从六月模板注入样本看黑产更新

 

概述

模板注入一直是钓鱼邮件的常青树，通常会配合着11882这个漏洞双剑合璧，悄无声息的窃取受害者主机上的文件，但由于这两个漏洞的特征较为明显，绝大多数的杀软都可以直接检测到，所以除了Gamaredon以外，也几乎没有其他组织会用0199漏洞利用的样本作为第一阶段的样本。最常使用0199的是在地下论坛售卖的商业马。笔者在筛选和过滤六月份模板注入的钓鱼文件中，发现FormBook和AgentTesla均使用了同样的加载手法，这或许说明有一批人正在将这些商业马重新打包售卖或使用。

 

样本分析

样本信息

原始样本类型：docx
样本名：Shipment Delay POA21022A, POA21022B, New Arrival Dates.docx
样本md5：bdbe43fde60af6dcb046c93626052c0a

诱饵分析

原始样本诱饵名译为：发货延迟POA21022A，POA21022B，新到货日期.docx
docx文件中并没有诱饵内容，用户双击启用该文件之后则会从模板注入地址下载后续带有11882漏洞的rtf文档进行加载：

该地址一看比较奇怪，但其实@符号之前的内容在解析时会被忽略，所以请求地址实际上是：
hxxps://0306.0014.0133.0240

根据该地址特性，很容易想到这是八进制的描述方法，转换为十进制之后，完整的请求路径为：
hxxps://198[.]12.91.160/-…………….-……………………………………………..—.-.-/……………………………………………………wiz

下载回来的wiz文件其实是一个11882漏洞利用的rtf文件

wiz文件分析

11882漏洞触发之后，程序会跳转到shellcode继续执行：

shellcode中有很多jmp用于干扰分析，同时动态解后面的代码

代码解完之后，依旧是第一个call直接步过，第二个call F7进入

最后从http[:]//198.12.91.160/www/vbc.exe 下载vbc.exe保存到本地的public路径下：

通过ShellExecute执行该pe：

vbc.exe

加载的vbc.exe是32位的应用程序。
程序运行后首先会检查dwByte 是否等于0x25，word_8EC300的长度是否为0x0E12，若两个判断条件通过则可能说明程序的运行环境符合攻击者预期。 首次运行时这个条件很明显是无法匹配的：

vbc.exe外面的代码全是假代码，用于迷惑用户分析的，执行到真实的shellcode需要跳转多次，这里需要注意。

进入shellcode之后，程序动态获取api，获取的api地址包括但不限于
VirtualAlloc
CreateToolhelp32Snapshot

Module32First

调用刚才获取的api，创建进程快照

分配内存空间并解密数据写入：

跳转到解密后的shellcode执行

解密之后的shellcode沿用了之前的风格，还是通过一样的方法去动态获取api地址，获取地址的api包括但不限于
WinExec
CreateFile
WriteFile
CreateProcess
GetThreadContext
GetModuleFileName
VirtualAlloc
VirtualAllocEx
ReadProcessMemory
WriteProcessMemory
SetThreadContext
ResumeThread
WaitForSingleObject
GetCommandLine
NtUnmapViewOfSection
NtWriteVirtualMemory
CreateWindow
VirtualProtectEx
GetFileAttributes
……

重新创建该进程，准备进行注入

ZwUnmapViewOfSection卸载内存空间

VirtualAllocEx进行写入

注入完成之后，结束当前进程

FormBook

注入的PE是FormBook窃密软件。
程序会遍历进程信息查找explorer.exe进行注入

程序中包含了多条执行分支，有非常完善的反分析技巧和注入技巧，完全分析工作量过大，这里挑选其中一条注入分支进行举例说明。

调用VirtualAlloc分配了01d40000和01d20000两段内存空间，后面对这两段内层空间操作均相同。

需要注意的是，程序中使用的函数均为自映射nt函数，无法直接设置断点中断

分配内存之后，程序将从指定的位置拷贝数据到新分配的内存中

再次解密前面的数据

同样的，程序通过_NtProtectVirtualMemory函数来替代了VirtualProtect

程序通过几个memcpy，修改了0041D1C7的部分字节码，查看修改后数据的尾部，不难发现01d40000是之前分配出来的空间

最后call 到刚才修改过的代码执行

jmp far 执行01d40000的代码

如下：

由于FormBook后续冗长，代码可执行的分支很多，本文中就不对剩余代码进行详细分析。

 

样本2分析

样本信息

原始样本为eml文件，样本md5为： 2b212a84a49c414acc3c0f9b79454db4 ，原始样本名为：문서.eml，译为：文书.eml

eml文件中以账户信息为诱饵，诱导用户下载并打开附件带有0199模板注入漏洞的docx文档：

该文档中模板注入地址位编码后的短连接，在真实的地址前面依旧加了一些无效字符串

短连接还原之后，真实的请求地址为：
http://192[.]227.196.133/igo/i.wbk

样本分析

i.wbk依旧是11882漏洞利用的文档，漏洞触发后的代码和上面的样本保持一致：

此样本11882漏洞出发之后的代码风格和上面非常接近，最后，程序也会下载C2/igo/win32.exe到本地保存为vbc.exe

下载的win32.exe Main函数只是一个空壳，真实的入口点在下面重写的OnCreateMainForm函数中

在该函数中，程序将base.MainForm重新指定为了MyProject类下面的frmMain

frmMain的get方法中会给m_frmMain赋值

跳转过来之后的frmMain类才是真实的代码

在frmMain的实例化方法中，分别调用了三个函数，关键代码在最后的InitializeComponent()函数中

程序硬编码了多段base64字符串进行拼接

第二段base64数据

拼接两段数据并调用base64解码函数

从base64头部的H4sIAAAAAAAEAOy9C1xU5dY 字符串可以得知该数据解码之后是一个压缩包，程序自定义了一个FillRecta函数用于解压缩并Assembly加载解压缩后的数据

加载的函数是ArgumentNullException.MessageEnum

参数列表如下：

加载的dll依旧是一个注入器，程序会读取原始文件中：
CriticalAttribute.Resources
资源项下的HMACRIPEMD160 资源，解密出一个PE并通过assembly加载

加载AgentTesla的窃密木马。