Common entry vectors: vulnerabilities in exposed services (from Log4Shell to unpatched admin panels), trojanised container images in public registries, compromised dependencies in the supply chain, cloud keys leaked in repositories and compromised credentials.
What is cryptojacking?
Cryptojacking is the unauthorised use of your endpoints, servers, containers or cloud accounts to mine cryptocurrency for an attacker's benefit. Unlike ransomware, it breaks nothing visible: the goal is to stay unnoticed for as long as possible while the victim pays the bill in electricity, degraded hardware or — the most expensive case — runaway cloud spend. It is silent-monetisation malware: it turns any compromised CPU or GPU into money, almost always mining Monero with variants of XMRig.
Why does it matter?
Because the miner is never the whole problem: it is proof that someone has code execution inside your infrastructure. The same access that mines cryptocurrency today can deploy ransomware, steal data or be sold to another group tomorrow; campaigns like TeamTNT or Kinsing combine mining with theft of credentials and lateral movement into everything they can reach. In the cloud the impact is direct and measurable: with leaked API keys, attackers spin up compute instances — often GPU — and the bill can grow by tens of thousands of euros in days before anyone looks at the billing console. In container and Kubernetes environments, mining is the default payload of bots scanning the Internet for exposed Docker APIs and misconfigured clusters: if your infrastructure is reachable, there will be a miner inside within hours, not weeks. Treating it as a minor nuisance is misreading the signal.
Key points
On endpoints: XMRig-based miners disguised as legitimate system processes, with deliberate throttling (capping their own usage or pausing when the user is active) to avoid triggering suspicion or fans.
In the cloud: attackers do not always infect your machines — with sufficient permissions they create their own. GPU or oversized instances in regions you never use, launched with stolen credentials, where the first symptom is usually the invoice. Billing and usage-anomaly alerts are a security control, not just a financial one.
In containers and Kubernetes: exposed Docker APIs, unauthenticated dashboards and pods deployed with names mimicking system components. Automated campaigns like Kinsing or TeamTNT exploit these gaps within minutes of deployment; a CWPP with runtime detection is the specific countermeasure.
Detection: sustained, out-of-pattern CPU/GPU usage, outbound connections to mining pools (the stratum protocol, characteristic DNS lookups), processes with suspicious command lines and EDR behavioural detections. Correlating these signals in a SOC separates a miner from a false positive.
Correct response: killing the process is the easy part. You must identify the entry vector, hunt for persistence (cron, systemd, DaemonSets, serverless functions), rotate the credentials involved and review what else the attacker did with that access. Otherwise the miner comes back — or something worse does.
Example: cloud bill blown up by mining in a Kubernetes cluster
A software company notices its monthly cloud bill has tripled with no business change to explain it. Cost analysis points to a node group running at sustained 100% CPU in a development cluster. Inside, several pods with names mimicking legitimate system components are running XMRig against a Monero pool. The origin: a Kubernetes API reachable from the Internet with an over-permissive role, found by a bot that deployed the miners in a fully automated way — the exact pattern of campaigns like Kinsing.
What worked was treating it as an incident, not an outage: isolating the cluster, capturing evidence, removing the persistence DaemonSets, closing the API exposure, rotating every credential and service account in the cluster and reviewing logs for lateral movement into other projects. Then prevention: admission policies for images, per-namespace resource limits, billing alerts with per-project thresholds and outbound monitoring for mining-pool connections from the SOC. The real cost was not the invoice: it was discovering that anyone had been able to run code in that cluster for weeks.
Common mistakes
- Treating it as minor because it 'only mines'. The miner proves remote code execution in your infrastructure; the same access serves ransomware or data theft, and sometimes has already been used for both by the time it is discovered.
- Cleaning up the miner without investigating the entry vector or persistence. If the hole stays open — the exposed API, the leaked key, the unpatched service — the miner returns within days, often improved.
- Not watching cloud billing as a security signal. Cost and usage-anomaly alerts catch cryptojacking earlier than many technical controls; without per-project thresholds, the first notice is the end-of-month invoice.
- Relying on traditional antivirus alone. Miners in containers, fileless techniques and instances created by the attacker inside your cloud account never touch an endpoint's disk; you need EDR, runtime detection and network monitoring.
- Ignoring the environments 'that don't matter': development clusters, lab machines, secondary cloud projects. They get the least scrutiny, hold credentials connected to everything else, and are exactly where miners live longest.
Related services
This concept may be related to services such as:
Frequently asked questions
Our cloud bill doubled this month for no apparent reason: how do I confirm whether it is cryptojacking?
Start with the cost breakdown: identify which service, project and region concentrate the increase. The typical signals are instances you do not recognise (especially GPU or oversized ones), regions your company never uses and sustained maxed-out CPU on existing resources. Then check the provider's audit logs (CloudTrail, Azure Activity Log, GCP Audit Logs): who created those resources, with which credential and from where. If an API key or service account shows up with permissions it should not have, assume compromise: rotate credentials, isolate the project and treat it as an incident, not a misconfiguration. And leave per-project budget alerts configured: they are the cheapest detector there is.
How do I detect cryptojacking on my company's machines if we have no in-house SOC?
With three affordable layers. First, a modern EDR on endpoints: the most common miner families (XMRig and derivatives) are well covered by behavioural detections, not just signatures. Second, network signals: outbound connections to mining pools follow recognisable patterns (the stratum protocol, well-known pool domains) that a firewall with DNS filtering can block and alert on. Third, physical symptoms still count in smaller companies: machines persistently slow, fans spinning up while "idle" and laptop batteries lasting half as long. If there is no internal capacity to watch those signals, a managed SOC outsources exactly that correlation and triage.
Is cryptojacking really dangerous if it 'only' steals computing power?
Yes, for three reasons. The first is visible: direct cost in electricity, hardware degradation and cloud bills that can reach tens of thousands of euros. The second is invisible: the miner proves someone is executing code in your infrastructure, and groups like TeamTNT or Kinsing do not stop at mining — they steal credentials, plant backdoors and move laterally while the miner generates revenue. The third is what it reveals: if an automated bot got in, your attack surface had a gap any targeted attacker would also have found. A discovered miner deserves the same investigation as any other intrusion: vector, scope, persistence and what else was done with that access.
We deploy with containers and Kubernetes: how do I stop them from ending up mining for someone else?
Close the three gaps automated campaigns exploit. One: exposure — no Docker or Kubernetes API reachable from the Internet without strong authentication, and dashboards always behind controlled access. Two: supply chain — only images from trusted registries, scanned before deployment, with admission policies that reject unsigned images; miners embedded in popular public images are a classic. Three: runtime — per-namespace resource limits (a pod requesting all available CPU is a signal, not normality), runtime detection with a CWPP or equivalent tooling, and outbound connection monitoring. A periodic cloud security review validates that these barriers are still standing as the cluster evolves.