DDG.Mining.Botnet：一个瞄准数据库服务器的挖矿僵尸网络

从 2017-10-25 开始，我们监控到有恶意代码在大规模扫描互联网上的 OrientDB 数据库服务器。进一步的分析发现，这是一个长期运营的僵尸网络，其主要目标是挖取门罗币（XMR，Monero CryptoCurrency）。我们将其命名为DDG 挖矿僵尸网络（DDG Mining Botnet，以下简称 DDG） ，主要原因是因为其核心功能模块的名称为 DDG。

DDG 累积挖取的门罗币数目较大。目前我们能够确认该僵尸网络累积挖取的已经超过3,395枚门罗币，按当前价格折合人民币 ￥5,821,657。另外因为矿池记账系统的问题，有2,428枚 XMR不能完全确认是否归属 DDG，按当前价格折合人民币 ￥4,163,179。DDG 是目前我们视野范围内门罗币收益第二大的僵尸网络，第一大的是我们之前报告的MyKings僵尸网络。

DDG 的结构上，除了僵尸网络中常见的 C2 和 bot，还有一个很有意思的 HUB 的设定。HUB 是一组 IP或者域名，用来提供挖矿二进制程序的下载。在 DDG 持续的更新过程中，其 v2011 版本的 HUB 列表中，有两个域名被列出但是未被注册，我们抢先注册并Sinkhole了这两个域名。虽然我们不可以通过这两个域名 Sinkhole 来接管该僵尸网络，但是可以基于 Sinkhole 数据对整个 DDG 僵尸网络的规模做一个精确的度量。

DDG Mining Botnet 的挖矿收益

DDG 在挖矿时使用如下矿池地址：

https://monero.crypto-pool.fr/

其使用的钱包地址有三个，如下：

Wallet #14AxgKJtp8TTN9Ab9JLnvg7BxZ7Hnw4hxigg35LrDVXbKdUxmcsXPEKU3SEUQxeSFV3bo2zCD7AiCzP2kQ6VHouK3KwnTKYg

Wallet #245XyPEnJ6c2STDwe8GXYqZTccoHmscoNSDiTisvzzekwDSXyahCUmh19Mh2ewv1XDk3xPj3mN2CoDRjd3vLi1hrz6imWBR1

Wallet #344iuYecTjbVZ1QNwjWfJSZFCKMdceTEP5BBNp4qP35c53Uohu1G7tDmShX1TSmgeJr2e9mCw2q1oHHTC2boHfjkJMzdxumM

其中，Wallet #3 是最先开始活跃的钱包地址，高峰期在 2017.02～2017-03；随后是 Wallet #1，持续了2017一整年； Wallet #2 是最近出现的，我们首次观察到的时间是 2018-01-03。

全部三个钱包的收入如下表所示，共计收入 3395 或者 5760 的门罗币，这些代币今天价值人民币580万或者980万。注意：在第二个钱包付费记录中，"Total Paid"与逐笔交易累积得到的 "Amount Summary" 并不一致，我们无从确认哪个数字更准确，因此把两个数字都记录了下来。

DDG Mining Botnet 的攻击阶段和结构划分

通过分析样本及其行为，我们能够描绘 DDG Mining Botnet 的攻击过程如下：

上图中，DDG Mining Botnet 的攻击过程可以分为几个阶段：

扫描阶段：攻击者（ ss2480.2 ）利用 OrientDB 数据库的已知 RCE 漏洞，投入攻击载荷；

第一阶段：攻击者修改本地 Crontab 定时任务，下载执行主要服务器上的 i.sh ( hxxp://218.248.40.228:8443/i.sh) ，并保持每 5 分钟同步。此 i.sh 会继续从同一服务器上下载运行 ddg 样本

第二阶段：ddg 会依次连接内置hub_iplist.txt文件里的 hub_ip，然后从可以成功连接的 hub_ip 上下载对应的 Miner 程序 wnTKYg（如果本机 CPU 不支持 AES-NI，还会下载 wnTKYg.noaes）。这个程序的命名，恰好是其钱包地址的尾部。

挖矿阶段：Miner 程序开始与矿池通信，利用失陷主机的计算资源，为攻击者的钱包开始挖矿。

上述结构中，除了僵尸网络中常见的 C2 和 bot 以外，还有一个很有意思的HUB。攻击者使用 HUB 上的多个IP或者域名来提供挖矿程序的下载。我们观察到 DDG 运营者会不时更新这些 HUB 的IP和域名，来源大部分是失陷主机。全部的 HUB 列表见文末。

关于这个HUB另一个有意思的地方，是我们注意到 v2011 版本中三个域名中的两个在当时是未注册的，如下。这两个域名被我们注册并 Sinkhole，后来我们意识到，我们可以通过这两个 HUB Sinkhole 上的到的数据来精确度量整个 DDG 僵尸挖矿网络。

defaultnotepad567[.]com

unains1748[.]com 未注册

5dba35bsmrd[.]com 未注册

下面我们分别介绍 DDG 僵尸网络的 C2， HUB， 和 Bot。其中 Bot 部分的数据，会使用来自Sinkhole 的数据。

DDG 僵尸网络的 C2

DDG 僵尸网络使用如下 C2 保持对设备的长期控制：

202.181.169.98:8443/i.sh

218.248.40.228:8443/i.sh

其中后者来自印度，AS9829，一直在使用，两年来没有变过；前者来自中国香港，AS7540，仅在早期短暂使用。

DDG 僵尸网络的 HUB，以及我们的 HUB Sinkhole

DDG 僵尸网络使用HUB_IP:8443\wnTKYg提供挖矿程序下载。我们监控到的两个版本的 HUB 详细列表见文末 IoC 部分，其国家分布如下表所示。可见大部分受害者位于中国。

如前所述，我们在监控其 v2011 版本的时候，发现其中两个域名没有注册，unains1748[.]com 和 5dba35bsmrd[.]com 。我们注册了这两个域名，合并到我们的 Sinkhole 池中，并几乎立刻看到有 IP 开始连接这两个域名，后来我们确认来连接的这些 IP 均是被 DDG 感染的主机。

这样至少我们可以利用 HUB Sinkhole 来度量 DDG 的规模。那么，我们的 Sinkhole 能看到 DDG 僵尸网络的多大部分呢，是盲人摸象看到一部分？还是全部？

我们仔细检查了 DDG 的运行机制，并且确认无论被感染的 bot 最终从 HUB 上的哪个部分下载挖矿程序，这些 bot 都会检查 HUB 上的全部 IP 和域名的连通性。这意味着，我们可以看到 DDG 全部的被感染设备，并进一步利用这些数据对 DDG 僵尸网络做精确的度量。

可惜的是，我们注册 Sinkhole 的行动被 DDG 运营者发现了，他们随后发布了 DDG 的更新版本，更新了全部的 HUB IP列表，将我们的 Sinkhole 从僵尸网络内部踢了出来。

另外一方面，从 bot 的代码逻辑来看，创造合适的条件，会使得被感染的 bot 尝试从我们的 sinkhole 下载并运行挖矿程序....嗯，这个话题我们就讨论到这里，白帽子一定要带头做遵纪守法的好公民。

DDG 僵尸网络的 Bot

我们可以使用 HUB Sinkhole 的数据来精确度量 DDG 僵尸网络的感染规模。为避免滥用，全部受害者 IP 列表不会公开。

我们共记录了4391 个受害者IP地址，来自各个国家，最主要的受害者集中在中国(73%)和美国(11%)：

从网络自治域分布来看，国内各主要云计算服务商均有出现，国外若干互联网巨头公司也有少量中招。总体来看，因为 DDG 投入时是利用数据库服务器的错误配置或者漏洞利用，云服务厂商既往确实不容易防范。建议后续云服务厂商考虑加强这方面的防御措施。

受害者一段时间内对上述 2 个域名的 DNS 请求趋势如下。尾部曲线快速下降，对应僵尸网络运营者更新版本的时段。

利用 DNSMon 感知这三个域名的异常访问

我们的 DNSMon 也感知到了这三个域名的异常，下面两张图分别展示这三个域名流量访问曲线高度拟合，并且在访问时序上有强烈的相关性：

DDG Mining Botnet 攻击过程详细剖析扫描

DDG Mining Botnet 的扫描和入侵阶段由样本 ss2480.2 完成。ss2408.2 首先会根据一定策略生成 Target IP 并扫描 Target IP 的 2480 端口，最后会利用 OrientDB 的 RCE 漏洞CVE-2017-11467实施入侵。

ss2480.2 会先扫描内网网段，然后扫描公网网段。生成的内网网段 Target IP 范围如下：

10.Y.x.x/16 (Y 为当前内网 IP B 段的值)

172.16.x.x/16

192.168.x.x/16

样本中生成内网 Target IP 的部分代码如下：

结束对内网的扫描之后，ss2480.2 会访问 hxxp://v4.ident.me 获取当前主机的公网 IP 地址WAN_IP，然后在范围内生成公网 Target IP 发起扫描。样本中生成公网 Target IP 时，会过滤掉保留地址段：

ss2480.2 利用 OrientDB 漏洞的过程如下：

样本利用漏洞最后执行的 Payload 如下：

第一阶段

DDG 在 C2 （218.248.40.228 India/IN AS9829）上提供了云端配置文件： hxxp://218.248.40.228:8443/i.sh

该 i.sh 配置文件有多次变化，但是内容大同小异。下面是一个早期版本，其功能主要是：

将本地 Crontab 内容与远程服务器上的 i.sh 保持同步

从远程服务器下载 ddg 样本到本地并执行

检查本地的 ddg 的历史版本进程，并杀掉

由 i.sh 脚本内容可知，攻击者只需更新其中的样本下载地址，便可以灵活地向失陷主机投放任意恶意软件。根据我们的监控，该云端配置文件确实会不定时更新，用以投放新版木马文件，或者投放集成新的攻击方式的恶意软件。其投递的恶意软件包括：

DDG 样本：即 ddg.$(uname -m) 系列样本，这是长期投递的攻击载荷，我们监测到 v2011、v2020 和 v2021 共 3 个大版本

ss22522系列样本：短时间内投递过，针对Struts2 漏洞 S2-052

ss2480系列：短时间内投递过，是针对 OrientDB 漏洞的攻击样本，正是这个样本在短时间内的大规模扫描暴露了自己

另外，早期版本中 kill 命令前面没有 xargs，进程并不会真正被杀死，在后期版本上这个 xargs 被加了进去，修复了这个问题。

2018.1.3 日，攻击者上线了最新的 i.sh(v2021.2)，新增了另外一个挖矿木马imWBR1，正是该木马中内置了前文列出的第二个 XMR 钱包地址 :

第二阶段

ddg 样本中内置了一个hub_iplist.txt文件，其中包含了上百个的列表。经我们排查，这些 hub_ip 对应的主机，多是常规网站服务器，都被攻击者入侵而沦为攻击者的肉鸡。

在这个阶段，ddg 会依次尝试连接 hub_iplist.txt 里的 hub_ip，如果成功连接某个 hub_ip ，ddg 就会访问下载对应的 Miner 程序 wnTKYg 并启动（如果本机 CPU 不支持AES-NI，还会下载wnTKYg.noaes）。ddg 尝试连接 hub_ip 的过程抓包如下：

ddg.xxx 与 ss2480.xxx 样本均由 Golang 编写而成。ddg 与 hub_ip 通信，通过一个 Golang 第三方 Stream Multiplexing 库Smux完成。ddg 用了 Smux 的默认配置：

所以在 ddg 从 hub_ip 下载 Miner 并启动后的KeepAlive阶段，就会每隔 10s 向已连接的 hub_ip 发 2 个数据包：

样本中内置的 hub_iplist.txt

i.sh 文件中的 ddg 样本下载 URL 是。ddg 文件V2011内置的 hub_iplist.txt 中有 158 个 hub_ip:8443 和 3 个 hub_domain:8443 列表，其中 2 个 Domain 未注册，然后被我们注册并 Sinkhole。

DDG Mining Botnet 的攻击目标，还曾瞄准 Redis 数据库与 SSH 服务

以上分析中，DDG 的攻击目标集中在 OrientDB 上。

事实上，ddg 木马中的系列样本还可以对 SSH 服务和 Redis 服务发起扫描&暴破攻击，这也是 ddg 一直以来入侵用户主机的主要手段。样本中内置的部分相关函数以及暴破字典如下两图所示：

样本中还有内置的 3 个 x509 证书 / 密钥文件如下：

详细内容见文末 IoC 部分。

回溯历史数据时，我们还能看到 i.sh 的 host 218.248.40.228 在更早期扫描 Redis 数据库的痕迹。互联网上也偶尔会有受害者曝光自己服务器中了 ddg 木马被用来挖矿。 下表是 218.248.40.228 在 2017-09-27 20:00:00 ~ 2017-10-25 11:00:00 期间扫描端口的分布情况。

按照扫描次数排序，6379, 7379，2480, 三个端口分别 Redis, Redis(Replicas), OrientDB 数据库服务：

近况

北京时间 2018.1.25 日 21 点左右，的样本更新，MD5 为cbc4ba55c5ac0a12150f70585af396dc，是一个 Mirai 家族的样本。

Mirai C2 为。

另外一个硬编码明文 C2目前在在DNS系统中没有配置解析IP地址。

IoC

C2:

样本 MD5: