Hidden Bee感染链分析（一）：stegano

Hidden Bee与常见的工具集不同，有着复杂和多层的内部结构。在1年的发展中不断更新，近期，研究人员从一个恶意可执行文件开始分析其感染链。本文介绍从Underminer Exploit Kit开始的感染过程中使用的一个加载器。

释放的payloads:概述

研究人员首先是从一个flash利用中开始发现Hidden Bee的感染的。它下载和注入了2个WASM扩展的元素，实际上这是自定义格式的可执行文件模块。

 WASM扩展的文件

这些元素是初始的加载器，负责初始化最终安装挖矿机的感染链。

在最近的攻击活动中，这些元素发生了一些变化。最近释放的元素中已经找不到WASM扩展，取而代之的是不同种类的多媒体文件，包括WAV、JPEG、PNG等格式。

下载的元素：WAV, JPG, PNG

WAV文件是由iexplore.exe下载的。图像文件是感染的之后阶段下载的，比如JPG是从dllhost.exe进程下载的。PNG一般是另一个进程下载的。

研究人员发现很多时候下载的都是PNG格式而非JPG格式：

WAV之后下载的PNG

然后我们对这些文件进行分析，并查看负责处理这些的代码来分析其潜在的目的。

完整的路线图如下所示：

元素之间转换的路线图

下载的WAV

WAV文件听起来像噪声，研究人员怀疑其中隐藏了属于恶意软件的二进制文件。

WAV文件的波形图

数据是不可读的，可能是被加密或经过了混淆：

研究还在其中找到了一个重复模式，看起来像一个加密的填充。填充块的大小是8个字节。

The 文件中的重复模式：8字节

JPG

下面是从URL以/views/[unique_string].jpg格式下载的样本JPG文件。

与WAV内容相比，JPG看起来是一个有效的图片。但是如果自己观察图片文件，就会发现其中有数据加到了尾部。

下面分析JPG文件，并尝试提取出payload。

首先，在十六进制编辑器中打开图片。图片的大小为156005字节，最后的118762字节属于恶意软件。所以需要移除前37243字节内容（156005-118762=37243）来获取payload。

添加到JPG的部分

Payload看起来不像是有效的代码，因此可能是混淆的。首先查看最简单的option，并尝试分析可能的XOR key。研究人员发现payload在尾部有填充：

研究人员将重复的字符作为XOR key，本例中为0xE5。得到的结果是(1953032199142ea8c5872107da8f2297):

在不同payload中重复实验，可以看出结果是从关键字 !rcx开始的。加载 !rcx模块到IDA中，研究人员确认了其中含有有效代码。

PNG

下面分析以下从URL /images/captcha.png?mod=attachment&u=[unique_id]处下载的样本PNG captcha.png：

虽然PNG是有效格式，但是看起来像噪声，可能表示的是加密数据。研究人员尝试将PNG图片转换为原始字节但没有成功。

代码分析：初始SWF文件

初始SWF文件是潜入在网站中的，负责为漏洞利用服务。但是看起来其中是没有恶意内容的。但是在二进制数据中可以发现一个恶意的WAV：

文件开头是这样的：

SWF文件中含有解码器：

函数decode中含有4个参数。第一个是含有WAV的字节数组，也是要解码的内容。第二个参数是由AppId和AppToken拼接而成的MD5，这可能就是加密密钥。第三个参数是salt（可能是加密函数的初始向量IV）。

Salt是从HTML页面提取的，其中嵌入了Flash组件：

另外二个WAV文件

除了嵌入含有Flash漏洞利用的WAV外，恶意软件开发者还使用其他的方式来传播它。他将URL保存到WAV中，并提取出来文件。

在下面的例子中，可以看到如何将该模式应用于Hidden Bee。Salt和WAV URL都保存在嵌入HTML的JS中：

Flash文件首先加载然后再下一步解码：

通过抓取的流量，可以看出下载了2个WAV文件：

下载了2个WAV文件的例子

用来加密第一个WAV内容的算法可能是不同的，有时候算法也作为其中的一个参数。在提取了内容后，WAV中的数据会用下面的算法来解码：

可以看出内容是一个Flash文件，之后会被加载：

Decode函数

Decode函数是从package com.google中导入的：

完整反编译代码见：https://gist.github.com/malwarezone/3aea44e1d4c66821f92b1092461fb815

分析发现，其中的代码进行了简单的混淆：

从反编译的代码中可以看到一些有意思的常数，比如–889275714的十六进制是0xCAFEBABE。在其他Hidden Bee元素的分析中，该DWORD被用来识别特定的格式。

其中引用了其他模块E_ENCRYPT_process_bytes()中的函数。在该函数中，可以调用Rabbit Cipher ：

Rabbit使用128位密钥和64位初始向量

解码过程完成后，得到的内容会被加载：

第一个WAV: Flash exploit

解码的WAV中含有一个嵌入了2个元素的package：一个Flash文件（movies.swf）和配置文件config.cfg。解码的数据从DWORD 0xCAFEBABE开始，这在前面的WSF代码中也出现过。

Flash 文件(movies.swf) 中含有一个嵌入的漏洞利用。经过分析，该漏洞利用使用的是CVE-2015-5122：

payload (shellcode)以数组的形式保存：

配置文件(config.cfg)中含有到另一个WAV文件的URL

Payload用NOP (0x90)字节填充，参数在payload运行前填充。

填充配置文件到payload的代码段

shellcode: 下载第二个WAV

第二个WAV与第一个相比，是下载的而不是嵌入的。它是从“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2)中提取的。

分析shellcode，研究人员发现该函数负责下载和解密另一个WAV。Shellcode使用前一层填充的参数。缓存中含有要查询的URL和用作payload解密的key，会从使用校验和的wininet.dll中加载函数。在初始化后，会查询填充的URL。期望的结果是含有针对WAV文件的首部的缓存。

WAV中的数据含有加密的数据。Block是8字节长，在循环中解密：

解密完成后，就看到了下一个模块。解码的数据是从0x01，0x04，…, 0x10开始的。

第二个WAV: 专门格式的可执行文件

如下所示，可以看出WAV数据解密后的样子：

这是一个加载到IE中的可执行文件组件。在解码import后，看起来就比较熟悉了：

该模块首先在IE中执行，然后创建一个暂停状态的进程(dllhost.exe)：

注入到原来的副本中：

然后重定向执行到加载函数中。下面可以看到dllhost.exe植入模块的入口点。

这里的dllhost.exe就是下载前面提到的图像的模块。

定制格式的模块

该模块与之前定制格式的模块类似，但是在header和实现上都有一些改进。

定制格式的变化

新的header与之前类似，发生变化的部分有：开始位置的数字从0x10000301变成了0x10000401，DLL保存的格式发生了变化。因此将该格式称之为0x10000401格式。另一个变化是是DLL的名字用简单XOR算法和1字节字母进行了混淆。在加载前会进行反混淆。

新格式如下：

混淆

这次作者在模块内将所有的字符串进行了混淆。所有的字符串在使用前都会进行解码。

示例：使用前解码字符串

解码算法非常简单，是基于XOR的：

字符串解码算法

图像下载器

下面看一下0x10000401格式的第一个模块。该模块是初始阶段的，角色是下载和解压其他组件。其中一个组件是CAB格式的。

该模块的角色与第一个WASM类似。当前版本中不仅做了更好的保护，还做了一些改进。这次下载的内容是隐藏在图像中的。所以分析该元素可以帮助我们更好地理解隐写术的原理。

首先，看一下来自base64格式的URL：

解码的字符串是一个含有要下载的PNG和JPG文件URL的列表。不同的样本这个列表是不同的。而且这些URL都不会重用：服务器只会给一个相应。比如：

http://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13
http://38.75.137.9:9088/images/captcha.png?mod=attachment&u=357e27e8af72925144ec1db2421d0cc5<
http://38.75.137.9:9088/views/q5ul78uv4b4q8bg8d95canrsns.jpg

因此，可以确认该模块是一个负责下载和处理以上图片的模块。

解码JPG

提取payload后，JPG header就验证了有效性。

然后payload就会用简单的XOR和最后一个字节解码。解码的内容是从!rcx开始的。

在解码内容后，!rcx模块的哈希值会用SHA256哈希进行有效性验证。有效的哈希会保存在模块的header中，并于文件内容计算得出的哈希值进行比较。

如果有效性验证通过了，保存在!rcx模块中的shellcode就会加载。

!rcx 包的header如下所示：

解码PNG

提取PNG中的内容比较复杂。

“captcha.png” –加密的CAB文件

首先，下载后，检查PNG header：

加密PNG的函数流程如下：

它将PNG转为字节内容，然后再ARIA cipher的帮助下解码。结果应该是CAB格式的。解压的CAB中含有一个之前遇到过的bin/i386/core.sdb模块。

作者没有重用URL和加密密钥。这就是为什么每个payload的Aria key都不同的原因。最后保存在0x10000401模块的结尾：

Key 格式: WORD key length; BYTE key_bytes[];

模块加载过程中，key会从用来解密下载的模块的位置重写到另一个内存区域。

从PNG中提取的CAN文件见: 001bdc26b2845dcf839f67a8760c6839

其中含有core.sdb (d1a2fdc79c154b120a0e52c46a73478d)。这是Hidden Bee定制格式的第二个模块。

core.sdb

该模块是0x10000401格式的第二个下载器模块。它使用定制的基于TCP的协议SLTP。

sltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999

执行流

1、检查黑名单进程，如果有，退出。

2、用RET指令覆写开始的部分来移除函数DbgBreakPoint, DbgUserBreakPoint。

3、检查是否安装了恶意软件，如果是，退出。

4、创建安装mutex {71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins。

5、如果模块flag=1：

a.连接到第一个地址: sltp://dns.howtocom.site:1108/minimal.bin?id=998

b.设置环境变量INSTALL_SOURCE 为给定值

c.运行下载的下一阶段模块

6、如果模块flag不等于1：

a.执行针对虚拟机的检查，如果存在，退出。

b.连接到第二个地址： sltp://bbs.favcom.space:1108/setup.bin?id=999。将受害者指纹加入到URL，格式为 <URL>&sid=<INSTALL_SID>&sz=<unique machine ID: 16 bytes hex>&os=<Windows version number>&ar=<architecture>

c.运行下载的下一阶段模块

防护性检查

在这一阶段，使用了多种反分析检查。首先，检查是否有黑名单中的进程运行。进程的枚举是用低级函数NtQuerySystemInformation和参数5 (SystemProcessInformation)：

黑名单中含有主流的调试器和嗅探器：

“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”, “ImmunityDebugger.exe”, “windbg.exe”
“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”

进程的名字也被混淆过了，所以在字符串列表中是不可见的。如果检测到任意的进程，就终止执行模块。

另一个函数使用了多种反虚拟机的检查，包括：

CPUID with EAX=40000000 (a check for Hypervisor’s Brand):

VMWAre I/O Port:

VPCEXT instruction

检查常见的虚拟机厂商：

为虚拟机环境检查BIOS版本：

如果发现任何关于虚拟机的特征就终止组件

下载新模块

HiddenBee的另一个元素是通过STLP协议下载的。

使用SLTP协议创建通信用的原始TCP socket：

通信是加密的，可以看到结果是随后加载和执行的shellcode：

!rcx package

该元素会提出恶意软件使用的定制的文件系统。Hidden Bee使用自己定制的文件系统，挂载在内存中并传递给其组件。文件系统对执行流来说非常重要，因为其中含有许多要安装到被攻击的系统中的组件来继续感染过程。

解压JPG文件可以获取!rcx package。该包下载后，会验证SHA 256校验和，然后重打包。首先，在!rcx的尾部，会复制之前模块中的URL列表。然后，复制ARIA key。模块的大小和SHA 256也会更新。最后，执行会被重定向到从!rcx中提取的第一阶段shellcode。

该shellcode就是前面看到的，从JPG 中解码的!rcx包。乍一看，并没有什么恶意内容的。这是因为这些元素都经过了非常好的保护，而且在下一阶段才会执行。

!rcx package中的shellcode一共有2个执行阶段。第一个是解包并为第二阶段准备。首先，使用硬编码的库来加载import。

函数的校验和会保存在模块中，并于函数计算得出的值进行比较：

校验和计算算法

其中使用来自kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll: RtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess的函数。

重打包的!rcx模块会作为第一个shellcode的入口点参数。因为第二阶段shellcode会从前面提供的!rcx包中解包。

检查 !rcx (第一阶段shellcode)

分配了一个新的内存区域，第二阶段shellcode被解包了。

解码和调用下一个模块

在第二个shellcode中，可以看到引用Hidden Bee恶意软件的组件：

/bin/i386/preload
/bin/i386/coredll.bin

第二阶段的角色就是解包!rcx的另一部分：!rdx包。

检查!rdx（第二阶段shellcode)

根据之前的经验，研究人员认为!rdx package是含有模块的定制的文件系统。在解密完成后，定制的文件系统就很明显了：

隐藏在JPG中的这一部分是一个家么定制文件系统和实现下一阶段模块 /bin/i386/preload 和 /bin/i386/coredll.bin的包。文件系统中有更多元素都被加载到感染的下一阶段。

总结

Hidden Bee恶意软件还在不断地更新。经过一年的进化，研究人员可以确认的是恶意软件作者使其更新静默以绕过安全产品的检测。初始释放器使用了和之前类似的组件，但加密的密钥和URL都不再重用，因此分析过程很艰难。研究人员认为Hidden Bee恶意软件活动短期内还会持续发展。