Miners and canaries have had a long and storied history, but Red Canaries aren’t too fond of miners. Cryptocurrency miners, that is. Recent booms in cryptocurrency values have made cryptocurrency mining an attractive way for anyone with a computer to earn some extra money. The trouble is, the average user would spend more money performing mining activities and paying for power than they would earn through the mining. It is this dilemma that drives adversaries to take a step ahead.
There have been numerous, well-documented campaigns where adversaries have exploited systems and phished users en masse to install mining tools and generate currency for themselves. Our detection engineers have begun seeing an uptick in cryptocurrency miners, as highlighted in last week’s post from Joe Moles. Adversaries usually do not need administrative or root access to a system; they only need the ability to execute code. In this post, we’ll look at one example where the detection of a cryptocurrency miner led to a more insidious discovery.
Mining a WebLogic Bedrock
One Friday shortly before the holiday season, the Cyber Incident Response Team (CIRT) received an event from one of our customers involving Windows PowerShell downloading a binary from somewhere outside of the customer’s network.
We see this type of event many times a day. Sometimes we find PowerShell’s Invoke-Expression commandlet combined with the WebClient object’s DownloadString method to download and execute malicious code. When we receive these events we usually move through a few steps:
- Evaluate the reputation of the file downloaded
- Evaluate the reputation of the remote network host
- Find out what triggered this download
The data from these steps gives our analyst the context to determine whether an event is suspicious, malicious, or a false positive. In this case, open source intelligence sources indicated that the downloaded and executed file was mining software related to the Monero cryptocurrency.
Open source intelligence also indicated the network host had been used for suspicious activity involving scanning web servers and phishing. At this point, we needed to determine which process triggered the command to see where it all began.
Looking back through the process tree, we found that PowerShell was spawned by the Windows Command Prompt, which was in turn spawned by a Java process. This chain of execution is common on Windows clients, but we also noticed a detail that made this less common: the command line arguments for Java suggested the process belonged to an Oracle WebLogic Web Server!
After performing some quick research, we discovered that vulnerabilities and exploits for the web server had been publicly disclosed, and were likely in active use. We quickly wrote up the detection and let our customer know of the compromise. The customer took steps to remediate the execution of the miners, but within a few days the vulnerability was once again exploited and PowerShell attempted another miner download. Another quick detection was dispatched, and this process repeated several times.
So What? It’s Only a Miner
In the grand scheme of technology and the risk it brings, cryptocurrency miners usually present a small threat.
When miners are installed on systems, they introduce an additional application, service, or network connection to secure. When they are introduced into an enterprise network, they sometimes present a policy issue: employers typically don’t approve of sharing computer resources without permission. In addition, a miner installation may make a system unusable due to high resource commitments.
The game changes when miners are introduced to infrastructure services such as web servers. In these cases, the installation of miners is a symptom of a larger sickness: a vulnerability within a web application or server. In this detection, an adversary was able to exploit a vulnerability leading to remote code execution (RCE). The adversary could have chosen to download and execute malicious backdoor software or ransomware, but they chose to execute something that was relatively low risk and might have been overlooked by the infrastructure administrators.
Detecting the Real Threat: Remote Code Execution
Detecting remote code execution (RCE) on web servers can be difficult for defenders because of the fast pace that adversaries discover and exploit vulnerabilities in servers and web applications.
Network-based intrusion detection systems and web application firewalls can help detect exploitation attempts, but gaps may be found in the coverage of these controls when newer exploits are used.
How to Detect Remote Code Execution
An evergreen solution to detecting RCE involves observing the behavior of your web server and application framework processes, like PHP, and alerting on unexpected behavior.
RCE exploits against a web server usually spawn processes from the web server’s worker processes. For example, Java spawned a malicious download in this detection because WebLogic uses Java to service web requests. In the case of Apache, a web server exploit would cause processes to spawn from the HTTPD process. In each case, new processes caused by an exploit would spawn as the same user security context that launches the web server.
In this detection, PowerShell was executed with the same privileges as the Java process. The fact that these processes spawn in the same security context as the web server means you can detect potential RCE payloads using controls that audit the child processes of your web server’s Apache, Java, or other processes.
RCE exploits against a web application usually spawn processes from the application’s framework process. In the case of an exploited PHP application, a PHP process would spawn commands sent by the adversary. In the case of an exploited Struts application, Java would spawn commands. As with the exploited web servers, each of the adversary’s commands would spawn within the same user security context of the PHP or Java parent process.
3 Tips to Prevent Remote Code Execution Exploits
Here are a few quick tips on how to prevent remote code execution exploits. Some of this advice may sound familiar; as our incident handlers often remind customers, good security comes back to proven IT fundamentals!
1: Start a simple vulnerability management program soon; preferably today.
Many organizations think thousands of dollars are needed to invest in expensive vulnerability scanning appliances, along with several dedicated employees to work on vulnerability management. However, this isn’t the case.
Vulnerability management programs can start as simple as one of your system administrators reading about vulnerabilities on a web server and seeking to patch it. As your organization grows, you can invest more resources into vulnerability management. For now, start simple and build a program that catalogs vulnerabilities in your systems and patches them. A vulnerability management program is like a workout routine: the best one is the one you can follow.
2: Work patch management into your vulnerability management efforts.
Yes, patching can be hard and it sometimes breaks applications. But the detection outlined in this may have been prevented with a patch.
Just like vulnerability management, patch management can start small and mature as your organization grows. In the beginning, a non-dedicated staff member can research critical patches each week. As the program matures, a few test systems can be utilized to test patches and make sure they don’t break mission critical applications. The main point is to start small and iterate.
3: Test out web applications your organization develops or deploys for RCE vulnerabilities.
Not all of these vulnerabilities are the fault of a web server. Sometimes they are caused by input into applications that wasn’t filtered properly. Improperly filtered input could leverage the ability of PHP, Struts, or other frameworks to issue commands on a web server.
To mitigate, consider using penetration testing or specialized application security tools to search for exploitable features in the application. A little extra effort on the deployment side of the application could save a lot of headache and resources on detection and mitigation later.
Out of the Mines, Into the Daylight
Remember that the execution of cryptocurrency mining or similar software should be investigated in your network. In the best case scenario, you may discover that someone has decided to generate a little extra money on the side. At the worst, you may discover the installation of a miner is a symptom of a larger vulnerability.
For detection, worry less about how to find new exploits and focus more on observing the behavior of web server and framework processes. These processes will lead you to discover the delivery of payloads resulting from exploits. For mitigation, start managing vulnerabilities by applying patches and testing your web applications. These efforts don’t need to be perfect or mature at the beginning, just focus on starting soon and improving as needed.