导语:在本文中,我们将深入研究Avzhan DDoS机器人功能,并将捕获的样本与过去描述的样本进行比较。

2010年以来,Avzhan DDoS机器人一直被人们所知,但最近我们又在野外看到了它,中国的路过式攻击(drive-by attack)可以将其删除。在本文中,我们将深入研究其功能,并将捕获的样本与过去描述的样本进行比较。

分析样本

· 05749f08ebd9762511c6da92481e87d8——主要样本,被开发工具包删除

· 5e2d07cbd3ef3d5f32027b4501fb3fe6——打开(Server.dll)

· 05dfe8215c1b33f031bb168f8a90d08e——2010年的版本(参考样本)

行为分析

安装

部署完该恶意软件之后,它会以一个随机的名字将自己复制到一个系统文件夹中,然后删除原始样本:

1.png

其实现持久性的方法是通过假冒一种Windows服务对自身进行注册。当然,此操作需要管理员权限,这意味着为了实现成功安装,样本必须提高权限运行。bot没有UAC旁路功能,所以它只能依靠一些外部滴管、使用漏洞利用或社会工程。

添加注册表键的样本,与注册一个新的服务有关:

2.png

我们也在已安装的服务列表中发现了该恶意软件:

3.png

有趣的是,这个被删除的主要样本也被另一个恶意软件感染,Virut是一个非常古老的家族(并且在64位系统上崩溃)。一旦部署完成,它就开始感染磁盘上的其他可执行文件。关于Virut的更多内容,我们将在另一篇文章中讨论。

络流量

我们可以看到该bot连接到它的CnC:

41.png

检查网络流量,我们发现了发送的信标。它是一种二进制格式,并包含收集的关于受害者系统的信息:

4.png

这里的信标与Arbor Networks描述的2010的一个信标非常相似。服务器响应的是单个NULL字节。

在实验期间,我们没有捕获由该bot执行的与典型DDoS活动有关的流量。不过,通过代码我们可以清楚地看到它具有这些功能。

样本内部

阶段1:加载程序

样本是以一种打包的形式传播的。主要样本的原始名称是Cache.dat,其输出一个函数:lp

5.png

Ip内部,我们可以很容易地看到该函数创建一个变量、用字符串填充该变量,然后返回该变量:

6.png

这些都是我们在行为分析中观察到的相同的参数。例如,我们可以看到服务名是“Nationalscm”并且被引用的服务器,可能的CnC:wm.shiquanxian.cn:8080(可以解析为:103.85.226.65:8080)。因此,很可能是该函数负责填充这些参数并进一步传递这些参数。

该可执行文件的主要功能是混淆,并且代码流很难遵循——该代码流是由一些通过跳转指令连接的代码小块组成,这些跳转指令中被添加了垃圾指令:

7.png

然而,就在函数Ip下面,我们发现另一个看起来可读的函数:

8.png

通过其特性,我们可以看到它是一个很好的候选函数,在之后的过程中该函数可以解包并安装payload:

1 它需要一些硬编码的缓冲区并对其进行处理,这看起来像是对payload进行了混淆处理。

2 它在未打包的payload的输出表中搜索函数“StartupService”,它给我们提示,未打包的内容是一个PE文件。

3 最后,在payload中调用找到的函数。

我们可以通过在调试器下观察执行来确认这一点。在解码函数被调用之后,我们看到缓冲区变成了一个新的PE文件:

9.png

此时,我们可以转储缓冲区,对其进行修剪,并单独分析它。事实证明,该缓冲区是bot的核心,执行所有的恶意操作。PE文件是原始格式,因此不需要进行映射。此外,加载器将分配另一个内存区域,并且在该内存区域将payload映射到Virtual Format,以便该payload可以执行。

反转储技巧

该恶意软件使用了几个技巧来避免自动转储。首先,加载的payload与页面的开头没有对齐:

10.png

如果我们此时转储,我们还需要取消映射(即通过pe_unmapper),因为此时payloadVirtual Format中。然而,也有一些令人不快的意外:加载器使用完重新定位表和资源后,二者就被删除。这就是为什么在映射之前转储payload通常更可靠。然而,payload中的一些数据可能也会被加载。因此,如果我们不把这两个版本都转储,可能会丢失一些信息。

2010年的版本中,最外层已丢失。该恶意软件是通过一个可执行文件传播的,这个可执行文件相当于从当前样本中取出的payload

阶段2:核心

按照前面提到的步骤,我们获得了名为Server.dll的核心DLL。并且发现该核心非常陈旧——该散列是一年多前第一次在VirusTotal上看到的。然而,当时并没有详细描述它,所以我认为它仍然值得分析。

11.png

相比之下,2010年的样本并不是一个DLL,而是一个独立的EXE。然而,通过字符串,以及在BinDiff的帮助下进行的比较,我们可以看到惊人的相似之处,这证明了核心并没有发生太大的变化。

执行流程

执行从导出函数——StartupServer开始。在开始的时候,该样本调用包含非ASCII码的OutputDebugStringA。有趣的是,该内容并不是随机的。之前在加载器中使用了相同的字节,即在payload中执行该函数之前。然而,其目的仍然是未知的。

12.png

该样本还试图检查当前的DLL是否已经由导出一个函数“lp”的主模块加载。如果是,就调用该函数:

13.png

正如我们所记得的,恰好具有该名称的函数是由外层导出的。该函数应该检索bot的配置,比如CnC地址和Windows服务名。在被检索之后,数据会被复制到bot的数据部分(配置会硬编码到bot)

在此之后,恶意软件将继续其主要功能。我们可以看到,检索到的数据和硬编码的数据后来被传递给了安装该服务的函数:

14.png

根据相应的注册表键的存在,恶意软件会区分这是第一次运行还是已经安装好了。根据这些信息,它可以采取不同的路径。

如果该恶意软件还没有安装,它将继续安装并退出:

15.png

否则,它将运行其主要服务功能:

16.png

主要的服务功能是负责与CnC的通信。它部署了一个线程,它读取命令并部署适当的操作:

17.png

功能

首先,该bot连接到CnC,并发送一个包含有关受害者系统的信息的信标:

18.png

收集的信息是详细的,包含处理器特性和互联网速度。在行为分析中这些数据被发送。

在成功的信标之后,它会部署主循环,在那里监听来自CnC的命令,解析它们,然后执行:

19.pngc

正如我们所看到的,恶意软件可以充当下载器——它可以从CnC提供的链接中获取并部署一个新的可执行文件:

20.png

CnC还可以推动主bot的更新,并指导bot将自己完全删除。

但是,最重要的功能是在几个不同的DDoS攻击中,可以远程部署到任何指定的目标上。CnC提供目标地址以及攻击ID

21.pngc

在为这些攻击准备的请求中,我们可以看到熟悉的字符串,其目的已经在2010年的报告中描述。我们可以看到畸形的GET请求:

22.png

作为替代,它可以使用一个有效的GET请求,例如:

23.pngc

泛洪函数被部署到一个新的线程中,并在循环中重复请求,直到启用了停止条件。例子如下:

24.png

结论

bot很简单,由一个不复杂的actor物件准备。从功能上看,多年来其变化也不大。唯一增加的功能是混淆恶意软件,并赋予其外部层添加配置的能力

源链接

Hacking more

...