Security operations · 5 MIN READ · MYLES SATTERFIELD, BRIAN BAHTIARIAN AND TUCKER MORAN · JUN 30, 2022 · TAGS: MDR / Tech tools
TL;DR
- 35% of the web application compromise incidents we saw in 2021 resulted in deployment of cryptocurrency coin miners.
- The Palo Alto Networks next-generation firewall (PAN NGFW) helps detect and investigate coin miner C2.
- This post walks through a cryptojacking example and provides helpful advice on how to avoid it in your own environment.
Cybercriminals are always looking for new ways to make money. These methods don’t always include holding data for ransom (although this tactic is a popular one). In fact, bad actors don’t necessarily have to elevate privileges or move laterally to make their coin.
Q: How? A: Cryptojacking.
Cryptojacking is when a cybercriminal steals an organization’s computing resources to mine various crypto currency blockchains. As our end-of-year report indicated, 35% of the web application compromise incidents we saw in 2021 resulted in deployment of various cryptocurrency coin miners. It’s a sweet gig for the bad guys, too: after the miner is deployed, they can sit back, relax, and watch the money pile up.
So how can organizations spot cryptojacking?
One of the answers is Palo Alto Networks next-generation firewall (PAN NGFW) series.
In addition to affording visibility into network traffic, PAN NGFW embeds different types of command and control (C2) detections. As the use of cryptojacking increases, we’ve noted how PAN NGFW has helped detect and investigate coin miner C2 activity in our customers’ environments. Throughout these investigations, we’ve used PAN NGFW—specifically, firewalls and Cortex XDR—to quickly identify and respond to coin miner infections.
To be clear: we don’t believe coin miners are inherently bad—it’s the groups that are exploiting vulnerable web-apps for cryptojacking that are the problem. In this post, we’ll walk through why we’ve found PAN NGFW is great at detecting cryptojacking, and some actions we’ve integrated into Ruxie™, our detection bot, to help.
Detecting cryptojacking with PAN NGFW
Over the past year, 40% of PAN NGFW “CoinMiner” alerts triaged by our SOC were true positive—an extremely high-performance result. In fact, anytime we ingest a PAN NGFW “CoinMiner” alert into Expel Workbench™ (our analyst platform) we create a high severity alert where we aim to have eyes on the activity within 15 minutes. Our response time for this class of alert? Six minutes. Bottom line: the fidelity of these alerts is quite good.
In coin mining incidents detected by our SOC, PAN NGFW “CoinMiner” alerts typically detected network connections to known mining pools (for example, “moneropool[.]com”), use of the JSON-RPC protocol, methods (example: “mining.subscribe”) associated with coin mining, and algorithms used by the miner (example: “nicehash”).
Let’s consider an example PAN NGFW coin mining alert in Workbench, the investigative steps we take to determine if the activity is a true positive, and some Ruxie actions we use to boost our investigation.
Let’s walk through an example alert
This is what a PAN NGFW “CoinMiner” alert would look like in Workbench.
First, let’s take a look at the source and destination IP addresses and ports. We can see the source IP address starts with 10.—indicating the address is internal to the organization. Additionally, the source and destination ports reveal that the source IP address is likely the client and the destination is the server. (The source port is a part of the ephemeral port range and the destination port is 80, and likely HTTP traffic.)
Therefore, if this is coin miner traffic, it’s likely a miner installed on the internal machine reaching out to the mining server.
Some quick research on the IP address indicates it’s likely part of a hosting provider. Shodan suggests the IP address has port 80 open, but it’s unclear as to what service is being offered.
If we take a look at the application field, we see json-rpc is used. Some research shows crypto miners use json-rpc to communicate with their mining pools. Let’s step through the communication flow covered in the reference:
- The miner sends a login request to the mining pool for authorization
- If the authorization is successful, the server sends back a job for the miner to do
- After the miner completes the job, it sends back a submit to the mining pool server
- The server sends a response to the miner on whether the submission was successful or not
The information from the alert and our research indicates this activity may align with coin mining. Now we can use information from Ruxie to get a better understanding of the traffic going back and forth.
We have a Ruxie action that pulls netflow data involving the destination IP address-45.9.148.21. In the screenshot below, the data shows consistent communication from the source internal IP address 10.1.2.3 to the destination 45.9.148.21. Additionally, there’s consistency between the bytes being transferred each time the source IP connects to the destination.
Finally, we have Ruxie download a packet capture file (PCAP) from the Palo Alto console (if available). Ruxie parses out readable strings as well as info from different layers in the packet.
What does this mean? The raw data from the packet above indicates active coin-mining activity. The json-rpc data suggests the server is giving the miner a job, specifying details such as the seed_hash and algorithm to use. This activity aligns with step 2 in the overview of mining communication traffic above.
We can infer that a miner at or behind the source IP address performed the login process in step 1 because the server wouldn’t have sent the job recorded in the PCAP if it didn’t receive a successful login.
At this point, we have enough evidence to conclude there’s a coin miner installed on the host at or behind the IP address 10.1.2.3. If we have access to endpoint technology, we can use it to determine what process is generating this traffic.
We got ‘em—now what?
To improve resilience, we first ask, “How did the coin miner get here?” If we don’t have access to the source machine of the activity, we may never uncover the answer. However, we can think about some of the common ways coin miners are deployed:
Public application exploitation
Attackers can exploit public-facing software that’s vulnerable to a remote code execution (RCE) vulnerability to deploy crypto miners.
How to prevent: Keep public-facing applications and software up-to-date. As our end-of-year report indicated, we typically see cybercriminals exploit one to three-year-old vulnerabilities.
Access key compromise
In the past, we’ve watched attackers gain access to long term Amazon Web Services (AWS) access keys—access keys that start with AKIA—and abuse access to deploy EC2 instances and run crypto miners on the deployed instances.
How to prevent: Make sure you aren’t exposing access keys in public repositories and implement least privilege for AWS users.
Phishing emails/USB devices
Coin miners can be deployed via phishing emails or infected USB devices.
How to prevent: Disable autorun on Windows 10 machines and educate end users on the impact of phishing emails.
Key takeaways
While we understand it’s next to impossible to completely prevent coin miners from being deployed in your environment, here are three key recs for detecting coin mining activity in your org:
- Look for internal-to-external connections over the json-rpc protocol or to known mining pools (Monerohash, c3pool, and minergate, among others).
- If you’re using a Palo Alto firewall, investigate their CoinMiner Command and Control Traffic and XMRig Miner Command and Control Traffic alerts.
- Consider services like Shodan and Censys to see what the internet can see about your attack surface.
