Just two weeks ago a new Apache Struts 2 critical remote code execution vulnerability was published,1 and F5 researchers have already detected known threat actors exploiting it in a new crypto-mining campaign:
Based on its use of cron (for persistency) and Xhide (for launching executables with fake process names), we have dubbed this campaign CroniX.
Several proof-of-concept exploits were published on Github2 and Twitter a few days after the vulnerability was responsibly disclosed by Semmle, and the current threat actor seems to have quickly adopted one of these exploits in its arsenal.
Recall that just a year and a half ago, Equifax was hit with another vulnerability on its Apache Struts 2 servers (CVE-2017-5638). That attack resulted in the exposure of personally identifiable information (PII) of 147 million consumers and has (so far) cost the company over $439 million.3
As with many other Apache Struts 2 vulnerabilities, CVE-2018-11776 allows attackers to inject Object-Graph Navigation Language (OGNL) expressions, which might contain malicious Java code that is evaluated under several circumstances. This time, the injection point is within the URL.
The attacker sends a single HTTP request while injecting an OGNL expression that, once evaluated, executes shell commands to download and execute a malicious file.
Figure 1: Decoded exploit payload in the request URL
An additional file on the server at /win/checking-test.hta holds a Visual Basic script that calls a Microsoft Windows cmd to run a Powershell command on a targeted victim. So, it seems this threat actor is targeting Windows OS (not just Linux) using another operation hosted on the same server.
Figure 2: Another file found on the server, holding a script that targets Microsoft Windows systems
Optimizing Machine Performance
The downloaded “update.sh” file is a bash script that performs several malware deployment steps.
First, the attacker sets the number of “huge pages” in the memory to 128. This is the first clue that the attacker’s intention could be a mining operation, as this step is most probably related to improving mining performance.5
Figure 3: Setting huge pages to Improve CPU mining
Three cron jobs are set in place for malware persistency. Two of them download and execute a new update.sh file every day. Interestingly, the files are downloaded both by using the explicit server’s IP address or its domain name. During the download, it uses a special “linux” user-agent (in some cases “Linux” with upper case L) as an access restriction mechanism, while IP accessing with any other user-agent is banned.
Another job starts a file located in “~/.config/java/.conf/upd” (analyzed later).
Figure 4: Setting a cron job for malware persistency
For additional persistency, another file named “anacrond” is downloaded, which is copied to every folder named “cron.d” under the /etc directory. It is also saved to /etc/cron.d/anacron, which is a system cron job file. The commands in the file are like the ones in “update.sh”—they download the deployment bash script and restart the mining process.
Figure 5: an acrond file used for additional persistency
Killing Competitor Processes
Any doubts about the intention of this malicious campaign is dispelled once the attacker tries to kill the processes and delete the binaries of previously installed crypto-miners. This is commonly done by crypto-mining operations these days.
Figure 6: Commands that kill competing crypto-miners
For some miners, the attacker decides to take a more careful approach and check each process name and process CPU usage and then kill only those processes that utilize 60 percent or more of the CPU resources. This is probably done to avoid killing legitimate processes as the names of these miners (crond, sshd and syslogs) typically relate to legitimate programs on a Linux system.
Figure 7: Killing sshd miner if CPU utilization equals or surpasses 60 percent
Dropping Malicious Executables
Once the competition is knocked out, the attacker removes the older version of his own malware files and downloads the freshest versions of the “run” and “upd” bash scripts.
Figure 8: Downloading additional malicious files
Two additional binary executables—“xmrig” and a file called “H”— are downloaded, each having a x86 and a x64 version.
Figure 9: Downloading x86 and x64 version of malicious, executable files
The “xmrig” file is a miner with an embedded configuration (pool, username, password etc.). This is not the original XMRig miner, but rather a fork of it named XMRigCC,6 built for CPU mining optimization.
Figure 10: XMRigCC menu
More interesting is the “H” file, which is an old XHide tool for launching executables with a fake process name.
Figure 11: H content
The “run” script executes XHide to launch “xmrig” crypto-mining while faking its process name to “java”. The created process id is written to a file named “pid”, so the “upd” script could kill and restart this process later.
Figure 12: Script file runs XHide process hider with a preconfigured XMRig miner
The prominent use of Cron for persistence and the rare use of XHide were the main reasons we named this campaign CroniX.
Tracks on PasteBin
We have spotted a draft of “update.sh” on https://pastebin.com/jRerGP1u with some differences from the currently downloaded malicious script. The script was uploaded on Aug. 16, 2018.
Figure 13: The attacker used Pastebin for the script’s draft
The Mining Operation
The attacker communicates with a Monero (XMR) pool at “eu.minerpool.pw” as seen in the following DNS request.
Figure 14: DNS query to the get the mining pool server’s IP address
Once resolving the pool’s domain, the attacker checks into the mining pool:
Figure 15: The miner tries to login to the mining pool
Connection to Other Campaigns
The malware deployment pattern, the similar deployed file names (“run”, “upd”, folders were named 32 and 64) and the quite unique usage of “XHide —Process Faker” made us believe that the threat actor behind the exploitation of this fresh Struts 2 vulnerability is the same one that was behind a previous campaign exploiting Jenkins servers via CVE-2017-1000353, which was reported by F5 Labs just two months ago. In that campaign, the threat actor used a Chinese Git website to host malicious files and, as it seemed, also for the development.
This time the attacker is using a dedicated web server to serve the files which is hosted in the US, while using Palau (Pacific island) domain names registered by a Russian registrant.
Figure 16: Palau (.pw) domain name registered by reg.ru
Figure 17: The threat actor is using a US hosting service to serve its malicious campaign files
Considering it’s only been two weeks since this vulnerability was discovered, it’s worth noting how fast attackers are weaponizing vulnerabilities and how quickly researchers are seeing them in the wild. Enterprises must be as vigilant as ever about patching affected systems immediately. When patching isn’t possible, it’s advisable to implement a web application firewall for automated protection. Stay tuned for more updates from F5 Labs on this campaign.
Join the Discussion
To comment, first sign in and opt in to Disqus.