New Research: Crypto-mining Drives Almost 90% of All Remote Code Execution Attacks

It’s early in 2018 and we have already witnessed one of the top contenders in this year’s web application attacks. Continuing the trend from the last months of 2017, crypto-mining malware is quickly becoming attackers’ favorite modus operandi.  In December 2017, 88 percent of all remote code execution (RCE) attacks sent a request to an external source to try to download a crypto-mining malware.
These attacks try to exploit vulnerabilities in the web application source code, mainly remote code execution vulnerabilities, in order to download and run different crypto-mining malware on the infected server. The malware usually uses all CPU computing power, preventing the CPU from doing other tasks and effectively denies service to the application’s users.
RCE vulnerabilities are one of the most dangerous of its kind as attackers may execute malicious code in the vulnerable server. Have you ever wondered what kind of malicious code attackers want to execute? The answer in most cases is – any code that earns the attackers a lot of money with little effort and as quickly as possible.
During a recent research project, we saw an extremely large spike of RCE attacks. In this post we will analyze these attacks, drill down into a malicious crypto-mining script, try to “follow the money”, and check if these attacks really are that profitable for attackers.

RCE vulnerabilities and payload families

A remote code execution vulnerability allows attackers to run arbitrary code on the vulnerable server. For example, in a previous post we discussed RCE vulnerabilities related to insecure deserialization. In these types of vulnerabilities attackers can tamper with serialized objects that are sent to the web application. Then, after the object is deserialized, malicious code will run in the vulnerable server.
In our current research we focused on RCE attacks where the payload included an attempt to send a request to an external location. The method of sending such requests differs depending on the operating system and the desired result. For example, attackers targeting Windows servers, used a Powershell command to download a file from an external location (figure 1). Attackers targeting Linux servers, used Bash scripts, and wget or curl commands for the same purpose.

We’ve categorized RCE attack payloads to three types:

• Crypto-mining malware – this payload tries to download a script from a remote server and run it locally on the vulnerable machine. The script turns the server into a miner for some crypto currency, most notably Monero. We dive into this type of attack later in the article.
• DDoS botnet– this payload tries to download and run a script like the crypto miner payload. The difference is that in this payload the script enlists the vulnerable server to a DDoS botnet where it will participate in a DDoS attack on demand.
• Reconnaissance– this payload is used when an attacker tries to assess whether the server is vulnerable or not. Attacks using this type of payload mostly included many requests to a specific server, each request targeting a different parameter.

A shift in the payloads trend

In the past, RCE payloads that sent requests to an external location included mostly attempts to infect servers with malware that added the vulnerable servers to a DDoS botnet. This kind of attack is mostly profit based since the attackers can provide DDoS for hire services.
In recent months, there has been a sharp increase in attempts to infect vulnerable servers with crypto-mining malware (see figure 2.)  This kind of malware allows attackers to use the CPU (or sometimes GPU) power of the vulnerable server to mine crypto currencies. In this kind of attack, the attackers eliminate the need to sell their product to a third party and thus achieve a faster return on investment.
According to our research, in December 2017 almost 90 percent of all the malicious payloads in RCE attacks that sent a request to an external location were crypto-mining malware. In this analysis we haven’t included reconnaissance attempts, but focused on payloads that contained malicious content.

September 2017

 

December 2017

 
Figure 2: Percentage of crypto miners and DDOS bots seen as payloads in RCE attacks in September 2017 compared to December 2017

Crypto mining in a nutshell

Crypto mining uses computation power to solve difficult mathematical puzzles called proof of work functions. Each time such a problem is solved, the miner who solved it gets a fixed amount of coins, depending on which coin she or he was mining. For example, currently, bitcoin miners get 12.5 bitcoins ($115,812.44) each time such a problem is solved.
But solving this puzzle alone is not an easy task, and a lot of computing power is needed. Hence, miners use mining pools to increase their chances of getting paid.
Mining pools are platforms that allow miners to work together and share computation resources to solve the puzzle. Once it is solved, the coins are divided between the participants of the pool according to how much computation power they each contributed.
To own and exchange crypto currency you need a crypto wallet. Contrary to a regular ‘pocket’ wallet, crypto wallets don’t hold actual money. They store cryptographic keys which allow the user access to their currencies. Each wallet has an address which can be used to sign the wallet into a mining pool and send the profit of the mining process to the wallet.
Another important aspect of crypto mining is the required hardware. Bitcoin is likely the most popular crypto currency and mining it is practically impossible using only regular CPU. To mine Bitcoin a specific hardware is required or requires the use of GPU which allows more parallelization of the computation, thus improving the mining process.
Other crypto currencies, like Monero, are newer and can be mined using regular CPU. Thus, it has become the hackers’ preferred choice to infect servers with crypto-mining malware to mine crypto currencies that are mineable with regular CPU.
CryptoNight is an algorithm used to mine Monero and is designed to work on a regular PC CPU. In recent attacks we have seen a lot of malware using it to mine Monero.

Why are attackers not mining Bitcoin?

Bitcoin is the arguably the most popular crypto currency that exists, but still we have not seen a single attack trying to infect servers with Bitcoin mining malware. Besides the fact that special hardware is required to mine Bitcoin while regular CPU can be used to mine the crypto currencies mentioned above, there is another notable reason.
Bitcoin transactions are not private and coins can be traced back along the transaction chain. All the cryptocurrencies that we saw attackers trying to mine are more anonymous.
The transactions of these cryptocurrencies cannot be traced back, the balance of accounts cannot be seen and actually seeing a transaction doesn’t reveal either the sender, the receiver or the amount transferred. This makes these anonymous crypto currencies a favorite for hackers to mine illegally on vulnerable servers.
Monero is also used as a way to launder money made illegally. For example there were reports that Bitcoins earned by the WannaCry ransomware were moved to Monero, probably as a means of hiding the source of the money.

Crypto-mining recipe

Next, we will follow an attack found in the wild, and through it try to understand the way that a crypto-mining malware works.
The following attack (figure 3) was found in the post body of an HTTP request that was trying to exploit an RCE vulnerability to send a wget command to download and run a script. Notice how the attacker is trying to hide his trails with the “-q” option which stands for quiet mode.

The link is disguised as a JPEG picture, but it actually contains a Bash script that infects the vulnerable server with crypto-mining malware. The fact that it is a Bash script indicates that this attack is targeting Linux servers, contrary to the Powershell command we saw before.
This downloaded script has three stages:

• Killing background processes
• Gaining persistency
• Downloading and running the malware

First, it kills processes that are running in the background of the server (figure 4). These processes include mostly competing crypto miners, but also security controls and processes that use a lot of CPU.
The way this script identifies competing crypto miners is either by killing the processes with known crypto-mining software, or by killing processes that include specific IPs or parts of crypto wallets. Seems like the attacker knows exactly who his competitors are by killing processes related to specific IPs and wallets, and he doesn’t like competition.

In the second stage, (figure 5) the script deletes the current cron jobs in the system. These are the scheduled tasks process in Linux.
After that, it adds a new scheduled task to download and run the script again. The goal of this stage is for the process to be persistent by downloading and running the script over and over again. So even if someone notices the malware and deletes it, it will be downloaded again. After running the scheduled task, the script hides its trail by deleting the folder from which it ran.

 
The third and last stage, (figure 6) is where the infection happens. First, the script downloads a dynamic configuration file (figure 7). In the attacks we’ve seen the configuration file was hosted on the same host in which the script was downloaded from.
This configuration file includes information like the attacker’s wallet, the mining pool which the crypto mining participates in and data about the mining algorithm to be run. Also, the attacker determines how much computing power would be dedicated to mining. In the file below the maximum CPU usage for mining is 90 percent, which would probably render the server unusable for any other process.
Next, the malware itself is downloaded. The script then calculates the number of cores in the server and runs the malware using the configuration file and number of cores as its input parameters.


To increase the success rate, the script then repeats the third stage four more times, each time downloading a different configuration file and a different malware. It runs other malware only if the previous attempts were not successful.
If the script was successful, then the vulnerable server that ran it would be infected by malware that earns crypto currency for the attacker. Also, most of the computing power of the server would be dedicated for this purpose, as other mining or CPU consuming processes were shut down. This would cause denial of service to the server’s client.

The money trail

In the downloaded configuration files we found, there were active Monero wallets that belonged to the attackers. By tracing the wallets and the mining pools, we saw the amount of money made using crypto mining. Figure 8 shows the total amount of money the attacker made in “mineXMR.com“– a popular mining pool for Monero.
At that point in time the attacker made around 41 Monero, which translates (in current Monero to dollar rate) to around $10,000.

We can also see how much Monero the attacker made each day (figure 9). Earning around one-and-a-half Monero a day which translates to around $375 each day. Not a bad profit for a day’s work at the (crypto) mine!

We checked on the attacker a couple of days after and saw that his account was suspended due to reports of botnet activity (figure 10). Notice that the suspension is only from this specific Monero pool. There are many other Monero pools from which the attacker can keep mining. The attacker simply needs to change the mining pool settings in the dynamic configuration file downloaded by the script to continue mining.

Other crypto currencies

Most of the RCE payloads in our data contained crypto miners for Monero. But there were some attacks in which the payload was a crypto miner for other currencies. One such currency is Electroneum, a relatively new crypto currency published in September 2017. This is a UK-based crypto currency designed specifically for mobile users. Figure 11 shows one of the Electroneum mining pools found in the payload which attackers tried to run.

 
Figure 12 shows the wallet of one of the attackers who tried to infect vulnerable servers with Electroneum mining malware. Last time we checked, the attacker had more than 220,000 Electroneum, which is worth (in current Electroneum to dollar rate) around $15,500.

 
Another crypto currency found in the payloads is Karbowanec, or Karbo for short. This is a Ukraine-based crypto currency published in mid-2016. Its name is derived from the word Karbovanet which was a currency used in the Ukraine at several periods during the 20^th century. Figure 13 shows a Karbo wallet found in the data that earned around 275 Karbo which at the time it was taken was worth $379.

Conclusion

There’s a surge of attackers trying to infect vulnerable servers with crypto-mining malware, and for obvious reasons. Last December almost 90 percent of all the RCE attacks that sent a request to an external source included a crypto-mining malware.
Attackers can make a lot of money (off your server resources) with crypto mining and there are many different crypto currencies to mine. The anonymity of transactions and the easy use of regular CPU make this attack very popular among hackers who want to earn money, and fast.
A crypto-mining malware causes denial of service to the infected server. With most of the server computation power directed to crypto mining, the server is rendered unavailable. Also, getting rid of the malware is not so easy due to its persistence as it adds a scheduled task to download and run it again after a certain period of time.
To protect web applications from crypto-mining malware, the initial attack must be blocked. In this case it’s the RCE vulnerabilities attackers exploit to launch their malware. Organizations using affected servers are advised to use the latest vendor patch to mitigate these kind of vulnerabilities.
An alternative to manual patching is virtual patching. Virtual patching actively protects web applications from attacks, reducing the window of exposure and decreasing the cost of emergency patches and fix cycles.
A WAF that provides virtual patching doesn’t interfere with the normal application workflow, and keeps the site protected while allowing the site owners to control the patching process timeline.
Learn more about how to protect your web applications from vulnerabilities with Imperva WAF solutions.