Safeguard Threat Research — July 2026. Between mid-May and late June 2026, Safeguard's research team tracked a coordinated cryptojacking campcampaign distributing malicious container images through Docker Hub's public registry. The operation, which we internally track as HIDDEN-SHAFT, placed at least 41 trojanized images across 17 distinct publisher accounts, several of which impersonated legitimate base-image maintainers through single-character typosquats (nginx-official, redis-cache, python3-slim). Combined pull counts across the identified images exceeded 320,000 by the time Docker Hub took down the last known account on June 27, 2026 — a window of roughly six weeks during which the images were freely discoverable via standard search and "most pulled" sorting.
The campaign is notable less for technical novelty than for operational discipline: payload staging was delayed, execution was conditional on environment fingerprinting, and the cryptomining payload itself was fetched post-pull rather than baked into the image layers — a pattern designed specifically to defeat static image scanning performed at push time or during CI.
What Made HIDDEN-SHAFT Different
Docker Hub cryptojacking is not new. Campaigns dating back to 2019 — and heavily documented incidents in 2021 and 2023 — established the basic playbook: publish a plausible-looking image, embed a miner, wait for pulls. What distinguished this campaign, and what prompted our team to open a formal tracking designation, was a three-stage delivery chain built to survive exactly the kind of scanning most organizations already run.
Stage 1 — Clean image, dirty entrypoint. The published image layers contained no miner binary, no XMRig strings, and no suspicious base64 blobs that would trip signature-based scanners. Instead, the ENTRYPOINT invoked a small Go binary (under 900KB) whose only job was to check for the presence of a debugger, container runtime metadata consistent with a sandbox (short uptime, absence of /proc/1/cgroup entries typical of production orchestration), and outbound network reachability to a specific set of domains before proceeding.
Stage 2 — Delayed payload fetch. If the environment checks passed, the binary slept for a randomized interval between 45 and 90 minutes — long enough to outlast most CI/CD pipeline scanning windows and many sandbox-based dynamic analysis tools — before pulling the actual miner payload from a rotating set of GitHub Gist raw-content URLs and Codeberg mirrors.
Stage 3 — Miner deployment with resource throttling. The final payload was a modified XMRig build configured to cap CPU utilization at roughly 40-60% of available cores, specifically to avoid the kind of "pegged at 100%" resource alarms that tend to get a compromised host investigated within hours. Wallets observed in the mining pool configuration were associated with two Monero pools already flagged in unrelated 2025 cryptojacking reporting, suggesting either payload reuse across campaigns or a shared operator.
Distribution Mechanics
Rather than relying purely on organic discovery, the campaign used two amplification techniques worth calling out because they are easy for defenders to miss.
First, tag churn: the same repository would publish a legitimate-looking latest tag alongside dozens of versioned tags (3.11.4-alpine, 3.11.4-slim, 3.11.4-bookworm) to game Docker Hub's popularity and freshness signals, and to maximize the chance that an automated dependency-update bot or a developer's docker pull with a pinned-but-wrong tag would grab a compromised variant.
Second, Dockerfile FROM-chain laundering: several downstream images in public GitHub repositories built FROM one of the compromised base images, meaning organizations that never directly searched Docker Hub for the malicious name still inherited it transitively through a base image reference buried three or four layers deep in a Dockerfile they trusted. In our sample set, 6 of the 41 identified images had at least one downstream public repository building on top of them, and one — a typosquatted alpine-curl variant — had 14 downstream forks.
Why Standard Scanning Missed It
Most container image scanning in production pipelines today is built around one core assumption: malicious intent is visible in the image's static layers. HIDDEN-SHAFT was engineered around that assumption. There was no miner binary to hash-match, no suspicious package to flag via CVE or malware-signature databases, and the entrypoint binary itself was small enough and generic enough in its initial behavior to pass casual manual review.
Three factors made the campaign viable for as long as it was:
- Delayed detonation defeated time-boxed sandbox analysis, which typically observes container behavior for seconds to a few minutes.
- Environment-aware execution meant the payload never fired inside the security vendors' own sandboxes, most of which are trivially fingerprinted as non-production.
- Base-image inheritance meant organizations pulling a downstream image had no direct visibility into the fact that their
FROMchain terminated in a compromised upstream repository — a supply chain relationship most SBOM tooling of the era captured incompletely, if at all.
Impact Snapshot
- 41 malicious images identified across 17 publisher accounts on Docker Hub
- 320,000+ cumulative pulls before takedown
- ~6-week active window (mid-May to June 27, 2026)
- 14 confirmed downstream public repositories inheriting the compromised base image transitively
- Estimated aggregate mining yield, based on pool-side hashrate contribution during the active window, in the low six figures (USD equivalent) — consistent with a mid-tier, not top-tier, cryptojacking operation, reinforcing that this was one of several concurrent campaigns rather than a singular large actor
Why This Keeps Happening
Docker Hub cryptojacking campaigns persist because the economics remain favorable for attackers and the detection gap remains structural rather than incidental. Publishing an image costs nothing. Typosquatting a popular name costs a few minutes. And the payoff — compute stolen at someone else's cloud bill — scales automatically with however many organizations pull the image, with no additional effort from the attacker. Meanwhile, the defensive side of this equation is still largely oriented around scanning what's declared, not what's actually reachable or actually executed. A miner that never appears in a layer manifest, that only activates outside a sandbox, and that arrives three Dockerfile hops away from where a developer typed docker pull, is specifically engineered to slip through exactly the controls most teams believe they already have in place.
How Safeguard Helps
Safeguard is built to close the gaps that campaigns like HIDDEN-SHAFT are explicitly designed to exploit. Our SBOM generation and ingest pipeline traces the full FROM-chain lineage of every container image, so a base image compromised three or four layers upstream is surfaced as a direct dependency risk rather than an invisible transitive relationship — the exact blind spot that let 14 downstream repositories inherit this campaign's payload without warning. Reachability analysis goes further than static layer scanning by evaluating whether flagged components and behaviors are actually exercised in your deployment context, helping teams prioritize the handful of images that matter out of the noise of every base image ever pulled. Griffin AI, Safeguard's threat-analysis engine, is tuned to recognize the behavioral fingerprints of delayed-detonation and environment-aware payloads — the sandbox-evasion techniques that let this campaign's entrypoint binary pass casual and even automated review — rather than relying solely on known-bad hash matching. And where a compromised or typosquatted base image is identified in your dependency graph, Safeguard can open an auto-fix pull request that repins the Dockerfile to a verified, trusted source, turning a multi-hour incident response scramble into a reviewable code change. Together, these capabilities are designed to catch what signature-based scanning was never built to see.