When Coinhive first came out in September of 2017, it was fairly easy to identify websites using browser miners by looking for a few lines referencing the Coinhive API within the HTML source code. Because this was a new phenomenon, even bad actors didn’t have to hide their intentions, and collecting statistics was a fairly straightforward and accurate process.
But as ad blockers and security companies started to detect and block Coinhive, criminals went to greater lengths to mask their code. Our friends over at Sucuri have reported extensively on compromised websites running different flavors of Content Management Systems injected with creatively obfuscated versions of the silent Coinhive API.
Proxies also became more and more common, not to mention a growing number of new Coinhive-like services. Ultimately, maintaining a blacklist became a bigger—although somewhat expected—challenge.
In this blog, we take a look at an evasion technique used by miners to bypass list-based blockers and behavior-based detection by avoiding maxing out the user’s CPU. This kind of evasion is nothing new for those tracking malware campaigns, but it shows that it can be successfully applied to cryptomining as well.
The site in question alternates between two different versions of its miner to guarantee maximum exposure. The “classic” one makes a clear reference to coinhive[.]com, which can easily be detected and blocked. The second one is similar in syntax but instead uses a different hostname (npcdn1[.]now[.]sh). While it may not seem like a big difference, it’s enough to bypass the majority of blacklists.
As described by Denis Sinegubko of Sucuri in a blog post about malicious miners from GitHub, this case is part of a fake JQuery campaign running self-hosted DeepMiner web apps. Threat actors are abusing platform-as-a-service (PaaS) solutions in order to not only evade blacklists but also to avoid paying the 30 percent Coinhive commission by selecting the Monero mining pool of their choice.
The problem lies with essentially chasing an unlimited number of subdomains in what rapidly becomes a whack-a-mole game. As we were working on this blog, a new one (sxcdn3.now.sh) had just popped up and was still undetected by many of the publicly available blocklists.
Watching for CPU usage
Another way to detect browser miners is to monitor for CPU usage and essentially detect offending tabs that are consuming most of the processor’s cycles. This is a common behavior among most miners (malware or browser-based), where threat actors run unthrottled code without worrying about slowing down the visitor’s computer.
Since abusing the CPU can be a way to trigger cryptomining detection, threat actors will often throttle their miner to run below a certain threshold so that it blends in with normal activity. This was the case here, with the miner hovering around 80 percent CPU usage, which could very well have been generated by playing an online game.
The malicious cryptomining landscape is evolving at a rapid pace and forcing defenders to come up with new ways of proactively detecting and blocking this threat. Identifying server compromises requires more time spent deobfuscating suspicious looking scripts while at the same time coming up with more generic detection rules.
For end users, ad blockers and web blocking, in general, are still one of the best means to defeat cryptominers, but they also require constant updates to keep them at bay. It is important to understand the different mechanisms used by threat actors and in turn develop the most effective mitigation techniques.
Malwarebytes identifies and blocks domains or proxies involved in cryptomining activity but also flags sites that may be using evasion techniques to bypass standard blacklisting approaches.
Indicators of compromise
mxcdn1[.]now.sh mxcdn2[.]now.sh npcdn1[.]now.sh sxcdn02[.]now.sh sxcdn3[.]now.sh sxcdn4[.]now.sh sxcdn6[.]now.sh
The post Malicious cryptomining and the blacklist conundrum appeared first on Malwarebytes Labs.