Most cyberattackers target the personal data or pocketbooks of their victims, but others are after something else entirely – processing power.
This was the case when we witnessed a spike in a customer’s CPU usage. The customer, who’s environment contained predominately Linux machines, reported nothing out of the ordinary. Our analysis quickly uncovered the culprit – a Monero cryptocurrency miner had been surreptitiously installed on the network and was draining the organisation’s resources.
Currency mining, in and of itself, isn’t illegal. In fact, it’s a central part of cryptocurrencies. At a fundamental level, by using special software miners solve math problems and, in return, are issued a certain number of coins. This process helps keep the currency secure by approving transactions and verifying them on the public ledger, or blockchain.
The process is designed to be resource-intensive, and the equations purposefully difficult, as this ensures new coins are released at a steady rate. This is why criminals sling coin mining malware against organizations with high computing resources – more CPU means more coins.
Root cause of entry
The compromise began after a user clicked on a malicious URL, either a display ad or through URL redirection, executing a shell script disguised as a jpeg extension (logo.jpg). After the malicious link was clicked, the content-type field in the response contained the exploit code that added an entry to crontab and downloaded the malicious logo.jpg file.
That file was stored in the cron entry and exploited the ‘’ (CVE-2017-5638) vulnerability which allows an attacker to carry out Remote Code Execution (RCE) attacks.
After this, a configuration file was downloaded from a remote server and stored in the victim machine, then the CPU was put to use mining Monero. The image below illustrates the infection steps:
Figure 1 Infection steps
Exploitation phase
As mentioned earlier, the Apache Struts vulnerability was pivotal in this attack. After gaining access, a blank file named “lclqhxwtts.conf” was saved under the directory /var/tmp with read/write permissions enabled. Then, a HTTP request downloaded the necessary configuration from a remote server.
Any existing sshd files present in /var/tmp were deleted and replaced with the cryptocurrency mining support files, kworker and kworker_na, and saved in the directory /var/tmp/sshd. This file’s permissions were set to ‘executable’ then a cron entry for this file was created every 29 minutes.
Let’s take a closer look at these configuration files:
“url” : “stratum+tcp://91.121.87(.)10:80”,
“user” : “46XG1vfKxfE1yQnPkrwdQoUDdewkqxCz8ZUnjtu4HH6j27uaWdXaC8D43Vax6XVZmGb3MTHaULEBoiBo7DbP3PPJLyffUcF”,
“pass” : “x”,
Another configuration file included similar contents:
“url” : “stratum+tcp://94.23(.)206(.)130:80”,
“user” : “46XG1vfKxfE1yQnPkrwdQoUDdewkqxCz8ZUnjtu4HH6j27uaWdXaC8D43Vax6XVZmGb3MTHaULEBoiBo7DbP3PPJLyffUcF”,
“pass” : “x”,
Here we see the ‘User’ detail set as the cryptocurrency wallet and the Password set as ‘x’ – a.k.a no password.
These files used the CryptoNight algorithm which is one of many algorithms used to mine cryptocurrencies. CryptoNight is designed to use CPU rather than GPU.
Coin miner
In the attack’s final step, the coin miner was dropped from 91.230.47(.)40 and it almost immediately began using the victim’s CPU resources. As identified in the conf files, the coin wallet was: 46XG1vfKxfE1yQnPkrwdQoUDdewkqxCz8ZUnjtu4HH6j27uaWdXaC8D43Vax6XVZmGb3MTHaULEBoiBo7DbP3PPJLyffUcF.
Conclusion
Regular patching will keep the system safe from most coin mining infections. In this case, Apache Struts needs to be updated to the latest version, or a filter should be deployed for servlet to validate content-type – the initial means of infection in this scenario.
The identified coin mining IP addresses should also be blocked in the firewall and proxy.
