一、简述

3月，卡巴斯基公布了一份有关“ShadowHammer故意主题活动”的供应链攻击报告，该报告中叙述了攻击者怎样根据ASUS Live Update Utility派发总体目标恶意程序，进而完成对asus的攻击。文中关键对此次攻击中所应用的之一阶段Payload开展深入分析。

二、恶性事件回看

2019年3月25日，卡巴斯基公布了一篇对于asus供应链攻击的高级别报告。在报告中，卡巴斯基强调：“在2019年1月，大家发觉了与ASUS Live Update Utility有关的繁杂供应链攻击。该攻击产生在2018年6月至11月中间，依据大家的监测，本次攻击危害了很多客户。”

攻击的总体目标是一个不明的客户池，这种客户的 *** 适配器MAC地址早已被鉴别出去。为了更好地完成这一总体目标，攻击者在木马病毒化的样本中硬编码了一份MAC地址目录，该目录用以鉴别本次规模性行動的具体总体目标。

在最开始的报告中，包括了一些有效的信息内容，但关键技术在初期遭受了限定，没法太多公布。为了更好地掌握相关该攻击的其他信息，我们决定进一步剖析Payload。

三、历史时间主题活动

在卡巴斯基的文章内容中，引入了一个ZIP文档，该文件是ASUS Live Update Utility的团本。在这个ZIP文档中，有三个文档，2个MSI和一个名叫Setup.exe的文档。根据在VirusTotal上查询这种文档的历史数据并查验文档自身，大家发觉，攻击者早已将Shellcode *** 到合理合法的Setup.exe中，并改动编码，进而完成跳转实行。

大家剖析了VirusTotal的历史时间样本，便于能够更好地掌握攻击者的个人行为。依据卡巴斯基的报告，此次攻击产生在2018年6月至11月，我们在VirusTotal上递交的样本中获得了认证。之一个故意样本在2018年6月29日被递交，而近期的样本是在2018年11月17日递交。

大家对这种样本开展了深层次地剖析，发觉在其中最少布署了二种不一样的侧门组合。从6月到9月，攻击者应用没经编号的Payload及其修复后的WinMain来跳转实行。

从9月逐渐，一个更为隐秘的侧门被攻击者布署，在其中包含一个搞混后的Shellcode Payload和视频解码器，根据涵数_crtExitProcess实行。大家发觉全部样本都应用同样的C&C安全通道，即asushotfix[.]com，该网站域名在2018年5月五日初次申请注册，其相匹配的IP地址是141.105.71[.]116，坐落于乌克兰。

根据对这一IP地址开展查看，还发觉了下列别的网站域名：

· host2[.]infoyoushouldknow[.]biz（2013年4月27日初次发觉）

· nano2[.]baeflix[.]xyz（2016年3月24日初次发觉）

· asushotfix[.]com（2018年5月22日初次发觉）

· www[.]asushotfix[.]com（2018年7月13日初次发觉）

· homeabcd[.]com（2018年9月五日初次发觉）

· simplexoj[.]com（2018年9月11日初次发觉）

现阶段暂不清楚这种网站域名充分发挥了哪些的功效，但很有可能他们也被用以本次对于asus的攻击当中，或是同一攻击者启动的别的攻击。

在下面的一部分中，大家将详细分析卡巴斯基报告中引入的一个样本（MD5：55a7aa5f0e56ba4d78c145811c830107），在其中包括历经搞混后的Payload。

四、载入Shellcode

在高些的一个等级看来，Setup.exe二进制文件好像是一个合理合法的文档。该文件早已历经签字，元信息内容也与合理合法的文档相符合，大部分编码合乎别的合理合法安装包的方式。可是，在将具体的合理合法Setup.exe与故意Setup.exe开展较为后，大家发觉，在其中的编码早已被修复，实行流将从_crtCoreExitProcess迁移到新涵数。

大家将这一新涵数重新命名为drop_shellcode。在其中，包括获取、编解码和实行内嵌式Payload的编码。根据在ExitProcess以前，即将迁移的內容置放在Setup.exe文件的结尾，就可以保证合理合法文档依照预估实行，进而减少被发觉的概率。

大家对Shellcode推广的涵数开展剖析，发觉它更先根据VirtualAlloc调用在Setup.exe过程中分派的运行内存，随后将置入的Shellcode拷贝到早已分派的运行内存中：

趣味的是，之一步仅在编解码以前，就将Payload的前16个字节数拷贝到了运行内存当中。这种字节数中，事实上包括Payload的尺寸，随后传送给第二个VirtualAlloc调用。接着，撰写、编解码和实行主Shellcode。

在文中中，不容易对编解码 *** 开展关键剖析，Winnti以前早已应用过相近的编码。

五、剖析Shellcode

依据大家截止到现阶段的剖析，Shellcode会实行下列实际操作：

1. 分析后必须启用的函数库：

(1) 解析xmlPEB中的构造，并查验k、l、点(.)标识符，以搭配控制模块名字，能够寻找之一个Kernel32的基址。

(2) 分析控制模块PE表，搜索导出来表。

(3) 应用涵数对自定义函数开展hach测算，并在每一次迭代更新时导出来该值以认证是不是搭配。

(4) 以一样的 *** ，寻找别的控制模块中的涵数，应用LoadLibraryExW获得基址。该涵数是坐落于Kernel32中的之一个涵数。

2. 根据启用IPHLPAPI.GetAdaptersAddresses获得服务器的MAC地址。

3. 将MAC地址开展MD5hach计算。

4. 将MD5hash值与硬编码的目录开展较为。要是没有寻找搭配项，则会将一个神密的IDX文档推广到硬盘。

5. 假如MAC地址搭配，则会应用 *** 商认知（Proxy-aware）API启用，从特殊URL免费下载第二阶段Payload。该全过程会直接进入RWX运行内存中，而且会被启用。

下边是有关每一个流程的详尽关键点。

5.1 解析函数

Shellcode更先必须寻找它要想应用的一些函数库，这关键分成2个流程。更先，在从好几个DLL中分析别的涵数以前，它会更先从KERNEL32.DLL中找寻LoadLibraryExW和GetProcAddress，LoadLibraryExW的详细地址将在第二阶段应用。