这个漏洞背后的图标显示bug可以深溯到Windows图像处理代码，其允许攻击者“借来”本地其他常用的图标并自动将可移植的可执行文件伪装起来，这样就更容易诱使用户打开他们。保守来说，自从Windows 7以来，这个bug就已经出现，而且仍然存在于最新版本的Windows 10中。
我们最近在研究一批恶意PE文件的时候发现了这个bug，在将一个文件从一个目录拷贝到一个目录的之后，我们发现了一个奇怪的行为：一些文件的图标改变了。为了排除出错的可能性，我们又将文件拷贝到另一个目录下，不过情况还是一样，这些文件的图标变成了其他很常见，却与其毫不相关的图标。这引起了我们的兴趣，并对这个奇怪的现象展开调查。
视频演示：
这批2017年4月的恶意文件包含了几十个Cerber勒索软件的样本，而这些勒索软件都发生了这种异常现象。在资源管理器中，样本提取的图标如下图所示
有些人乍一看可能认为这只是一些勒索软件使用的人畜无害的图标（确实，不过左上角那个图标很奇怪），但是在将这些图标转换成不同的内部图像格式后，这些图标展示了其真面目。
可以看出，这些图标有些奇怪的地方：都基于Adobe图标，且全部是黑白的，不过除此之外就是一个很正常的图标了。这些文件几乎都有轻微的像素修改痕迹，表明其是自动生成的，目的是用来躲避基于图标的签名。
下图为Adobe的图标：
正当许多恶意程序使用一些资源在杀毒软件和人的眼睛之前隐藏自己时，我们需要知道的是其图标并不是真正显示在屏幕上的图标，除了模仿Adobe的图标，他们都有一个共同点，它们都是我们所称的“真单色图标”（True Monochrome Iron），简称TMI。
TMI是具有两个特定品质的图标——它们只有两种颜色（即它们的比特每像素（bpp）为1），这两种颜色正好是黑色（0×000000）和白色（0xFFFFFF）。值得注意的是，图标可以是具有其他颜色的单色（就像黑白一样），但它们并不是单色（bpp高于1），所以说bpp=1这种现象只发生在真单色图标上。
图标文件格式的完整文档请点击下方链接查看
https://msdn.microsoft.com/en-us/library/ms997538.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx
这是从Ceber样本中提取的实例：
以往经验及实验表明：不需要特别制作，任何TMI图标都发生了不正常的图标转换。为了证明这一点，我们使用了十六进制编辑器做了我们自己的空TMI（任何人都可以尝试DIY）。
现在我们将这个图标作为唯一的”HelloWorld“程序图标，Windows资源管理器显示如下：
改名之后又变成了这个：
来张动图感受一下：
这到底是什么情况？？？
看起来问题在于图标渲染和缓存的方式，以及TMI所受到的特殊处理方式，这使得他们不会覆盖现有的目标。
Windows资源管理器，和其他应用程序中基于资源管理器的框架一样，使用comctl32.dll（用户体验控制库）中的CImageList类实现图标缓存。
https://msdn.microsoft.com/en-us/library/9xc4z2c7.aspx
缓存是通过将文件的路径映射到CImageList中的索引实现的（有多个这样的缓存，大小不同），因此，在查看一个图标已经被渲染过的文件时，简单地将图标从缓存中取出就好了；而尚未遇到的路径则需要根据文件类型从头开始渲染，然后再将其添加到缓存中。这就是为什么当浏览一个有很多图标文件的目录，或查看具有嵌入图标的PE文件时，文件会有延迟地逐渐显示。另外，当文件被拷贝或重命名时，它们的图标会被再次渲染，因为它们会被当作新遇到的路径。
然而这些都只有有限且相对较小的尺寸，当一个新图标被添加到图像列表中时，如果它还不是空的，所使用的索引就是-1，并且会附加新图标。但是当列表满了的时候，新图标会覆盖先前创建的图标，并将他替换为其索引（可能基于LRU）。
该逻辑在CImageList::_ReplaceIron函数中实现。
添加或替换依赖于所给的索引
经过一些操作之后，该函数将检查索引处的当前图像是否具有Alpha通道，如果有（几乎每次都是这样），就立一个用于决定以后该如何调用DrawIronEx的flag。
如果这个flag立了，该函数稍后就会使用flag DI_MASK (1)调用DrawIconEx来绘制列表中预先存在的图标，而不是DI_NORMAL (3)。
在内部，图标和图像一般可能包含两个不同的像素图——“颜色”和“蒙版”，这可以应用于颜色上，如ICONINFO的文档所示：
https://msdn.microsoft.com/en-us/library/windows/desktop/ms648052.aspx
所以本质上可以这样解释：仅仅”蒙版“部分被绘制，且覆盖了蒙版的DC（Device context） ( [esi+7ch] )而不是颜色的DC ( [esi+78h] ). 。当图标是TMI时，这种情况导致了没有像素被覆盖，且之后会借用CImageList先前占用者的索引来渲染图标！
如果要实现这种情况，就需要缓存已满，这取决于这些函数的调用者。但是这些类似于资源管理器的组件（如”文件打开“对话框）的大小实际上都非常小。
举个例子表明这可能发生在使用这些组件的任何进程中。该截图截于在”Outlook 2016“中的”添加附件“窗口中浏览满是TMI的目录时，
不仅仅是图标文件会触发这个bug（不包括嵌入图标的PE文件），不过条件是这些必须是文件中唯一的图标类型，因为选择“最佳拟合”图标的Windows的算法往往会根据大小和从高颜色深度到低颜色深度的顺序排列嵌入图标 。
既然是这种情况，我们决定再搜索我们的恶意软件数据库中只包含TMI的样本，所有筛选出的样本都无一例外地触发了这个bug，而在良性样本数据库中进行的类似搜索没有得到任何结果。
我们根据他们使用的图标变化将这些样本分成以下几组：
如上所述，第一次检测到的是从4月17日的Cerber勒索软件样本滥用Adobe徽标图标。 这里有五个这样的样品（以及他们目前在我们的机器上出现的方式）：
这些样本可能只是自动生成的，附带伪随机资源来伪装的PE文件中的一小部分 ，由此我们认为Cerber并未故意利用这个bug（还不能十分确信）。但是，我们同时也在从2014年到2017年的样本中寻找和我们自己制作TMI图标差不多的文件。通过寻找，认为有些文件的创建者知道这个bug，并积极地利用它，因为一个本身不试图模拟任何现有的应用程序的空图标没有任何价值。
这个bug虽然不是一个重大的安全漏洞，但足够提醒您以下几点：
对网络钓鱼活动保持警惕。
耳熟能详的”不要打开可疑的电子邮件的附件“。
显示文件的拓展名，因为这可以帮助我们辨别文件。
该错误在2017年6月向微软报告，我们的研究在他们的许可下发布。
*参考来源：Cybereason