隐藏的蜜蜂感染链，第一部分:剑龙群

大约一年前，我们描述了由Underminer Exploit Kit提供的Hidden Bee矿工．

Hidden Bee的内部结构复杂而多层，这在网络犯罪工具包中是不寻常的，这使它成为威胁领域中一种有趣的现象。这就是为什么我们在这一年中专门发表了一系列文章来探索特定的元素和更新。

最近，我们决定重温这个有趣的矿工，描述其装载机从单一恶意可执行文件开始感染。此帖子将呈现一个替代装载机，当感染从内置型器漏洞套件开始时部署。它类似于我们在2018年的以下帖子中描述的装载机：[1] 和 [2]。

下降的有效载荷:概述

我们第一次发现"隐藏蜜蜂"的时候，它是利用闪光漏洞感染的。它下载并注入了两个带有WASM扩展的元素，这两个元素实际上是自定义格式的可执行模块。我们详细地描述了它们在这里．

这些元素是初始装载机，负责启动感染链最后安装了矿工．

如今，这些因素已经发生了变化。如果我们看看今天被同一个EK丢弃的元素，我们将再也找不到那些WASM扩展。相反，我们会遇到各种各样的多媒体文件:一个WAV(或者两个WAVs)、一个JPEG和一个PNG。

WAV文件由IExplore.exe下载，浏览器运行的浏览器。相比之下，在稍后的感染阶段下载图像。例如，JPG始终从DLLHost.exe进程下载。PNG通常从另一个过程下载。

在某些运行中，我们观察到要下载的PNG而不是JPG：

我们将通过查看这些文件开始我们的隐藏蜜蜂分析之旅。然后，我们将看到负责处理它们的代码，以揭示它们隐藏的目的。

完整描述包的路线图:

下载的wav

WAV文件听起来像灰色噪音，我们怀疑它是为了隐藏一些属于恶意软件的二进制文件。

数据不可读，可能是加密或混淆的:

我们还发现里面有重复的模式，看起来像是加密的填充。chunk的大小为8字节。

这次，使用重复模式作为XOR键无助于获得可读结果，因此可能使用一些更复杂的块密码。

的JPG

下面是一个示例JPG，以格式从URL下载：/视图/ [unique_string] . jpg

与WAV内容相比，JPG始终看起来像一个有效的图像。（有趣的是，我们观察到的所有JPG都有一个始终如一的漫画风格的女孩的主题。但是，如果我们仔细看看图像，我们可以看到一些数据在最后附加。

让我们分析JPG并尝试提取有效载荷。

首先，我在Hexeditor（i.hxd）中打开了图像。完整图像的大小为156,005个字节。最后118,762个字节属于恶意软件。因此，我们需要删除前37,243个字节（156,005-118,762 = 37,243）以获得有效载荷。

有效载荷看起来不像有效代码，所以它可能会被滥用。让我们首先尝试最简单的选择，看看是否有XOR键有任何候选者。我们可以看到有效载荷最后有填充：

让我们尝试将重复字符(在给定的示例中是0xE5)应用为XOR键。这就是结果(1953032199142A8C5872107DA8F2297）：

重复各种有效载荷的实验，我们可以看到结果始终从关键字开始！rcx.．我们从分析中知道Hidden Bee的其他元素，此恶意软件的作者决定使用以后命名的各种自定义格式64位英特尔寄存器．我们还遇到了包从！RBX.和肢体重复性劳损症!在不同的层。这是链中第一个使用这种约定的元素。

当我们载入！rcx.模块进入IDA，我们可以确认它包含有效代码。更详细的解释！rcx.格式将在本文后面给出。

PNG.

让我们来看看样品PNG，从“CAPTCHA.PNG”下载（URL格式：/images/captcha.png?mod=attachment&u=[unique_id]）：

虽然它是一个有效格式的PNG，但看起来像杂音。它可能表示一些加密数据的字节数。将PNG转换为原始字节的尝试没有给出任何可读的结果。我们需要分析代码以便发现它隐藏了什么。

代码分析：初始SWF文件

初始SWF文件嵌入网站上并负责服务漏洞利用。如果我们在内部看，我们就不会发现任何恶意的东西。但是，在二进制数据中，我们可以找到另一个可疑的WAV作为音频资产：

文件的开头:

这个SWF文件还包含一个解码器:

功能“解码”需要四个参数。其中的第一个是包含WAV资产的字节数组：这是要解码的内容。第二个参数是MD5（“设置”函数是一个MD5实现）由AppID连接和Apptoken：这可能是加密密钥。第三个参数是盐（可能是加密的初始化向量）。

salt是从HTML页面中获取的，其中嵌入了Flash组件:

替代案例：两个WAV文件

有时，作者不是嵌入包含Flash漏洞的WAV，而是使用另一种模型来传递它。它们将URL存储到WAV，然后检索文件。

在下面的示例中，我们可以看到该模型如何应用于隐藏的蜜蜂。盐以及WAV URL均存储在HTML中的JavaScript中：

Flash文件首先加载它，然后将其解码为下一步：

看看交通捕获，我们可以看到，在这个例子中，不是一个，但是两个WAV文件已下载：

用于加密第一个WAV内容的算法可能不同，有时算法作为参数之一提供。获取内容后，WAV文件中的数据使用一种可用的算法进行解码:

我们可以看到预期内容是一个闪存文件，然后加载：

“解码”功能

函数“解码”是从包“com.google”包中的：

完整的反编译代码可用在这里．

当我们看内部时，我们看到代码略微混淆：

看着解散的代码，我们看到一些有趣的常数。例如，十六进制的-889275714是0xCafeBabe。我们发现期间其他隐藏蜜蜂元素的分析，这个DWORD以前被相同的作者用作标识一种自定义格式的神奇数字。

在内部，有对另一个模块的函数的引用:E_ENCRYPT_process_bytes()。在这个函数中，我们看到调用建议兔子密码已使用:

Rabbit使用128位键(与前面提到的MD5哈希值长度相同)和64位初始化向量。(在不同的运行中，可能会选择不同的加密算法。)

在解码过程完成后，加载显示的内容：

第一个WAV: Flash漏洞

解码后的WAV包含一个包，其中嵌入了两个元素:Flash文件(movies.swf)和配置文件(config.cfg)。解密的数据从神奇的DWORD 0xCAFEBABE开始，这是我们在前面SWF的代码中注意到的。

Flash文件（Movies.swf）包含嵌入式漏洞。在分析的情况下，使用的漏洞利用是CVE-2015-5122但是，可以在不同的机器上使用不同的利用：

有效载荷（shellcode）以阵列的形式存储（此处可用的二进制版本：9 aec11ff93b9df14f060f78fbb1b47a2）：

配置文件（config.cfg）包含另一个WAV文件的URL。

负载是用NOP (0x90)字节填充的，包括配置在内的参数是在负载运行之前填充的。

shellcode：下载第二个WAV

与第一个相反，第二波始终下载并从未嵌入过。它由“PayloadWin32”shellcode检索（9 aec11ff93b9df14f060f78fbb1b47a2)，在成功开发后部署。

查看此Shellcode内部，我们发现负责下载和解密另一个WAV的功能。shellcode使用上一层填充的参数。此缓冲区包含将查询的URL以及将用于解密有效载荷的密钥。它使用其校验和加载来自Wininet.dll的函数。初始化步骤后，它会查询提供的URL。预期结果是带有典型的WAV文件的缓冲区。

正如我们已经怀疑的那样，WAV的数据（从偏移0x2C开始）包含加密内容。实际上，长度为8个字节的块在循环中解密：

解密完成后，将显示下一个模块。看看有关有效载荷的预期标题是有趣的，以了解输出元素的哪种格式。这次，解码数据应该从以下Magic数字开始：0x01，0x04，...，0x10。

第二个WAV：专有格式的可执行文件

在下面的插图上，我们可以看到WAV的数据如何在被解密后照明（9B37C9EC19A53007D450B9B9C8FEBBE2.）：

这是一个可执行组件，它被加载到Internet Explorer中。解码导入后，它开始看起来更熟悉：

我们可以看到，它遵循了去年文章中描述的一个类比结构。

此模块首先在Internet Explorer中执行。然后，它创建另一个处于挂起状态的进程(dllhost.exe):

它将它的原始副本注入那里(769A05F0EDDDD6EF2EBDD13618B244758）：

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

对该模块的执行流的详细分析及其格式将在文章稍后给出。

此时，重要的是要注意DLLHost.exe是进一步下载上述图像的模块。

自定义格式的模块

具有自定义格式的模块类似于该模块之前描述了．但是，我们可以看到它已经显着发展。

标题中有更改，以及实现的改进。

自定义格式的更改

新标题类似于前一个．改变的几个细节是：开始时的魔法号码（从0x1000开始0301 0 x10000401），存储DLL的格式（已添加DLL名称的长度）。这就是为什么我们将把这种格式称为“0x10000401格式”。

另一个变化是dll的名称现在被一个带有1字节字符的简单XOR混淆了。它们在加载之前被消除模糊。

总结，我们可以按以下方式可视化新格式：

使用混淆

这次，作者决定使用模块内使用的所有字符串混淆。现在，所有字符串都在使用之前被解码。

译码算法简单，基于XOR:

里面的图像下载

让我们在我们遇到的0x10000401格式内查看第一个模块。此模块是初始阶段，其角色是下载和解压缩其他组件。一个这样的组件是以驾驶本格式（这就是为什么我们可以在导入的DLL中看到Cabinet.dll）。

该模块的作用类似于我们一年前帖子中提到的第一个“WASM”。但是，当前版本不仅受到更好的保护，而且还具有一些改进。这次下载的内容隐藏在图像中。因此，分析此元素可以帮助我们了解使用的速膜术方式。

首先，我们可以看到url是从它们的Base64表单中检索的:

这个字符串解码为一个包含将要下载的PNG和JPG文件的url的列表。对于每个样本，这个集合是唯一的。所有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=357e27e8af72925144C1DB2421D0CC5 
          

          
因此，我们可以确认此模块是负责下载和处理观察图像的模块。实际上，里面我们可以找到负责他们解码的功能。
          
解码jpg.
          
检索有效载荷后，验证JPG报头。
          

           
          
          
然后，通过简单地使用具有最后一个字节的XOR来解码有效载荷。预计解码的内容将从！RCX Magic ID开始。
          

           
          
          
在解码内容后，在SHA256哈希的帮助下验证了！RCX模块的散列。有效的哈希存储在模块的标题中，并与文件内容的计算散列进行比较。
          

           
          
          
如果验证传递，则加载存储在！RCX模块中的shellcode。有关执行流程的更多详细信息将稍后给出。
          

           
          
          
！rcx包有一个简单的标题：
          

           
          
          
解码PNG
          
从PNG中检索内容更为复杂。
          

           
           
          
          
首先，下载后，检查PNG头:
          

           
          
          
解码PNG的函数具有以下流程：
          

           
          
          
它将PNG转换为字节内容，并借助咏叹调密码．结果应该是驾驶本格式。未包装的驾驶室应该包含一个模块“bin / i386 / core.sdb”，这些模块也发生在我们之前的隐藏蜜蜂的遭遇中。
          
作者小心不要重用URL以及加密密钥。这就是为什么Aria键对每个唯一有效载荷不同。它只是在0x10000401模块结束后存储：
          

           
           
          
          
在模块加载期间，密钥被重写到另一个内存区域，从那里它被用来解密下载的模块。
          

           
          
          
从PNG中检索的CAB文件在这里可用:001年bdc26b2845dcf839f67a8760c6839
          

           
          
          
它包含核心。深发展(D1A2FDC79C154B120A0E52C46A73478D）.这是Hidden Bee自定义格式的第二个模块。
          

           
          
          
内部Core.SDB.
          
这个模块(从PNG中检索)是第二个0x10000401格式的下载器组件。这一次，它使用了一个基于tcp的自定义协议，作者将其称为SLTP。(一年前的类似成分也使用了这个方案)。嵌入式链接:
          
sltp：//dns.howtocom.site：1108 / minimal.bin？ID = 998sltp：//bbs.favcom.space：1108 / setup.bin？ID = 999
          
执行流程
          

           
检查列入黑名单的过程。如果有，则退出。
           
删除功能:dbgebreakpoint.那DbgUserBreakPoint通过用RET指令覆盖它们的开头。
           
检查是否已安装恶意软件。如果是，退出。
           
创建一个安装互斥锁{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}}。
           
如果模块使用标志== 1运行：

             
连接到第一个地址：sltp：//dns.howtocom.site：1108 / minimal.bin？ID = 998
             
设置环境变量install_source.作为论据给出的值。
             
运行下载的下一个阶段模块。
            
           
如果模块是用标志运行的!= 1:

             
对VM进行检查。如果检测到,退出。
             
连接到第二个地址：sltp：//bbs.favcom.space：1108 / setup.bin？ID = 999．这次，将受害者的指纹附加到URL。格式：＆SID = ＆sz = <唯一机器ID：16字节十六进制>＆OS = ＆AR = <架构>
             
运行下载的下一个阶段模块。
            
          
          
防御性的检查
          
在此阶段，部署了许多反分析检查。首先，检查是否有任何黑名单的进程运行。使用低级功能实现进程的枚举：NtQuerySystemInformation参数5（SystemProcessInformation.）.
          

           
          
          
黑名单包含热门的调试器和嗅探器：
          
" devv .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 "
          
进程的名称被混淆了，所以它们在字符串列表中不可见。如果检测到其中任何一个进程，则模块的执行将终止。
          
另一个功能部署了一组防VM检查。反VM支票包括：
          

           
          
          
eax = 40000000的CPUID（检查Hypervisor的品牌）：
          

           
          
          

           
          
          
VMware I / O端口（更多详细信息[在这里):
          

           
          
          
VPCEXT指令(详情[在这里]）
          

           
          
          
检查公共VM供应商的列表：
          

           
          
          
检查虚拟环境典型的BIOS版本：
          

           
          
          
检测建议VM的任何特征导致组件终止。
          
下载新模块
          
HiddenBee的下一个元素是通过自定义“STLP”协议下载的。
          

           
          
          
为使用SLTP协议通信而创建的原始TCP套接字:
          

           
          
          
通信已加密。我们可以看到预期的输出是加载和执行的shellcode：
          

           
          
          
装载的方式让我想起了我们最近描述的元素“隐藏的蜜蜂:我们去兔子洞吧”。当前模块加载将传递给下一个模块的函数列表。这是一个简单的，自定义版本的导入表。它还将下载的文件系统传递给用于进一步加载组件的内存。
          
！rcx包
          
此元素检索此恶意软件使用的自定义文件系统。正如我们从以前的分析所知，隐藏的蜜蜂使用它自己的自定义文件系统，该文件系统被安装在恶意软件内存中并传递给其组件。此文件系统对于执行流程很重要，因为它包含许多应该在攻击系统上安​​装的许多其他组件，以便继续感染。
          
如前所述，解包JPG给了我们一个！RCX包。下载此包后，其SHA256校验和验证，它将重新包装。首先，在！RCX包的末尾，复制来自上一个模块的URL列表（jpg，png）列表。然后，aria键被复制。更新模块及其SHA256哈希的大小。然后，将执行重定向到从！RCX获取的第一级shellcode。
          
这个shellcode是我们最初看到的，在从JPG解码!rcx包之后。然而，从这部分来看，我们并没有看到任何恶意。更重要的元素将在接下来的执行阶段得到很好的保护和显示。
          
来自！RCX包的shellcode以两个阶段执行。第一个解压缩并准备第二个。首先，它使用库的硬编码名称加载自己的导入。
          

           
          
          
将使用的功能的校验和存储在模块中，并与函数计算的名称进行比较：
          

           
           
          
          
它使用来自kernel32.dll的函数：getProcessheap，VirtualAlloc，VirtualFree以及ntdll.dll：rtlallocateheap，rtrlfreeheap，ntqueryInformationProcess。
          
重新打包的!rcx模块应该作为第一个shellcode的入口点的参数之一提供。这是最重要的，因为第二阶段的shellcode将从提供的!rcx包中解包。
          

           
           
          
          
分配一个新的内存区域，并在那里解压缩第二阶段shellcode。
          

           
           
          
          
在第二个shellcode中，我们看到字符串引用隐藏蜂恶意软件的其他组件：
          
/ bin / i386 /预加载
/bin/i386/coredll.bin
          
第二阶段的作用是从!rcx: an !rdx包中解包另一部分。
          

           
          
          

           
           
          
          
根据我们以前的经验，我们知道!rdx包是一个包含模块的自定义文件系统。实际上，在解密完成后，自定义文件系统就会显示出来:
          

           
          
          
因此，隐藏在JPG文件中的部分实际上是一个包，它解密自定义文件系统并部署下一阶段的模块:/ bin / i386 /预加载和/bin/i386/coredll.bin．此文件系统具有更多元素，该元素在稍后的感染阶段加载。他们的系列中的下一篇文章将描述它们的全功能。
          
更加隐藏
          
从一开始，隐藏的蜜蜂恶意软件就经过了良好的设计和创新。回顾它一年的发展历程，我们可以肯定作者们是认真地想让它更隐秘——而且他们没有停止改进它。
          
尽管最初的droper使用的组件类似于过去观察到的组件，但现在要揭示他们的加密内容需要更多的步骤和更多的耐心。分析中的额外困难是由于url和加密密钥从来没有被重用，并且只对单个会话有效。
          
这个恶意软件背后的团队技术娴熟，意志坚定。我们预计“隐藏蜜蜂”恶意软件不会很快灭绝。