Cryptojacking in the Cloud: From Cost Anomaly to Root-Cause Credential Leak

Cybersecurity

Cryptominers are the loudest quiet incident in cloud. Walk through XMRig and kdevtmpfsi artifacts, EC2 instance-type flips, the AWS cost signal that catches it first, and why the real fix is almost always rotating a leaked key.

By Arjun Raghavan, Security & Systems Lead, BIPI · July 3, 2024 · 7 min read

Cryptojacking is rarely the breach you fear most, but it is almost always the breach that tells you a worse one is possible. A miner running on your fleet means an attacker has code execution and persistence somewhere, and your detection stack let it idle long enough to be worth their compute time. The investigation is short, the cleanup is long, and the root cause is almost always boring.

The signal that catches it first

In cloud environments, the bill detects it before the SOC does. AWS Cost Anomaly Detection, GCP billing anomalies, or even a finance question about why EC2 spend doubled this week is how most cryptojacking incidents enter the queue. The second-most-common entry point is GuardDuty or Defender for Cloud surfacing CryptoCurrency:EC2/BitcoinTool.B!DNS or a known mining pool destination.

Endpoint signals to confirm: sustained CPU at or near 100% across all cores, sudden network egress to known mining pools (xmr-pool, supportxmr, nanopool), and process names that try to look legitimate (kdevtmpfsi, kinsing, kthreaddi, xmrig). On Linux, /tmp and /var/tmp are the favourite drop paths.

EC2 instance-type tampering

A pattern worth knowing: attackers with sufficient IAM access will modify Auto Scaling launch templates to upgrade instance types from t3.medium to c5.4xlarge or larger, because mining margins are dominated by raw core count. CloudTrail will show ModifyLaunchTemplate, RunInstances, or RequestSpotInstances events from an identity that has no business resizing fleets. Sometimes they flip an entire ASG to spot pricing across new regions you do not normally operate in.

On-host artifacts: XMRig, kdevtmpfsi, kinsing

Pull a triage image with KAPE on Windows or UAC on Linux. The minimum viable artifact set is process listing, network connections, cron entries, systemd unit files, /tmp, /var/tmp, ~/.config, and shell history for any user the attacker pivoted through. kdevtmpfsi is the binary you will most often find; it is dropped by the Kinsing malware family and persists via cron or systemd timer. Kinsing also writes to /etc/ld.so.preload to hide its process from ps, so always cross-check via /proc directly or use unhide.

On Kubernetes nodes, miners typically land via a compromised container image or a kubectl exec from a leaked kubeconfig. Falco rules for spawned shell in container, write below etc, and outbound traffic to mining pool will catch them at runtime if you have it deployed. Without Falco, the only signal is the pod's CPU graph in Prometheus and the egress destination in VPC flow logs.

Root cause: almost always a leaked credential

Trace backwards. Who created the rogue instances or pods? Which IAM key signed those CloudTrail events? Almost every cryptojacking case I have run ends at one of three sources: a long-lived IAM access key checked into a public GitHub repo, a Jenkins or GitLab runner with the AWS profile mounted, or an SSRF in a web app that exposed EC2 instance metadata and minted temporary credentials. The GitHub case is so common that AWS proactively quarantines exposed keys, and the attackers race to use them in the few minutes before quarantine fires.

Cleanup that actually holds

Killing the process and terminating the instance is not remediation, it is symptom management. The credential that authorised the spawn is still valid, and the attacker will respawn within hours. The order that works:

What to learn for next time

Cryptojacking is a free penetration test of your IAM hygiene. The miners are loud, the detection is cheap, and the credential gap they expose is the same gap a more disciplined actor would use to exfiltrate data instead. Treat every cryptojacking ticket as a credential-management incident first, and a malware incident second.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.