Avoid Becoming a Victim of Cryptojacking

Cryptocurrencies continue to divide people. Without question, the criminal world is a fan of these unregulated financial instruments, using them for payment for services rendered and stealing them – or stealing the way to make them – when they can.

By Dave Cartwright, CISSP
19 April 2023

Cryptocurrencies are strange beasts, because crypto-money is created pretty much out of thin air: you give up some of your computer’s time to do complex calculations, and in return you get a little bit of whatever cryptocurrency you’ve signed up to; this process is called “mining”. Of course, it only makes sense if the value of cryptocurrency you receive is greater than the equipment and power cost it took to mine it … and of course one way to keep your costs down is to use someone else’s kit and electricity. And that’s the raison d’etre of cryptojacking: putting hidden crypto-mining code on unsuspecting people’s computers and leaving them to mine away for your benefit at the owner’s expense.

The world’s relentless drive to move IT to the cloud brings opportunities for attackers: after all, everything in the cloud is by definition “out there on the internet” and thus potentially visible to attackers. And the bills incurred as a result of someone injecting crypto-mining code into a cloud-hosted IT setup can be wildly unaffordable: cloud-focused security vendor Sysdig, in its 2022 Cloud Native Threat Report, argued that to illicitly mine $8,100 worth of cryptocurrency can result in a $430,000 spike in the victim’s cloud bill – but of course the attackers only care about their income, not the expense. And as Mike Isbitski, director of cybersecurity strategy at Sysdig, put it: “If you think about, for an attacker, this is very low effort, right? And they're getting rewarded for it”.

Accidentally Infecting Yourself
An interesting way for illicit crypto-mining code to get into your cloud setup is for you to put it there yourselves – albeit unwittingly. Rather than attempting to break into your cloud instance, it makes more sense (in principle, at least) for the bad guys to look “upstream” in your supply chain, to the places and vendors from whom you source the apps you run in your cloud. After all, why bother to attack an individual organization if you can poison the software upstream and let dozens, hundreds or even thousands download and install it for you? It’s precisely what happened in 2020, when the installer for SolarWinds’ Orion network management platform was altered to provide a “back door” for attackers once a customer had installed the latest version, resulting around 18,000 organizations globally – including government and household-name companies – being affected.

In a February 2023 webinar, Isbitski looked at an example involving cloud-based containers: in short, if the attackers can get their code into the container repository, the next time you update your containers from that repository, you’re doing the attackers’ job for them. As he put it: “So [attackers] will embed crypto miners into dependencies, and particularly container images. And then when you source those things, and instantiate them in your environment, lo and behold, you have a malicious crypto miner running, right? So that's a crypto jacking attack. How does it get there? Like I said, it's often embedding within the container image. So, maybe targeting public registries and repositories to get that miner in there. And then once it's executing, right, it's just it's kind of paying out to that attacker’s wallet”.

At-Risk Dependencies Are Everywhere
We must not, for a moment, think that the threat is limited only to container-based technology. When Isbitski mentioned “dependencies” in the previous example, these can be anything you might download and install, such as patches for your database server, updates for your email platform or – of course – the latest version of your network management package. Nick Lang, threat researcher at Sysdig, talked about what they see in a non-container world in their “honeypot” systems. “If you're running out of date, for example, you know Apache Tomcat, I see a lot of attacks on our Tomcat and the honeypot, and it's almost always to exploit some vulnerability that's been out for three or four years,” he said.

So, what can you do to defend yourself against cryptojacking?

First of all, defend yourself against attacks in the usual ways – while the examples we’ve talked about related mainly to supply-chain attacks, there are still plenty of threats directed straight at your own systems. Just bear in mind that you’ll need to do more – after all, your anti-malware software won’t complain if you’re using malicious code that isn’t a virus. The way to go is to “assume breach” and consider the behaviors of the malicious code once it’s in your systems.

What’s Using Your CPU Cycles?
CPU loading on your systems is an obvious place to look, because the nature of the beast is that it’ll use extra CPU cycles on top of what your own legitimate kit uses. This is arguably our equivalent of how you find a cloaked spaceship. Hidden or otherwise, there’s always a detectable engine output. Ironically, your best chance of spotting unusual activity comes if the attackers simply go for a quick-and-dirty win – that is, set their code to spin up and use as much resource as it possibly can in the time before you spot it. Michael Clark, Sysdig’s director of threat research, explained: “A lot of times … they will try to get on any compute [platform] they can and run. And … obviously they can scale. That's the best case for them. And we see this often with stolen secrets, or leaked API keys and things like that”. An attacker who goes for a more long-term approach may write their code to limit CPU usage to avoid creating obvious spikes. Lang agreed: “even big popular projects can get hit for days at a time and before anyone realizes”, noting also that “if you have some kind of monitoring setup, and you're noticing CPU usage, another huge easy win”.

The next step is to look out for the traffic that the malicious code is generating – indicators of compromise as cyber people call them. As Lang put it: “looking in your traffic for those IOCs towards mining pools – huge, easy win”.

For effective defense, though, you need to consider some much more in-depth activity on the software and systems you’re running – or, more accurately, the software and systems you’re installing. In a cryptojacking attack your software goes from a version with no bad code to a version containing bad code, and so you need controls over that change in version. Lang again: “It gets a little bit more complex … you're getting into the territory of SBOM (software bill of materials) – and really knowing your application from inside to out … so I don't recommend that everyone read every single line of code, they import, it’s just not feasible. But if you have a good version of something, and it doesn't have any CVEs, maybe don't use the nightly build”. This last point is key: if the effort of looking for bad things is proportional to the number of times you install an update, then updating less regularly reduces the effort requirement.

Test Before You Deploy
Finally, don’t just wait until software has been deployed – do what you can to detect issues before double-clicking the installer. The last comment goes to Lang: “doing stuff in CI [continuous integration], and CD [continuous deployment] is a lot easier than trying to catch it at runtime. So, setting up some kind of security scanner, or even just using the built in ones that come with these tools. Like if you use Node.js, NPM has this audit tool that will tell you all the vulnerabilities in all the packages, and it will prioritize them everything for you. So again, something like that set up in CI and CD is also a huge one, that is a little bit more effort, but it's worth it as well”.