概述

模板注入一直是钓鱼邮件的常青树，近期，笔者在筛选和过滤六月份模板注入的钓鱼文件中，发现了一些有意思的样本。

样本分析

样本信息

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

诱饵分析

原始样本诱饵名译为：发货延迟POA21022A，POA21022B，新到货日期.docx

docx文件中并没有诱饵内容，用户双击启用该文件之后则会从模板注入地址下载后续带有11882漏洞的rtf文档进行加载：
image.png

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

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

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

wiz文件分析

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

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

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

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

通过ShellExecute执行该pe：
image.png

vbc.exe

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

接着，程序生成一个大循环，让变量var_AC从0自增到0x19ad06a5
image.png

动态获取api，获取的api地址包括但不限于
VirtualAlloc
CreateToolhelp32Snapshot
Module32First
00a762d0
image.png

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

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

跳转到解密后的shellcode执行
image.png

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

判断apfHQ文件是否存在
image.png

注册名为saodkfnosa9uin的窗体
image.png

重新创建该进程
image.png

ZwUnmapViewOfSection卸载内存空间，准备傀儡进程注入
image.png

VirtualAllocEx进行写入
image.png

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

FormBook

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

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

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

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

再次解密前面的数据
image.png

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

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

call 到刚才修改过的代码执行
image.png

jmp far 执行01d40000的代码
image.png

执行解密出来的代码
image.png

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

样本2分析

样本信息

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

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

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

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

样本分析

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

下载C2/igo/win32.exe到本地保存为vbc.exe
image.png

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

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

frmMain的get方法中会给m_frmMain赋值
image.png

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

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

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

第二段base64数据
image.png

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

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

加载的函数是ArgumentNullException.MessageEnum
image.png

参数列表如下：
image.png

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

释放加载AgentTesla的窃密木马。
image.png