对某HWP漏洞样本的shellcode分析

前言

最近拿到一个新的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。

第1阶段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

第2阶段shellcode

获取功能函数

得到解密后的第2阶段shellcode后,就可以愉快地在IDA里进行后续分析了。

第2阶段shellcode上来就是一系列hash,看起来貌似是要通过hash比对搜索功能函数。

一系列hash

一番调试和逆向后,我们明白shellcode封装了一个辅助函数用来查找所需的功能函数:

解密后的hash对应情况

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

然后,shellcode从读入的文档内容开始搜索两个连续的标志0x42594F4A0x4D545245,并将第2个标志结束+2的地址处作为PE数据的首地址保存到[ebp-18]处。

定位真正的加密PE处

可以在HWP文档中定位到相应数据区域:

在HWP文档中定位PE数据

不过此时的PE文件数据仍为被加密的状态,shellcode随后用两轮解密将解密的PE文件进行解密,相关汇编代码如下:

对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数据

解密后的PE数据如下:

解密后的PE数据

创建userinit.exe进程并挂起

得到解密的PE文件后,shellcode做了一系列准备并最终去启动userinit.exe进程,启动时传入CREATE_SUSPENDED标志,指明将userinit.exe启动后挂起:

准备进程启动信息

启动userinit.exe进程

替换userinit.exe主模块

随后shellcode调用GetThreadContext获取userinit.exe主线程的线程上下文并保存到栈的指定位置:

获取线程上下文

接着读取userinit.exe的Peb.ImageBaseAddress

读取peb内的镜像基地址

然后动态获取ntdll!ZwUnmapViewOfSection,并判断操作系统版本,如果操作系统主版本小于6(相关原理可以参考这篇文章),则调用该API对主模块基地址的内存进行解映射,否则直接跳到后续步骤:

判断操作系统版本

接着shellcode在userinit.exe进程内0x400000地址处(即PE文件中写入的进程默认加载基址)申请一片内存,内存大小等于解密出来的PE文件,并先将PE文件的头部写入所申请的内存(0x400000):

写入PE头部

随后往上述内存区域循环写入PE文件的各个节区:

循环写入各个Section

每写完一个节区后,shellcode获取PE文件中该节区的原始读写属性(通过Characteristics字段),并在内存中相应更新这些节区对应的内存属性:

更新内存属性

完成上述步骤后,shellcode将userinit.exe进程的Peb.ImageBaseAddress域改写为0x400000(即注入后的PE基地址),并将线程上下文中Context.eax更新为所注入PE的AddressOfEntryPoint,这部分的原理可以参考这篇文章

改写OEP

最后恢复userinit.exe的主线程,并关闭刚才打开的userinit.exe进程句柄,从而使主线程去执行Process Hollowing后的PE文件,达到偷天换日的目的。相关代码可以参考这里

恢复线程

 

注入的PE文件

前面我们已经静态解密出了PE文件,我们现在来看一下解密出的PE文件的基本信息,用pestudio打开该PE文件,看一下这个PE文件的基本信息:

可以看到该PE文件的编译时间是2017.12.26 10:13:17,此外还可以知道该PE文件的链接器版本是9.0。

PE基本信息1

逆向PE文件

整个PE文件既没有加壳,也没有加花指令,整体逻辑非常清晰明了,拖进IDA基本上就原形毕露了。

PE文件主入口函数如下:

PE文件主入口

正如函数名所示,它首先调用AdjustTokenPrivileges提升自己的权限,然后分别从Kernel32.dll/Wininet.dll/Advapi32.dll获取所需的功能函数并保存到全局变量,最后启动一个新的线程,并在10秒后退出当前函数。

kernel32

wininet

(以下几个函数貌似并没有被用到)

advapi32

来看一下启动的线程干了哪些事情,如下图所示,这个线程的主要目的就是先收集系统信息,并保存到%appdata%MicrosoftNetworkxyz,随后将这些信息发送给远程C2,传完之后删除xyz文件。随后进入一个循环,每隔30分钟从远程服务器尝试下载一个zyx.dll并保存到%appdata%MicrosoftNetworkzyx.dll并尝试加载之。这里推测是C2端需要先判断目标用户是否有价值,然后才决定是否将下一阶段的载荷发送给目标用户。

线程函数

收集信息部分的代码也很直接,如下:

收集信息

随后将收集的信息发送给远程C2:

构造HTTP头部

post

http报文

最后,一旦远程dll被下发到目标机器,PE文件会立即加载之,并在3分钟后卸载对应的dll并删除文件。由于我们调试期间并没有获得下发的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

上一篇:保障IDC安全:分布式HIDS集群架构设计

下一篇:调查:加密货币挖矿仍居恶意软件威胁前列