Inside one xmrig botnet miner

This post is an extension of this article.!

I – Introduction
At the beginning of this year, after some daily IoC Feeds. I was interested in one Linux sample on hybrid-analysis! for two reasons :

First, it’s quite rare to see some stuff like this on public feeds.
Secondly, the POST requests were basics but it changed from what I read every day.

GET /includes/libraries/files.tar.gz
POST /includes/libraries/notify.php?p=wl

So by curiosity, I checked if there’s some additional information, and realized that was an open directory with interesting things.

At this moment, this meme summarizes my reaction :

II – Botnet Architecture!

A ) How C&C are chosen?
First of all, our attacker needs to find a server to host his configuration. After some quick search of the different campaigns, C&C are in reality vulnerable servers with ClipBucket 10 installed. Exploit is only designed to setup the server for further activities.

The first step of his setup is stored on /cache/ repository. There is some interesting data like a PHP file named “cookie.php“. It’s a simple webshell designed to appear if we put the parameter “tooeasy“, I guess its some hacking fantasy ¯_(ツ)_/¯ , so for fun, I decided to call this miner botnet “tooeasy”.

webshell

Another funny thing, the attacker puts “xmrig“, the Monero miner on it! It means even the C&C is used to mine for the attacker, It’s really greedy and risky to be spotted by the administrator of the server. When everything is done, the configuration to spread the miner is pushed on /include/librairies/ repository.

B ) Configuration
As shown above, there are only 5 files to spread and monitor the botnet :

1 – manager.sh
This shell script is the most critical file of the botnet, without it, nothing could work perfectly. It permits to push on the infected machine the miner, notify the C&C that everything is working or not.

I will not explain all technical interaction of it because it is already explained in the other article 13.

2 – files.tar.gz
This archive pushed on the victim server is composed of two files :

fs-manager
Our mysterious file is only working on x86-64 Architecture.

file fs-manager
fs-manager: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=559009c5c0b88e95225aab9ed30adb45e3c7e5ca, stripped
With just a simple string command, we can understand this is just in fact xmrig.

strings fs-manager
...
Usage: xmrig [OPTIONS]
Options:
-a, --algo=ALGO cryptonight (default) or cryptonight-lite
-o, --url=URL URL of mining server
-O, --userpass=U:P username:password pair for mining server
-u, --user=USERNAME username for mining server
-p, --pass=PASSWORD password for mining server
-t, --threads=N number of miner threads
-v, --av=N algorithm variation, 0 auto select
-k, --keepalive send keepalived for prevent timeout (need pool support)
-r, --retries=N number of times to retry before switch to backup server (default: 5)
-R, --retry-pause=N time to pause between retries (default: 5)
--cpu-affinity set process affinity to CPU core(s), mask 0x3 for cores 0 and 1
--cpu-priority set process priority (0 idle, 2 normal to 5 highest)
--no-huge-pages disable huge pages support
--no-color disable colored output
--donate-level=N donate level, default 5%% (5 minutes in 100 minutes)
--user-agent set custom user-agent string for pool
-B, --background run the miner in the background
-c, --config=FILE load a JSON-format configuration file
-l, --log-file=FILE log all output to a file
-S, --syslog use system log for output messages
--max-cpu-usage=N maximum CPU usage for automatic threads mode (default 75)
--safe safe adjust threads and av settings for current CPU
--nicehash enable nicehash support
--print-time=N print hashrate report every N seconds
-h, --help display this help and exit
-V, --version output version information and exit
...
more information here : VirusTotal 3

config.json
Linked with fs-manager, it’s the miner configuration file.

{{ "algo": "cryptonight", "av": 0, "background": true, "colors": false, "cpu-affinity": null, "cpu-priority": null, "donate-level": 2, "log-file": "xmrig.log", "max-cpu-usage": 85, "print-time": 60, "retries": 2, "retry-pause": 3, "safe": false, "syslog": false, "threads": null, "pools": [ { "url": "pool-proxy.com:8080", "user": "user", "pass": "x", "keepalive": true, "nicehash": false } ]}
If you want some additional information, these linked as below could help :

https://en.bitcoin.it/wiki/CryptoNight 2
https://cryptonote.org/cns/cns008.txt

3 – getsetup.php
when the attacker has the ability to have a shell on the infected machine, he makes a “curl” request with a specific argument to indicate which product he exploits :

X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "GET /includes/libraries/getsetup.php?p=PP HTTP/1.1" 200 2931 "-" "curl/X.XX.X"
getsetup.php is linked with manager.sh.

4 – notify.php
this file is used with a simple “curl” request to communicate with the C&C and permits to log the installation and the state of each infected machine. Also over the different campaigns, there is no evolution of it.

$line = '['.date('Y-m-d H:i:s').']'.($product?'['.strtoupper($product).'] ':'').' '.$ip.' ## '.$msg."\n";
$fp = fopen(‘log.txt’, ‘a’);

fputs($fp, $line);

fclose($fp);

5 – log.txt
As explained just above, this file logged just everything about the activity of the botnet.

SecondCampaignsecondcampaign1.png736x148 53.4 KB
B ) How victims are chosen?
All the victim are servers with a database hosted on it. Linux is the only operating system targeted by this botnet and with the description of the configuration detailed as above, this affects only the x86-64 Architecture.

Most of the machines are, unfortunately, old unpatched servers with outdated versions of database products. Also, there is a lot of case with machines that were already infected before by other things like ransomware.

Bitcoinbitcoin1.png736x235 34.5 KB
Other point, victims are often using factory credentials or weak one for authentications. This simplifies some much the work for attackers.

Also, most of the case he used the user account “CouchDB” to execute fs-manager.

https://github.com/apache/couchdb/issues/1074 6 (one case of a user complaining about a huge CPU usage with fs-manager)
C ) How this botnet works?

1 – Attacker finds a WebServer with ClipBucket installed, this host will be his new C&C and pushed the configuration.
2 – Attacker scan subnet by subnet to find vulnerable database servers and used a different kind of exploits to gain access to them.
3 – When it’s done, the victim requests to the C&C (with getsetup.php) and indicate with which product he was pwned, download and execute the shell script, installed the miner with a CRON table and send to the C&C if everything is ok (notify.php).

On victim side :

X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "GET /includes/libraries/getsetup.php?p=PP HTTP/1.1" 200 2931 "-" "curl/X.XX.X"
X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "POST /includes/libraries/notify.php?p=PP HTTP/1.1" 200 2 "-" "curl/X.XX.X"
X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "POST /includes/libraries/notify.php?p=PP HTTP/1.1" 200 2 "-" "curl/X.XX.X"
X.X.X.X - - [DD/MM/YYYY:HH:MM:SS -????] "POST /includes/libraries/notify.php?p=PP HTTP/1.1" 200 2 "-" "curl/X.XX.X"
On C&C side :

[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## Cron installed
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## fs-manager not found
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## Downloading files
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## all done
4 – post-traffic communication lead to a mining pool.

III – Botnet Timeline
As far I know, there is (at least) currently 3 identified campaign :

A ) First Campaign (December 2017)
C&C: viewyng[.]com

We only understood that the attacker used this website to spread his miner, the configuration leads to the third campaign, no logs are hosted on it. There are still some hints about his activity thanks to Pastebin.

https://pastebin.com/5PK24fLP
https://pastebin.com/1EKyhC5f

By speculation, I considered based on the second campaign approximately 600 machines were infected by this botnet.

Also, based on this post 1 in one mailing list archive, there were some people complaining about it (or this one).

B ) Second Campaign (03/01/2018 – 09/01/2018 Approximately)
C&C: letoscribe[.]ru

Between the first & second campaign, everything is exactly the same except the hoster. There is no upgrades or changes to the configuration. At that time, the attacker seems to temporize his botnet. Almost all the victims were from the first campaign, this is easily explained thanks to the logs :

To prove that the attacker gains access to a new one :

[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## Cron installed
[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## fs-manager not found
[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## Downloading files
[DD/MM/YYYY:HH:MM:SS][SF] X.X.X.X ## all done
When the attacker re-infects a victim to push the new config :

[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## Cron installed
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## fs-manager found
[DD/MM/YYYY:HH:MM:SS][PP] X.X.X.X ## all done
Product targeted
A least there is 3 different products identified (for almost 700 machines) :

WL : WebLogic (explained on the other article)
SL : Unknown
SF : Unknown but this is linked with CouchDB
The repartition is really contrasted. “SF” represents more than the half of the victims, “SL” 28 % and WebLogic is only 17%.

How it ends?
After the publication of the article quoted as the beginning of this post, my investigations were shut down because the domain was suspended. So, no more data to understand well this botnet.

C ) Third Campaign (13/01/2018 – Present)
C&C: ### Magic ###

The current one is interesting because as far I saw, It targets two products and contrary to the second campaign, this one is heavily active to spread the miner to new machines. WebLogic is not used and this probably caused by all the news about at the beginning of this year. At the time, there are approximately 1000~ machines infected by this botnet.

“SF” products seem to be pwnd manually (or slowly), on the other hand, “SL” are heavily pwnd by scan ranged.

Victims_3rd_Campaign

IV – Is there some information about the attacker?
It’s quite hard to understand well who is behind this (even if he’s alone or not), but we have some hints. First for the third campaign. there is an interesting line that is completely different from the other. The day before the “effective” activity of the botnet, some tests were done to check if everything was working well.

[2018-01-13 18:19:49][T] 188.69.192.107 ## nope
The IP is Lithuanian, but it’s quite hard to qualify this data because it might be a proxy or a VPN.

Secondly, on the source code on the panel, there is on IP that is automatically skipped if it’s pwnd :

$ip = $_SERVER['REMOTE_ADDR'];
if ($ip == '199.87.232.5') die('Ok');
After a quick check on shodan.io 1, This server is hosted on eSited

Remediation
if you are a victim of this miner

Kill fs-manager, xmrig
Clean your CRON Table
Change your admin credentials
Reset your “couchdb” account
Update your system and these packages :
ClipBucket
Apache CouchDB
WebLogic

Prevention / Anticipation
Add an alert when the CPU usage is too high
Install a file and directory integrity checker (like AIDE)
Establish a mining pool proxy blacklist
Don’t use default password or weak one for admin database accounts

IoC
7153ac617df7aa6f911e361b1f0c8188ca5c142c6aaa8faa2a59b55e0b823c1c
a3bbc8d3c4a950fa0b0def4109a07e9d01bae157781ff7a4b07910340e021dc7
3168fb6a817615eef3d65769f19dcaff890fc2142c35fcebc4a35e78dee2c3f3
8572208664eede5fa939bad4cfa6185c8f8db13880b560c845c65a34d12d1ad0
50538b351d2ec3d1c6531298caac5b3bbd129b6f1ae9904c92aa1ac8ab37f04d
f8d6cb1554e5826ebbf33213b37d5b31891f052784054a859de8591ee3084884
Happy hunting !

(special thanks to @benkow )

Found it here:

Inside one xmrig botnet miner!
Original source: https://fumik0.com/2018/01/24/inside-one-xmrig-botnet-miner/