Security researchers scanning public container registries this quarter flagged another wave of cryptomining malware buried inside images that, on the surface, looked like ordinary developer tooling. The pattern is not new — Docker Hub has been a soft target for cryptojacking campaigns since at least 2019 — but the latest sweep of tags across popular base-image namespaces found the same techniques still working: typosquatted repository names, layered obfuscation, and payloads that only activate once a container reaches a cloud runtime with real CPU to spare. Analysts pulled several hundred suspect images out of a sample of general-purpose repositories, a hit rate that tracks closely with figures Aqua Security first published years ago and that Sysdig, Unit 42, and Docker's own security team have echoed in subsequent reports. The takeaway for engineering teams pulling images by tag rather than digest: the threat did not go away, it just got quieter.
A Threat That Never Left
Cryptomining in containers is one of the oldest monetization plays in cloud-native attacks, and it persists because the economics still work. An attacker who can get unauthorized compute time — even a few vCPUs across a few thousand pulls — turns a public registry into a distributed mining rig paid for by someone else's cloud bill. Unlike ransomware or data exfiltration, cryptojacking doesn't need privilege escalation or lateral movement to pay off; it just needs the image to run.
That low bar for "success" is why the same malware families keep resurfacing under new names. XMRig, the open-source Monero miner, remains the payload of choice because it's legitimate, well-maintained, and trivial to bundle silently into an entrypoint script. Kinsing continues to show up in campaigns that specifically hunt for exposed Docker APIs and misconfigured daemons, deploying miners within seconds of gaining access. TeamTNT-style tooling — which combines credential harvesting with mining deployment — has been observed reusing worm-like propagation logic first documented years ago, updated just enough to dodge signature-based detection. None of this is exotic tradecraft. It's commodity malware wrapped in a container, distributed through a channel — Docker Hub, GHCR, and other public registries — that millions of pipelines pull from without a second look.
How the Images Get In
The delivery mechanism is almost always social rather than technical. Researchers consistently find malicious images using one of a handful of patterns:
- Typosquatting popular names. Images tagged to look like
nginx,redis,alpine, or a well-known CI helper, published under a namespace one character off from the official one. - Trojanized "helpful" utilities. Images that genuinely do what they advertise — a monitoring agent, a build tool, a Kubernetes helper — while also launching a background miner process that throttles itself to avoid tripping obvious CPU alerts.
- Abandoned or hijacked accounts. Legitimate publishers whose Docker Hub credentials were compromised, with a malicious layer pushed on top of an otherwise trusted image history, inheriting the trust and pull count of the original.
- Build-time payload injection. Dockerfiles that pull a script from a remote URL during
RUN, meaning the image itself can look clean in a static manifest review while the actual mining binary is fetched only at build or first-run time.
That last pattern is particularly relevant for supply chain security teams, because it defeats a purely metadata-based review. An image can pass a superficial check of its declared base and still execute a curl-pipe-to-shell instruction that resolves to different content depending on when it's built.
Anatomy of a Typical Payload
Once pulled, the pattern is remarkably consistent across families. The entrypoint or an init script drops a miner binary — frequently a renamed or repackaged XMRig — into a writable path, sets mining pool configuration pointing at infrastructure the attacker controls, and forks the process so it survives independently of the container's ostensible primary workload. Many samples include basic evasion: process names spoofed to resemble kworker or other kernel threads, CPU usage capped below thresholds likely to trigger autoscaling or cost alerts, and checks for the presence of monitoring agents (falling silent if datadog-agent, cloudwatch, or similar processes are detected).
The more advanced campaigns go further, harvesting cloud credentials mounted into the container — IMDS tokens, service account files, .aws or .kube configs left in the image or the runtime environment — and using them to pivot into the surrounding cloud account before or after deploying the miner. That combination is what elevates cryptojacking from an "annoying cloud bill" problem to a genuine supply chain security incident: the miner is often just the most visible symptom of a foothold that also enables credential theft and lateral movement.
Why Public Registries Remain a Soft Target
Three structural factors keep this attack surface open:
Tag mutability. Pulling image:latest or any mutable tag means the content behind that reference can change after a team has already reviewed it. A scan performed at adoption time provides no guarantee about what gets pulled in production six months later unless teams pin to a digest and verify it stays constant.
Registry scale versus curation. Public registries host millions of images with review processes that cannot manually vet each layer. Automated scanning catches known-bad signatures, but obfuscated or delayed-activation payloads routinely slip past first-pass moderation, especially when the malicious behavior only manifests at runtime.
Trust transitivity. Base images get built on top of other base images. A single compromised or malicious layer several hops up an inheritance chain can quietly propagate into hundreds of downstream images that otherwise look legitimate, and most teams have no visibility into that chain beyond the image they directly reference.
The Business Impact Beyond the Cloud Bill
The immediate cost is compute: unexplained CPU spikes, inflated cloud invoices, and autoscaling triggered by mining load rather than real traffic. But the second-order costs are what security and platform teams should weigh more heavily. Any workload compromised enough to run unauthorized code is a workload whose integrity can no longer be assumed — the same access that deployed a miner could just as easily have exfiltrated data or planted a backdoor. Incident response time spent identifying and rotating credentials after a cryptojacking event routinely exceeds the direct cost of the stolen compute. And because these images frequently enter through developer laptops or CI runners pulling "convenient" third-party tooling, the exposure often predates any formal security review entirely, making after-the-fact remediation slower and more disruptive than catching it at the image-pull stage would have been.
How Safeguard Helps
Safeguard is built to catch exactly this class of supply chain risk before it reaches a runtime environment where a miner can do damage. Every image pulled or built in a monitored pipeline is scanned and matched against a continuously updated SBOM, so unexpected binaries, injected scripts, or layers inherited from untrusted upstream sources are surfaced instead of assumed safe because the tag looked familiar. Griffin AI correlates that inventory against known cryptojacking indicators and behavioral patterns — mining pool domains, XMRig-family signatures, suspicious entrypoint scripts — and prioritizes findings using reachability analysis, so teams aren't buried in alerts for miner code that's present in a layer but never actually executed in their deployment path. When a genuinely exploitable issue is found, whether it's a malicious base image, a vulnerable dependency an attacker could piggyback on, or a misconfigured pull that isn't pinned to a verified digest, Safeguard can open an auto-fix pull request that swaps in the trusted image reference or patched dependency, cutting the time between detection and remediation from days to minutes. For organizations running large numbers of containers across CI and production, that combination of SBOM visibility, AI-driven prioritization, and automated remediation is the difference between finding cryptomining malware after the cloud bill arrives and stopping it before the image ever ships.