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.

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

Mining

At this moment, this meme summarizes my reaction :

leonardo

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 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.

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.

With just a simple string command, we can understand this is just in fact xmrig.

more information here : VirusTotal

config.json

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

If you want some additional information, these linked as below could help :

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 :

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.

5 – log.txt

As explained just above, this file logged just everything about the activity of the botnet.

SecondCampaign

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.

Bitcoin

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.

C ) How this botnet works?

2018-01-23_11-42-19

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 :

On C&C side :

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.

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

Also, based on this post 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 :

When the attacker re-infects a victim to push the new config :

Product targeted

A least there is 3 different products identified (for almost 700 machines) :

The repartition is really contrasted. “SF” represents more than the half of the victims, “SL” 28 % and WebLogic is only 17%.

2ndCampaignPieChart

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.

404 page

 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.

Evolution

“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.

The IP is Lithuanian, but it’s quite hard to qualify this data because it might be a proxy or a VPN.

IP_Miner

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

After a quick check on shodan.io, This server is hosted on eSited

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)

Leave a Reply