In February 2023, Sysdig's Threat Research Team disclosed PURPLEURCHIN, a cryptojacking operation that had automated the creation of thousands of free-tier accounts across GitHub Actions, Heroku, and Docker Hub to mine Monero at scale, using dozens of Docker Hub accounts publishing images whose sole purpose was hosting a miner. Cryptomining malware in container images is one of the most common payloads security teams encounter in cloud-native environments today, not because it is sophisticated, but because containers make it easy to hide, cheap to scale, and slow to notice. A miner running in a sidecar or buried in a base image doesn't crash a service or exfiltrate data — it just quietly burns CPU cycles until someone questions the cloud bill. This post covers how mining malware gets into container images, what an infection looks like at runtime, which malware families to watch for, and how to catch it before it ships.
What is cryptomining malware in a container image?
Cryptomining malware — often called cryptojacking malware — is code embedded in or dropped onto a container that hijacks CPU or GPU cycles to mine cryptocurrency, almost always Monero (XMR), for an attacker's benefit without the operator's knowledge or consent. Monero is the currency of choice because it's CPU-mineable (no specialized ASIC hardware needed) and its ring-signature design obscures the destination wallet, making payouts hard to trace. The actual mining is usually done by XMRig, a legitimate open-source Monero miner that attackers repackage and drop into a container, sometimes renamed to mimic a system process like kworker or systemd-worker to blend into ps output. Containers are attractive hosts because they're ephemeral, frequently over-provisioned, and rarely monitored for CPU baseline deviations the way a production database server would be — a compromised build agent or an idle dev namespace can mine undetected for weeks.
How does cryptomining malware get into a container image?
Cryptomining malware reaches container images through four recurring paths: malicious public images, exposed orchestration APIs, compromised CI/CD pipelines, and unpatched application vulnerabilities. The oldest documented case is still instructive — in 2018, researchers at Fortinet and Kromtech traced 17 Docker Hub images published by a user named "docker123321" that had been pulled over 5 million times and had reportedly mined roughly $90,000 worth of Monero over about two years before Docker removed them. More recently, Kinsing malware — first documented by Aqua Security's Team Nautilus in January 2020 — spreads by scanning the internet for exposed Docker Remote APIs on port 2375 and misconfigured Kubernetes kubelets, then drops a shell script that disables the host's existing security tools and installs XMRig. Kinsing's operators are also fast: Cado Security reported the group weaponizing CVE-2022-26134, a Confluence OGNL injection flaw, within hours of public disclosure in June 2022 to deploy miners on unpatched servers. Compromised CI/CD credentials and typosquatted base images (a python:3.9-slimm instead of python:3.9-slim, for instance) round out the common entry points.
What does a cryptomining infection look like at runtime?
A cryptomining infection typically shows up as sustained, near-100% CPU utilization from one process, combined with outbound connections to mining-pool infrastructure on ports like 3333, 5555, or 7777. Because XMRig needs to talk to a pool to submit mining shares, network traffic will often contain stratum+tcp:// or stratum+ssl:// URLs pointing at pool domains such as pool.minexmr.com or xmr.gntl.uk. Container orchestrators tend to surface the symptom indirectly first: pods get OOM-killed or throttled as the scheduler tries to reclaim CPU the miner is hoarding, and autoscalers spin up extra nodes to compensate — which is usually how finance teams notice before security does. Sysdig's 2021 Cloud-Native Threat Report quantified the economics: for every $1 of cryptocurrency an attacker mined, the victim organization was billed roughly $53 in extra cloud compute costs, which is why a mining infection is as much a cost incident as a security one.
Which cryptomining malware families most commonly target containers?
Four campaigns account for most of the container-focused cryptojacking activity tracked since 2020: Kinsing, TeamTNT's Hildegard, Sysrv-hello, and PURPLEURCHIN. TeamTNT, active since May 2020, built its reputation harvesting AWS and Docker credentials from misconfigured hosts before deploying XMRig; its Hildegard variant, documented by Palo Alto Unit 42 in January 2021, specifically targeted misconfigured Kubernetes kubelets and used an IRC channel and a legitimate-looking tmate.io session for command and control. Sysrv-hello, a Go-based worm tracked by Juniper Networks starting in 2021, exploits known RCEs in WordPress plugins, Spring, and Atlassian Confluence to install a miner and a self-propagating worm component on any reachable container or VM. PURPLEURCHIN distinguished itself in early 2023 by abusing free-tier CI/CD compute rather than compromising victim infrastructure directly, showing attackers will mine wherever cycles are free, not just where they're stolen.
How can security teams detect cryptomining malware before it reaches production?
Security teams detect cryptomining malware before deployment by scanning image layers and their software bill of materials (SBOM) for known malicious binaries and hashes, rather than waiting to notice a CPU spike after the image is already running. Effective pre-deploy detection combines a few checks: matching binaries in each layer against known XMRig and miner-dropper hashes, flagging UPX-packed or unusually obfuscated executables added outside the normal build process, verifying base image provenance and signatures against expected publishers, and diffing SBOMs between builds to catch packages or binaries that appear with no corresponding line in the Dockerfile or lockfile. This last check matters because most miner injections don't touch application source code at all — they add a binary and a cron job or entrypoint override, which a dependency-only scan will miss but an SBOM diff will not.
How do you stop a cryptomining infection from spreading once it's in a cluster?
You stop a cryptomining infection from spreading by cutting off the two things it needs — network egress to a mining pool and the privileges to pivot to other nodes. In practice that means blocking egress to known stratum ports and pool domains at the network policy layer, running containers with readOnlyRootFilesystem: true and dropped Linux capabilities like CAP_SYS_ADMIN so a dropped miner script can't persist or re-exploit the host, and using admission controllers to reject unsigned or unscanned images at the Kubernetes API server before they're ever scheduled. Combined with automated eviction of any pod that trips a CPU-baseline anomaly, these controls turn a mining infection from a slow-burning cloud-cost problem into a contained, single-pod event.
How Safeguard helps
Safeguard closes the gap between a base image with a known vulnerability and an attacker actually landing a miner on your infrastructure. Our reachability analysis tells you whether the CVE a scanner just flagged — say, a Confluence or ActiveMQ RCE of the kind Kinsing has weaponized within hours of disclosure — is actually exploitable in your deployed configuration, so teams patch the paths attackers use instead of chasing every CVE with a high CVSS score. Griffin AI, Safeguard's detection engine, correlates SBOM data, image provenance, and runtime signals to flag the miner-dropper patterns and unexpected binaries that a pure dependency scan misses. Safeguard generates and ingests SBOMs automatically on every build so you can diff them across versions and catch additions that never appeared in a Dockerfile or lockfile, and where a fix exists, Safeguard opens an auto-fix pull request against the vulnerable base image or dependency so the exposure window closes in minutes rather than the hours attackers need to weaponize it.