Cryptominers’ Anatomy: Shutting Down Mining Botnets
Contents
Introduction
Welcome to the final installment of our Cryptominers’ Anatomy blog series:
In our first post, we discussed cryptocurrencies' fundamentals, their various attributes, and what makes some of them more attractive than others to threat actors.
In the second part, we analyzed various cryptomining samples that we found abusing different mining topologies.
In this third and final blog post in the series, we will explore two novel proactive techniques that can be used to defeat cryptominers.
In addition to these blog posts, we released several analysis tools that can be found in our repository.
Everybody knows that the best defense is offense. Because of the distributed nature of cryptominer campaigns, disrupting them can be very challenging.
In this blog post, we show how to overcome this problem by exploiting the design of common mining topologies to effectively shut down the mining process. Although the techniques we describe were used to target Monero cryptominers, the same principles can apply to other cryptocurrencies, as well.
Shutting down cryptominer operations
When a malicious cryptominer operation is detected, there are currently two ways to attempt to shut it down:
We can request the pool service to ban the attacker account
We can attempt to take down other services in the attacker's infrastructure to interfere with the campaign
The problem with these options is that they can become quite complex and take a long time because of third-party reliance.
We found a better option.
We developed two techniques by leveraging the mining topologies and pool policies that enable us to reduce a cryptominer botnet's effectiveness to the point of completely shutting it down, which forces the attacker to make radical changes to their infrastructure or even abandon the entire campaign.
Both techniques are based on exploiting stratum communications in a way that enables banning critical components like proxies or wallets that are related to accounts of the mining operation.
3.3 million to zero
We targeted a malicious cryptominer operation that has been active for six years. By banning the attacker’s mining proxy, a central point of failure in the mining topology, we were able to reduce its hashrate from 3.3 million hashes per second all the way down to zero (Figure 1).
As easily as the attackers were making money, we were able to terminate the attacker’s potential yearly revenue in a matter of seconds. By using a simple laptop, we caused the cryptominer operator to lose their US$26,000 per year cash cow with the now plummeted hashrate.
Fig. 1: A malicious mining proxy losing 100% of its hashrate
The video in Figure 2 demonstrates this technique, which we dubbed “bad shares.” It depicts a cryptominer victim that's connected to a malicious mining proxy. By executing “bad shares,” we were able to ban the mining proxy from the network — shutting down the mining operation and dropping the victim's CPU use from 100% to 0%.
Fig. 2: Applying the bad shares technique on our lab setup
If you can’t beat them, ban them
Cryptomining through a pool is based on submitting valid hash calculations, referred to as shares. To generate revenue, a cryptominer is required to submit shares to the mining pool. Upon receiving a share, the mining pool will validate the hash result and its difficulty.
The validation of shares is one of the heaviest tasks the pool server has to handle, especially in cases of invalid shares. As with everything in life, mistakes are possible; for example, a hardware malfunction could lead to incorrect shares being submitted to the pool.
Handling invalid shares consumes a lot of resources, so pools must protect themselves from collapsing under a load of massive submissions of invalid shares. Therefore, when a submitted share doesn’t pass the server validation, most pools will enforce a penalty on the miner, usually in the form of a temporary ban.
This interaction can be very interesting when attempting to shut down a malicious mining operation. If we can make a back-end node or a pool to ban the attacker miners (a.k.a. victims), we can stop the resource exploitation of the cryptominer and essentially release the victims.
In the following sections, we demonstrate this concept by targeting two mining campaigns that we’ve previously explored, each representing a different mining topology: a mining proxy and a direct public pool connection.
Using bad shares to ban an attacker mining proxy
One of the most popular mining topologies used by malicious cryptominers is a mining proxy (Figure 3). This setup enhances privacy by concealing both the back end and the wallet address of the attackers, thereby protecting their identities and reducing traceability within the network.
Fig. 3: Mining topology based on a mining proxy
Mining proxies pose unique challenges for network detection since they “hide” the target pool that the miner connects to, which is usually detectable by using network inspection. They also hide the wallet address, which further reduces the miner’s detectable footprint. However, we have discovered that mining proxies can serve as a cryptominers’ Achilles’ heel.
When mining using a proxy, all the victims are connected to a single server, which means that interfering with the proxy can bring the entire mining operation down. We developed a technique that can enable us to do just that.
The idea is simple: By connecting to a malicious proxy as a miner, we can submit invalid mining job results — bad shares — that will bypass the proxy validation and will be submitted to the pool. Consecutive bad shares will eventually get the proxy banned, effectively halting mining operations for the entire cryptomining botnet.
Communicating with the proxy
The cryptominer must first connect to the proxy using the Stratum login method. If no other configuration was set, the miner identifies as x by default in the XMRig proxy server (Figure 4).
Fig. 4: JSON representation of the login request
If the connection succeeds, it means there is a listener on the proxy end. We can ensure it’s indeed a mining proxy by parsing the response — a valid response will be a JSON document that complies with the Stratum protocol, and the result will be a job.
Although the complete mining process is complex (as described in Zero to Monero), crafting a custom share is relatively simple. It only requires extracting a few values from the proxy response: the worker id, job id, and nicehash nonce. All three are required to keep track of a specific mining job, so if we want the proxy to accept our bad shares we have to fill out those fields correctly (Figure 5).
Fig. 5: JSON representation of job assignment response
Upon receiving a share from a miner, the proxy will forward it to the pool almost as is, with one key difference — it's submitted under the attacker’s wallet address. This is why we could never know the wallet or any other information about the attacker’s account or the pool from the cryptominer sample.
XMRogue
Infiltrating the cryptominer botnet as one of the victims is not hard. Usually, there is no special authorization — and in many cases, it uses standard applications like XMRig as a miner and XMRig-proxy as a mining proxy.
This led us to develop XMRogue. XMRogue is a tool that enables us to impersonate a miner, connect to a mining proxy, submit consecutive bad shares, and eventually ban the mining proxy from the pool (Figure 6).
Fig. 6: Bad shares technique sequence diagram
One important consideration is share validation on the proxy level — as our bad shares are forwarded to the pool by the proxy, it has the opportunity to identify and drop them.
For example, the popular XMRig-proxy will validate the nicehash nonce it supplies with the job and the difficulty of the result. If either the nonce or the difficulty are incorrect, the bad share will not be forwarded to the back-end pool. In Figure 7, we see the validation within the code, where shares with low difficulty hashes or incorrect nicehash values are discarded.
Fig. 7: XMRig-proxy code that handles mining errors. (Source: https://github.com/xmrig/xmrig-proxy/blob/501d9722454e20de90ed205e26da8cbf304c2ac8/src/proxy/Miner.cpp#L259)
We can overcome these validations by parsing the job request and carefully crafting a “bad” job result that is deemed valid by the proxy, causing it to forward our shares to the pool.
Testing the theory
To test our technique, we chose to target one of the mining campaigns we identified in part two of this series. We were able to extract the addresses of all mining proxies used by the chosen campaign, which gives us quite a bit of information to play with. For example, we can see that the central attacker’s proxy — creatively named “proxy” — has a maximum rating from Nanopool, which indicates extended use (Figure 8).
Fig. 8: Worker list of the malicious campaign
This proxy generates 3 million hashes per second, roughly equal to a revenue of US$3 hourly or US$26,000 annually. By targeting this proxy with XMRogue, we were able to quickly ban it from the pool and to stop the mining of all victims that were connected to it. If we inspect the hashrate of the proxy, we can see that it dropped all the way down to zero (Figure 9).
Fig. 9: The campaign mining dashboard during XMRogue work
If we consider the impact of XMRogue on the attacker’s entire campaign, we can see a substantial decrease in its profitability. When we first documented this campaign, it generated almost US$50,000 annually. After we disrupted it and set it out of balance, the campaign’s annual revenue decreased by 76% to US$12,000. By targeting additional proxies, the revenue could have potentially dropped to zero. This kind of impact could easily force the attackers to abandon their campaign for good or take a risk of being identified when making changes that are being monitored.
Leverage other mining pool policies
Attackers will not always use a proxy. In many cases, victims will connect directly to the pool, which means that the previous technique will not be applicable. Submitting bad shares will simply ban our IP address from the pool, without affecting the mining operation.
Fig. 10: Public pool topology; a victim miner connected directly to a public pool
When we inspected the mining pool’s source code, another option came to mind — targeting the wallet address. While the previous bad shares policy targeted miner IP addresses, we identified an additional policy that is enforced on the wallet level — the pool will ban the wallet’s address for one hour if it has more than 1,000 workers.
When using proxy mining, an attacker can embed their wallet address exclusively on the proxy server, enabling them to effectively masquerade it. But in situations where direct mining is performed, the wallet address must be present on the victim machine, which enables us to extract it.
Getting the attacker banned in this case is straightforward — we just send more than 1,000 login requests using the attacker’s wallet simultaneously, which will force the pool to ban the attacker’s wallet. This technique was added as an operation mode to the XMRogue tool.
To illustrate this idea, we used another campaign we uncovered that uses the public pool MoneroOcean. The campaign's initial state was a 22 kH/s hashrate (Figure 11). This campaign is much smaller than the one we discussed above, but the technique itself should cover a broader range of cryptomining campaign configurations.
Fig. 11: Active cryptominer campaign uses MoneroOcean public pool
After launching our script, which instantly initiates thousands of logins, we saw the mining rate plummet, eventually seizing entirely (Figure 12).
Fig. 12: Continuous decrease of the cryptominers’ mining hashrate
Wider net, shallower catch
This tactic could interrupt more mining operations, but it isn’t a permanent solution. Once we stopped the multiple login connections, the campaign's hashrate recovered (Figure 13).
Fig. 13: The account recovered after we stopped XMRogue's multiple login sequence
Summary
The techniques presented above show how defenders can effectively shutdown malicious cryptominer campaigns without disrupting the legitimate pool operation by taking advantage of pool policies. A legitimate miner will be able to quickly recover from this type of attack, as they can easily modify their IP or wallet locally.
This task would be much more difficult for a malicious cryptominer as it would require modifying the entire botnet. For less sophisticated miners, however, this defense could completely disable the botnet.
Series conclusion
This post concludes our Cryptominers’ Anatomy series. We’ve covered the fundamentals of cryptomining and explored the attacker mindset through the hunting of active campaigns that implement different mining topologies.
We believe that the threat of cryptominers will continue to grow over time. But now we can fight back and disrupt the attacker’s operation, making it much more challenging to monetize cryptominers effectively.
