帮助众多恶意软件逃避检测：针对一款Delphi加壳器的分析

 

概述

为了绕过静态或动态分析工具，恶意软件往往会使用加壳或加密的方法，这样的方法已经被恶意软件开发者广泛使用。然而目前，恶意软件使用多种新型技术，不断尝试逃避分类和检测，而反病毒产品则不断扩充自己的样本库，二者间实际上已经在进行着一场“军备竞赛”。例如，我们发现在地下论坛提供了许多加密服务，他们声称所制作的恶意软件，完全无法被反病毒产品、沙箱或其他终端解决方案检测到。与此同时，我们还看到安全产品在对正常的用户行为数据进行建模，并尝试着将其作为识别恶意软件特征的一种有效方案。

 

Delphi加壳

我们所分析的样本，带有Delphi的签名（如下图所示），与使用IDR（Interactive Delphi Reconstructor）分析时的Delphi代码构造一致。

借助Delphi编程语言，我们能够轻松编写使用Windows API函数的应用程序或项目。实际上，一些恶意软件编写者使用默认库进行伪装，试图妨碍静态分析的转移过程，并试图使应用程序在动态分析中“看起来合法”。下图就是在某论坛中讨论这种技术的一篇帖子。

 

恶意软件的分发

我们观察到，目前存在具有多个不同主题的恶意邮件，会分发使用这一加壳器进行加壳的Payload。

其中的一个典型例子是电汇恶意邮件，邮件中会包含一个文档文件作为其附件（哈希值：71cd5df89e3936bb39790010d6d52a2d）。在该文档中，包含一个恶意宏，也就是其Payload。恶意邮件的内容如下图所示。

另一个比较典型的例子，是询问报价主题的恶意邮件，它以一个包含漏洞利用的文档作为附件（哈希值：0543e266012d9a3e33a9688a95fce358），该文档利用公式编辑器存在的漏洞来投放Payload（如下图所示）。

这一示例中的文档，会从http[://]5[.]152.203.115/win32[.]exe的位置获取Payload。经过分析，其Payload实际上是Lokibot恶意软件。

 

对用户活动进行检查

加壳器需要尽量确保它不是在分析环境中运行。一般来说，计算机用户在一段时间内就会更改一些应用程序的窗口大小（包括移动位置、缩放等）。因此，该加壳器的第一个变种会首先调用GetForegroundWindow API检查是否用户已经更改窗口大小3次以上，如果没有，则不会执行任何功能。这一部分的代码如下图所示。有趣的是，通过这样简单的技术，其实就可以防范一部分常用的沙箱。

为了确认用户的活动，加壳器的第二个变体使用GetCursorPos和Sleep API检查鼠标光标移动，而第三个变体使用GetLastInputInfo和GetTickCount API检查系统空闲状态。

 

从PE资源中提取实际Payload

原始Payload被拆分成多个二进制Blob，并存储在资源目录的各个位置，如下图所示。

为了定位并组装实际Payload的字节，加壳器代码首先直接从资源段内的硬编码资源ID读取内容。它的前16个字节形成一个XOR密钥，用于使用滚动XOR（Rolling XOR）解密其余字节。解密的字节实际上表示内部数据结构，如下图所示。加壳器使用它，来引用各种资源ID的加密和混淆缓冲区。

然后，加壳器从加密缓冲区中读取值，从dwStartResourceId开始，直到dwStartResourceId+dwNumberOfResources，同时通过读取dwChunkSize块中的内容，将其存储到一个特定的位置。当最终的数据缓冲区准备完成后，会使用前面提到的滚动XOR算法，以及上述结构中新的密钥，对其进行解密，从而生成核心Payload可执行文件。这个脚本可用于静态提取实际的Payload。

 

恶意软件真实的家族分类

我们对样本中的二进制文件进行提取并去壳，最终它们都被识别为Lokibot恶意软件家族。此外，我们还发现了Pony、IRStealer、Nanocore、Netwire、Remcos和nJRAT恶意软件系列，以及一些加密货币挖掘恶意软件。使用该加壳器的恶意软件家族分布如下图所示。由于恶意软件的种类比较多样，所以也就意味着有很多恶意软件开发人员都在使用这种“加密服务”或“加密工具”，以试图逃避反病毒机制的检测。

 

结论

这些加壳和加密服务，无疑是为恶意软件开发人员提供了一种简单方便的选择。他们可以将保护真正Payload的这部分工作外包出去，并且获得非常有效的结果。我们所分析的加壳器采用了反分析技术，从而尝试绕过沙箱。针对于此，如果研究人员能在模拟真实用户行为的沙箱环境中对恶意软件进行分析，那么无疑这样的机制就会变得不再有效。

 

IoC

853bed3ad5cc4b1471e959bfd0ea7c7c
e3c421d404c08809dd8ee3365552e305
14e5326c5da90cd6619b7fe1bc4a97e1
dc999a1a2c5e796e450c0a6a61950e3f
3ad781934e67a8b84739866b0b55544b
b4f5e691b264103b9c4fb04fa3429f1e