前言
最近拿到一个新的HWP样本，样本本身利用的是一个老漏洞，这个样本吸引我们的是shellcode部分。相关漏洞的细节我们在之前的文章中已有描述。需要注意的是，这次的样本和上次的样本在最终的执行流切换方面有一些差异。前一段时间我们曾审计过一些HWP样本，发现不同HWP样本在触发该漏洞后具体的执行流切换上存在4种不同的情况。上次的漏洞分析文章是第1种情况，本次的样本是第2种情况，此外还有2种其他情况，相关的MD5示例如下：
第1种情况：
33874577bf54d3c209925c9def880eb9
第2种情况：
660b607e74c41b032a63e3af8f32e9f5
e488c2d80d8c33208e2957d884d1e918 (本次调试样本)
第3种情况：
f58e86638a26eb1f11dd1d18c47fa592
第4种情况：
14b985d7ae9b3024da487f851439dc04
本次调试环境为 windows7_sp1_x86 + HWP2010英文版 (hwpapp.dll 8.0.0.466) + windbg x86
这个样本在漏洞触发成功后执行的shellcode让我们眼前一亮，样本在漏洞触发后先执行第1阶段shellcode去解密第2阶段的shellcode。在第2阶段的shellcode中，通过hash比对的方式从kernel32.dll中获取功能函数，然后创建 C:Windowssystem32userinit.exe 进程并且在创建时挂起，接着从文档内容中查找标志头，定位到被加密的PE文件数据，随后通过两轮解密解出PE文件，将其写入userinit.exe进程的0x400000处，随后修改userinit.exe进程的Peb.ImageBaseAddress为新写入的PE文件，并且修改userinit.exe的主线程的线程上下背景文的Context.eax为新写入PE文件的AddressOfEntryPoint，然后恢复userinit.exe的主线程，从而将执行流切换到注入的PE文件的入口地址，这是一种Process Hollowing技术，相关原理在这个网页中有描述。这种方法让分析人员较难提取到注入的PE文件，在沙箱中跑时也不会显式drop出PE文件，可以说有效躲避了检测。注入的PE文件启动后，会收集系统信息保存到%appdata%MicrosoftNetworkxyz,随后发给远程C2(online[-]business.atwebpages[.]com)，然后在一个while循环中进行等待，如果收集的信息显示当前目标存在价值，远程C2会下发一个动态库保存到%appdata%MicrosoftNetworkzyx.dll并使之加载。比较遗憾的是，我们在调试时并没有得到zyx.dll。
文档信息
用HwpScan2工具打开该文档，先看一下基本属性部分。可以看到原始文档在2016年就已经生成。
原文档是限制编辑的，打开后文档内容无法复制，实际的段落内容被存储在”ViewText”流下，而不是常规的”BodyText”流下：
关于这一点，VB2018的一个PPT上有详细的介绍：
Section1和Section2这两个Section里面含有被压缩后的堆喷射数据，在文档打开期间解压后的数据会被喷射到指定的内存。
内存布局
这个样本用到了堆喷射来布局内存，我们在调试器里面看一下堆喷射的具体细节：
sxe ld:hwpapp.dll
...
ModLoad: 046f0000 04ad1000 C:Program FilesHncHwp80HwpApp.dll
eax=0012ee68 ebx=00000000 ecx=00000006 edx=00000000 esi=7ffdf000 edi=0012eff4
eip=772270b4 esp=0012ef0c ebp=0012ef60 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
772270b4 c3 ret
0:000> bp hwpapp+1122f3 ".if(edx == hwpapp+bded0){g;}.else{}"
0:000> g
DllMain() : DLL_PROCESS_ATTACH - ABase Start!
(d8c.468): C++ EH exception - code e06d7363 (first chance)
eax=20142014 ebx=0012f6bc ecx=20142014 edx=20142014 esi=02c86d18 edi=00000098
eip=048022f3 esp=0012ed90 ebp=02d881a8 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
HwpApp!HwpCreateParameterArray+0x8c433:
048022f3 ffd2 call edx {20142014}
0:000> !heap
NtGlobalFlag enables following debugging aids for new heaps: stack back traces
Index Address Name Debugging options enabled
1: 00230000
2: 00010000
3: 01980000
4: 02650000
5: 02770000
6: 02950000
7: 025d0000
8: 028f0000
9: 03250000
10: 028d0000
11: 04e20000
12: 06720000
13: 07440000
14: 07590000
// 可以看到5号堆块几乎被完全用完
0:000> !heap -stat -h 02770000
heap @ 02770000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
42003b0 2 - 8400760 (49.47)
420035c 2 - 84006b8 (49.47)
e4 926 - 825d8 (0.19)
f0 38a - 35160 (0.08)
194 1cf - 2daac (0.07)
24000 1 - 24000 (0.05)
18 15d9 - 20c58 (0.05)
20000 1 - 20000 (0.05)
100 190 - 19000 (0.04)
aa00 2 - 15400 (0.03)
28 6e1 - 11328 (0.03)
10bc0 1 - 10bc0 (0.02)
10000 1 - 10000 (0.02)
fda0 1 - fda0 (0.02)
fb50 1 - fb50 (0.02)
a8 158 - e1c0 (0.02)
4400 3 - cc00 (0.02)
2200 6 - cc00 (0.02)
800 17 - b800 (0.02)
82 13b - 9ff6 (0.01)
0:000> !heap -flt s 420035c
_HEAP @ 230000
_HEAP @ 10000
_HEAP @ 1980000
_HEAP @ 2650000
_HEAP @ 2770000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
invalid allocation size, possible heap corruption
121b0018 84006d 0000 [00] 121b0030 420035c - (busy VirtualAlloc)
invalid allocation size, possible heap corruption
242d0018 84006d 006d [00] 242d0030 420035c - (busy VirtualAlloc)
_HEAP @ 2950000
_HEAP @ 25d0000
_HEAP @ 28f0000
_HEAP @ 3250000
_HEAP @ 28d0000
_HEAP @ 4e20000
_HEAP @ 6720000
_HEAP @ 7440000
_HEAP @ 7590000
0:000> !heap -flt s 42003b0
_HEAP @ 230000
_HEAP @ 10000
_HEAP @ 1980000
_HEAP @ 2650000
_HEAP @ 2770000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0a6d0018 840078 0000 [00] 0a6d0030 42003b0 - (busy VirtualAlloc)
200c0018 840078 0078 [00] 200c0030 42003b0 - (busy VirtualAlloc)
_HEAP @ 2950000
_HEAP @ 25d0000
_HEAP @ 28f0000
_HEAP @ 3250000
_HEAP @ 28d0000
_HEAP @ 4e20000
_HEAP @ 6720000
_HEAP @ 7440000
_HEAP @ 7590000
// 推测Section1和Section2分别被映射了两次，我们来看一下堆喷射的总大小
0:000> ? 42003b0 / 400 / 400
Evaluate expression: 66 = 00000042
// 可以看到堆喷射的大小总大小为264MB，单个堆块大小为66MB，0x20142014地址稳定位于0x200c0030左右开始的喷射区域，所以可以很方便地劫持控制流。
0:000> ? 42 * 4
Evaluate expression: 264 = 00000108
第1阶段shellcode
漏洞触发成功之后，首先跳转到0x20142014这个地址，由于前面已经通过堆喷射布局内存，所以执行流可以一路滑行到0x242bf714(这里再强调一下，HWP2010并未开启DEP，所以可以直接在堆上执行shellcode)以执行第1阶段的shellcode。下面来看一下shellcode部分。
0:000> u 242bf714
242bf714 52 push edx
242bf715 53 push ebx
242bf716 56 push esi
242bf717 50 push eax
242bf718 57 push edi
242bf719 ba14201420 mov edx,20142014h
...
第1阶段的shellcode的主要目的是定位并解密第2阶段的shellcode。从下图可以看到，第1阶段shellcode通过第1轮循环(loc_A)定位到第2阶段shellcode地址，然后通过第2轮循环(loc_22)去解密第2阶段的shellcode。
我们用python模拟了一下上述shellcode的解密过程：
# -*- coding: utf-8 -*-
import os
import binascii
cur_dir = os.path.dirname(__file__)
path_encode = os.path.join(cur_dir, "sc_encode.bin")
with open(path_encode, "rb") as f:
bin_data = f.read()
bin_data = binascii.b2a_hex(bin_data)
i = 0
j = 0
k = 0
while k < 0x60D:
a = ((int(bin_data[i:i+2], 16) & 0x0F) << 4) & 0xF0
b = int(bin_data[i+2:i+4], 16) & 0x0F
c = '{:02x}'.format(a + b)
bin_data = bin_data[:j] + c[0] + c[1] + bin_data[j+2:]
i += 2 * 2
j += 2 * 1
k += 1
path_decode = os.path.join(cur_dir, "sc_decode.bin")
with open(path_decode, "wb") as f:
f.write(binascii.a2b_hex(bin_data))
实际解密时从下述数据开始：
解密完成后，我们可以得到如下数据：
第2阶段shellcode
获取功能函数
得到解密后的第2阶段shellcode后，就可以愉快地在IDA里进行后续分析了。
第2阶段shellcode上来就是一系列hash，看起来貌似是要通过hash比对搜索功能函数。
一番调试和逆向后，我们明白shellcode封装了一个辅助函数用来查找所需的功能函数：
在GetFuncAddrFromEATByHash函数内部，作者用循环右移13位的方式计算hash，并查找满足指定hash的动态库(kernel32.dll)内的满足指定hash的函数，然后将它们的地址保存到栈的指定位置，如上图所示。我们这里用C语言还原一下dll的hash的计算过程和api的hash的计算过程：
// 部分代码借鉴自网络，此处表示致谢
#include <stdio.h>
#include <windows.h>
#define ROTATE_RIGHT(x, s, n) ((x) >> (n)) | ((x) << ((s) - (n)))
DWORD GetHashHWPUnicode(WCHAR *wszName)
{
printf("%S", wszName);
DWORD dwRet = 0;
WCHAR* wszCur = 0;
do
{
dwRet = ROTATE_RIGHT(dwRet, 32, 0x0D);
dwRet += *wszName;
wszCur = wszName;
wszName++;
} while (*wszCur);
printf(" function's hash is 0x%.8xn", dwRet);
return dwRet;
}
DWORD GetHashHWPAscii(CHAR *szName)
{
printf("%s", szName);
DWORD dwRet = 0;
CHAR* szCur = 0;
do
{
dwRet = ROTATE_RIGHT(dwRet, 32, 0x0D);
dwRet += *szName;
szCur = szName;
szName++;
} while (*szCur);
printf(" function's hash is 0x%.8xn", dwRet);
return dwRet;
}
int main(int argc, char* argv[])
{
GetHashHWPUnicode(L"KERNEL32.dll");
GetHashHWPUnicode(L"KERNEL32.DLL");
GetHashHWPUnicode(L"kernel32.DLL");
GetHashHWPUnicode(L"kernel32.dll");
GetHashHWPAscii("ResumeThread");
GetHashHWPAscii("SetThreadContext");
GetHashHWPAscii("VirtualProtectEx");
GetHashHWPAscii("WriteProcessMemory");
GetHashHWPAscii("GetVersionExA");
GetHashHWPAscii("ReadProcessMemory");
GetHashHWPAscii("TerminateProcess");
GetHashHWPAscii("GetThreadContext");
GetHashHWPAscii("GetLastError");
GetHashHWPAscii("GetProcAddress");
GetHashHWPAscii("GetSystemDirectoryA");
GetHashHWPAscii("GetModuleHandleA");
GetHashHWPAscii("CreateProcessA");
GetHashHWPAscii("GlobalAlloc");
GetHashHWPAscii("GetFileSize");
GetHashHWPAscii("SetFilePointer");
GetHashHWPAscii("CloseHandle");
GetHashHWPAscii("VirtualAllocEx");
GetHashHWPAscii("ReadFile");
return 0;
}
定位PE文件并解密
获得需要的功能函数后，shellcode首先通过GlobalAlloc函数申请一段内存，用来存储后面将要读入的PE数据。随后，从4开始，遍历句柄，暴力搜索文件大小等于当前hwp文件大小的文件句柄并保存，然后将文件指针移动到0x9DE1偏移处，并将大小为3E40A Bytes的内容读入之前申请的内存处。
然后，shellcode从读入的文档内容开始搜索两个连续的标志0x42594F4A，0x4D545245，并将第2个标志结束+2的地址处作为PE数据的首地址保存到[ebp-18]处。
可以在HWP文档中定位到相应数据区域：
不过此时的PE文件数据仍为被加密的状态，shellcode随后用两轮解密将解密的PE文件进行解密，相关汇编代码如下：
在理解上述代码的基础上一样可以用python写出解密程序，如下：
# -*- coding: utf-8 -*-
import os
import binascii
cur_dir = os.path.dirname(__file__)
path_encode = os.path.join(cur_dir, "pe_encode.bin")
with open(path_encode, "rb") as f:
bin_data = f.read()
bin_data = binascii.b2a_hex(bin_data)
i = 2 * 2
while (i / 2) < 0x18400:
a = int(bin_data[i-4:i-4+2], 16)
b = int(bin_data[i-2:i], 16)
c = int(bin_data[i:i+2], 16)
c = '{:02x}'.format((a ^ b ^ c) & 0xFF)
bin_data = bin_data[:i] + c[0] + c[1] + bin_data[i+2:]
i += 2 * 1
i = 2 * 2
while (i / 2) < 0x18400:
c = int(bin_data[i:i+2], 16)
c = ((c << ((i / 2) & 7)) & 0xFF) + ((c >> (8 - ((i / 2) & 7))) & 0xFF) ^ (i / 2)
c = '{:02x}'.format(c & 0xFF)
bin_data = bin_data[:i] + c[0] + c[1] + bin_data[i+2:]
i += 2 * 1
path_decode = os.path.join(cur_dir, "pe_decode.bin")
with open(path_decode, "wb") as f:
f.write(binascii.a2b_hex(bin_data[4:]))
解密前的PE数据如下：
解密后的PE数据如下：
创建userinit.exe进程并挂起
得到解密的PE文件后，shellcode做了一系列准备并最终去启动userinit.exe进程，启动时传入CREATE_SUSPENDED标志，指明将userinit.exe启动后挂起：
替换userinit.exe主模块
随后shellcode调用GetThreadContext获取userinit.exe主线程的线程上下文并保存到栈的指定位置：
接着读取userinit.exe的Peb.ImageBaseAddress：
然后动态获取ntdll!ZwUnmapViewOfSection，并判断操作系统版本，如果操作系统主版本小于6(相关原理可以参考这篇文章)，则调用该API对主模块基地址的内存进行解映射，否则直接跳到后续步骤：
接着shellcode在userinit.exe进程内0x400000地址处(即PE文件中写入的进程默认加载基址)申请一片内存，内存大小等于解密出来的PE文件，并先将PE文件的头部写入所申请的内存(0x400000)：
随后往上述内存区域循环写入PE文件的各个节区：
每写完一个节区后，shellcode获取PE文件中该节区的原始读写属性(通过Characteristics字段)，并在内存中相应更新这些节区对应的内存属性：
完成上述步骤后，shellcode将userinit.exe进程的Peb.ImageBaseAddress域改写为0x400000(即注入后的PE基地址)，并将线程上下文中Context.eax更新为所注入PE的AddressOfEntryPoint，这部分的原理可以参考这篇文章。
最后恢复userinit.exe的主线程，并关闭刚才打开的userinit.exe进程句柄，从而使主线程去执行Process Hollowing后的PE文件，达到偷天换日的目的。相关代码可以参考这里。
注入的PE文件
前面我们已经静态解密出了PE文件，我们现在来看一下解密出的PE文件的基本信息，用pestudio打开该PE文件，看一下这个PE文件的基本信息：
可以看到该PE文件的编译时间是2017.12.26 10:13:17，此外还可以知道该PE文件的链接器版本是9.0。
逆向PE文件
整个PE文件既没有加壳，也没有加花指令，整体逻辑非常清晰明了，拖进IDA基本上就原形毕露了。
PE文件主入口函数如下：
正如函数名所示，它首先调用AdjustTokenPrivileges提升自己的权限，然后分别从Kernel32.dll/Wininet.dll/Advapi32.dll获取所需的功能函数并保存到全局变量，最后启动一个新的线程，并在10秒后退出当前函数。
(以下几个函数貌似并没有被用到)
来看一下启动的线程干了哪些事情，如下图所示，这个线程的主要目的就是先收集系统信息，并保存到%appdata%MicrosoftNetworkxyz，随后将这些信息发送给远程C2，传完之后删除xyz文件。随后进入一个循环，每隔30分钟从远程服务器尝试下载一个zyx.dll并保存到%appdata%MicrosoftNetworkzyx.dll并尝试加载之。这里推测是C2端需要先判断目标用户是否有价值，然后才决定是否将下一阶段的载荷发送给目标用户。
收集信息部分的代码也很直接，如下：
随后将收集的信息发送给远程C2：
最后，一旦远程dll被下发到目标机器，PE文件会立即加载之，并在3分钟后卸载对应的dll并删除文件。由于我们调试期间并没有获得下发的dll，所以dll里面具体执行了什么逻辑不得而知。
IOC
HWP: e488c2d80d8c33208e2957d884d1e918
PE: 72d44546ca6526cdc0f6e21ba8a0f25d
Domain: online[-]business.atwebpages[.]com
IP: 185[.]176.43.82
参考链接
https://github.com/m0n0ph1/Process-Hollowing
https://cysinfo.com/detecting-deceptive-hollowing-techniques/
https://blog.csdn.net/lixiangminghate/article/details/42121929
https://www.virusbulletin.com/uploads/pdf/conference_slides/2018/KimKwakJang-VB2018-Dokkaebi.pdf