概述

DorkBot是一种已知的恶意软件，最早可以追溯到2012年。它被认为通过社会媒体链接、即时消息应用程序或受感染的可移动设备等多种方式进行传播。尽管它是众所周知的恶意软件家族中的一员，但我们相信已经有更多的网络感染了Dorkbot，而且超过了我们之前的预计，其中受影响最大的国家是斯里兰卡、印度和俄罗斯。

 
Dorkbot感染的地理分布

恶意软件本质上是一个通用的下载器和一些二进制组件的启动器，主要模块是用于执行DDoS攻击或窃取密码。此次的分析是基于在过去一个月中多次捕获到的一个在野样本。 

DorkBot恶意软件被打包在一个dropper中，其中payload被嵌入到一个RC4加密的blob(二进制大对象)中。这个blob可以在二进制编码的资源部分中找到，并且使用Base64编码。

 
图1: Base64 编码computer_name>#calculated_md5>”格式的ID，其中第二个参数是系统信息缓冲区的MD5哈希，其结构如下:

在运行时可以看到这种结构的一个例子: 

 
图 5: 用于计算Machine ID的hash值的缓冲区结构

计算GUID：恶意软件中的大多数对象(事件、互斥、文件名等)都是基于生成的GUID来命名的，此次的GUID按照如下方式构建(基于前面提到的系统信息结构，当前进程所有者的SID和一个key作为参数传递给GUID生成函数):

DWORD Data1: MD5(sysinfo)[0..3] xorkey
DWORD Data2|Data3: MD5(sysinfo)[4..7]xor key
DWORD Data4[0..3]:MD5(sysinfo)[8..11] xor CRC32(user_SID)
DWORD Data4[4..7]:MD5(sysinfo)[12..15] xor CRC32(user_SID)

APC注入：创建一个挂起的进程，将恶意软件的内存映射注入进去，将其主线程的控制函数（接下来要叙述的）作为一个APC队列，并恢复其主线程。因此，上述函数开始运行在svchost.exe进程中。 

工作线程控制函数:该函数包含恶意软件的主要功能，以线程的形式调用各种功能。预计这个函数将会在前面提到的APC注入后的宿主exe中运行，如果失败，将在当前进程的上下文中运行。然而由于代码中出现的一个bug，后者将不会在现实中发生。在进程句柄关闭后，正在启动的svchost.exe主线程句柄也会关闭。这会导致进程崩溃，从而避免进一步的恶意活动。 

函数本身的行为如下:

Ø PE加载操作，即进行重定位操作以及解析导入的恶意软件映射的执行。

Ø 创建一个隐藏的计划任务(使用ITask COM类)，该任务设置为在当前用户的登录时启动。

Ø 创建注册表runkey,在HKCM\Software\Microsoft\Windows\CurrentVersion\Run。键的名称是预先生成的GUID，路径为复制到%appdata%下的恶意文件。

Ø 在一个单独的线程中删除原始的恶意软件文件(除非当恶意软件从一个非移动介质运行，并成功地注入到exe)。

如果恶意软件是由可移动的媒体执行的，它将在HCKU\Software\Classes\CLSID下注册一个指定的类，类名是GUID，键值为0xDEADBEEF。

 
图6：恶意软件注册一个类

文件修改监控:一个线程会不断地计算%appdata%下复制的恶意二进制文件的CRC32，并将其与原始文件的CRC32进行比较。一旦发生变化，复制文件会被删除，并将其重写为原始文件的内容。

 
图7: 文件更改监视器代码

替换快捷方式:遍历所有安装的驱动器（通过GetLogicalDriveStringsW获取）并枚举所有文件，以找到具有“.lnk”扩展名的文件。如果找到这样的文件，则通过以下参数去执行exe去修改目标路径（使用IPersistFile COM类）：

Ø 由恶意软件生成的包含恶意软件副本的路径。

Ø 枚举文件的路径，它将通过执行恶意软件本身来调用。

注入进程监控代码:该恶意软件将枚举所有正在运行的进程，并排除64位进程、当前进程和运行名为“teamviewer.exe、tv_w32.exe”的进程。

 
图8:将TeamViewer排除在注入的目标进程之外。

所有其他进程(以及恶意软件创建的notepad.exe进程)将被注入以下代码:

 
图9:注入进程监视代码

指针0x11111111、0x22222222、0x33333333和0x44444444将在注入函数之前被替换，如下所示:

 
图10: 在进程监视payload中把无效指针替换成真实的函数指针

注入的代码本身将无限期地等待一个事件，当原始的恶意软件进程被终止时，信号量将会被释放。当出现这种情况，注入的进程监控代码将会再次启动恶意软件。

l通信:所有C2域名都存放在一个以AES256-CBC加密的blob二进制文件中，排列成一个指针列表，在.data区段偏移16的位置中可以找到。

 
图11：被加密的CnC域名表

解密的密钥为“GD!brWJJBeTgTGSgEFB/quRcfCkBHWgl”。

 
图12:CnC域名的解密函数

在恶意软件中可以观察到以下类型的通信:

Ø HTTP GET 请求一个文件从样本的C2服务中。C2将通过“v%d”格式的子域进行联系，其中的%d数值是从运行时的全局变量中获取。如果从服务器成功返回一个文件，那么它将一10字符的随机数命名存在在%appdata%下，并使用CreateProcessW启动。

注意：其他变种的恶意软件可能使用不同的子域名，例如“up%d”。

Ø 基于TCP的原始协议，用于获取可从中下载文件的新CnC地址。协议请求消息是一个包含170个字节的缓冲区，具有以下结构:

 
图13:请求CnC的原始协议结构

响应包由517字节组成，具有以下结构:

 
图14:来自CnC的响应包

IOCs

153a3104fe52062844fed64c7a033d8378f7977f– Dropper 
0cf0f00b7c78d68365b4c890c76941051e244e6f– Unpacked

*参考来源：checkpoint，由三五年后编译，转载请注明来自FreeBuf.COM