By Assaf Morag, Cybersecurity Researcher
Docker Hub is the world’s largest public container registry and a foundational component of the modern software supply chain. Millions of developers and organizations rely on Docker Hub daily to pull base images, application runtimes, and infrastructure components that power everything from local development environments to production cloud workloads.
This central role also makes Docker Hub an attractive target for abuse.
Container images are often trusted implicitly, pulled automatically by CI/CD pipelines, orchestration platforms, and infrastructure-as-code workflows. When malicious actors succeed in distributing harmful images through a public registry, they effectively gain access to downstream environments at scale, turning the container ecosystem itself into a supply-chain attack surface. In this research, we uncovered multiple cryptomining campaigns abusing Docker Hub to distribute malicious container images at a significant scale.
The malicious container images we found are located here.
Key Takeaways
- Docker Hub remains an active distribution channel for malicious container images
- Cryptomining campaigns can persist for years while accumulating millions of pulls
- Image naming, size, and impersonation of legitimate technologies are key deception tactics
- AI-themed imagery is now being abused as social engineering for developers
- Supply-chain security must extend beyond source code to container registries and artifacts
Initial Discovery: Active Exploitation via Malicious Images
Our investigation began with the discovery of a small but active campaign centered around the container image: renegadefuel/renegadefuel:latest
The malicious container images page on Docker Hub
This image was observed actively targeting misconfigured Docker APIs, a recurring and well-documented attack vector in cloud and on-prem environments. Open Docker APIs allow unauthenticated attackers to deploy arbitrary containers, making them ideal targets for opportunistic cryptomining campaigns. We observed this image being used in active exploitation attempts surfaced through Shodan, indicating real-world abuse rather than dormant or experimental activity.
We found it attacking via Shodan:
Indications for live attack on Shodan
When inspecting the container image itself, we detect this entrypoint script, which is set to run when running the container and running the cryptominer.
The malicious entrypoint.sh script that runs when the container start
Dormant but Massive: A Large-Scale Docker Hub Mining Cluster
Beyond the initial active campaign, we identified a much larger and more concerning cluster of dormant cryptomining container images hosted on Docker Hub.
This cluster consists of 64 distinct container images, following a consistent naming pattern:
<hex-namespace>/<technology-name>:<hex-tag>Key characteristics:
- Upload period: June 26, 2021 – September 15, 2021
- Total pulls: 6,498,377
- Stars: 0
- Average image size: ~314 MB (range: 313–316 MB)
Uploads of malicious images to Docker Hub by date
Despite the massive number of pulls, these images show no community engagement, documentation, or legitimate usage signals, which are strong indicators of automated or deceptive consumption rather than organic adoption.
Inside the Container: Mining on Execution
Inspecting the container image revealed a deliberately simple structure. The filesystem resembles a minimal Ubuntu-based image, containing:
- A directory named xmrig
- A secondary directory named after a legitimate technology (e.g., Gradle)
Inside this second technology-named directory, we found a single binary file. Based on VirusTotal analysis, this binary is a cryptominer.
Crucially, the container’s CMD and entrypoint are explicitly configured to execute the cryptominer upon container startup. This means that any user running the image (intentionally or not) immediately executes mining malware. There is no additional loader, exploit, or user interaction required.
The filesystem of the Gradle container
Hiding the cryptominer under the Gradle directory
After we uploaded the binary to Virus Total it was marked as malicious
The initial CMD that runs the cryptominer
Masquerading as Legitimate Infrastructure
The images in this cluster impersonate a wide range of common enterprise and cloud technologies, including:
- Databases & Data Stores: MySQL, MariaDB, PostgreSQL, MongoDB, Neo4j, Redis, Memcached, Zookeeper
- Web Servers, Proxies & Gateways: Nginx, Apache HTTPD, Traefik, Kong
- Application Platforms & Runtimes: Java / OpenJDK, Python, PHP, Node.js, Ruby, Perl, Bash, Erlang
- Frameworks & CMS: WordPress, Drupal, Rails, Nextcloud
- DevOps & CI/CD: Docker, Docker Swarm, Jenkins, Consul
- Observability & Logging: Kibana, Logstash
- Messaging: RabbitMQ
- Application Servers: Tomcat
- Build Tools & Compilers: Gradle, GCC
- Standalone Languages: Rust, Swift
This breadth strongly suggests an intent to blend into normal infrastructure usage patterns, increasing the likelihood that these images are pulled automatically by scripts, templates, or misconfigured pipelines.
A Second, More Recent Cluster: AI-Themed Deception
We also identified a second, smaller cluster consisting of 10 container images, but with more recent activity:
- Upload window: August–November (year-over-year monthly pushes)
- Total pulls: 31,462
- Stars: 0
This cluster uses a different naming strategy:
- Random or plausible namespaces (e.g., sandcorp, reymen44)
- AI-themed image names such as: tensor-train-vis, ai-train, predict
- Uniform 0.0.0-style versioning
The use of AI-related terminology appears designed to capitalize on current hype and curiosity, increasing the likelihood of opportunistic pulls by developers experimenting with machine-learning workflows.
Inside the Container: Mining on Execution via Tor
Inspecting the container image revealed a deliberately simple structure:
An entrypoint shell file running Tor and the cryptominer:
The malicious entrypoint script running Tor and the cryptominer
The name of the container (insights for instance) is under /bin/<container_name>:
The cryptominer (its name is similar to the container image name)
The cryptomining configuration is under etc/<container_name>/config.json:
The cryptominer’s configuration file
Based on VirusTotal analysis, this binary is a cryptominer:
The binary was marked as malicious on Virus Total
Infrastructure Monetization: Following the Money
Across this second cluster, we identified 10 distinct Monero (XMR) wallets tied to the mining operations.
Based on transaction analysis across multiple time windows spanning approximately four months, we estimate that this infrastructure generated:
- ~35–40 XMR total
- ≈ $5,200–6,300 USD
- Paid out via highly regular, fully automated Monero transactions
- Consistent mixin usage, indicating standardized mining configuration
The payout patterns strongly suggest long-running, industrial-scale cryptomining, likely executed through containerized and cloud-based deployments rather than ad-hoc manual usage.
Below is a list of the Monero crypto wallets:
- 86ZJF2powbsBdgrCvijNnG6VmNPiCUtJ7AvA9txEir7bDpy51UHaRpsUVRwPKy1Ck6M76jfSWS1GBjKkBCYaHhhy99YRGSh
- 8ANFj4CKyP21CrJR38tw2LTXSd6LDbY1SMaVUp5dGYt4YtVaQXAg6kCYszR1Qa4hRegsw8AvjENBZRz4nqS8xzPHJBQyon5
- 83hCPtDuvJ7i7htkaaHZPgj2mijX5s5awZ4jnv46iM53Ap2t9SVZczw3Ta7ksKtbmUQgNrkr6qirNAyGWrvGWEvDP7AuHs2
- 82miFUyQT7f4gUdHG2jJtjDoVNNavCYoK7N61MrQ1drX7pvTMmRLycYVffLJCoEZpv2wDWCivDmkDKwxb2hK5Q2WSsH5hdb
- 884NyZgThwgYrsok1SWDkX5KXzTjYAAiRhQw36EBD87PNZqfiWhcXb574nDdczMmKNdxEbJUJLhV7UrhaqGm5Qk8PjmVKtY
- 87EhDrK8emZddUheNPYusrj3J5sDgsdc3HUfyHXzjoZUFGMdidgZ3z1P1vXSGbgY3VbTBJHffH9EkFykbriizER7FvTFUBo
- 894sKh2WCsq7YcHJ2yfipkA7U9Fmo2wHRgYUaV5PKCG4RZHWqfS7cmPfBsfx6Yu6pUMXWNuHKm4hffT7mKrNCm5hTxwF5Pw
- 8AKTc8Gym3EawazbM7yS9RgZqByFUa479jU1cskRxu78Pndsx7sjfgw48ZFpy6Ff8yYKb9EegqigN1p6XrboxBRi18JpFtH
- 83yZSzPrWQQLtsWcyt7J8DYTptUFCoe5q9WzDRCpWCUjWiZintNdYj4AL3VroqGfEUSLWWr1dTZLechhu9fVakCANAvgxdk
How We Discovered This in Flare
Below, you can observe how we set the search filters to easily find malicious container images.
The steps we took:
1. Under events → Global Search: We searched for “xmrig” in that sense, you can look for a specific rootkit (Diamorphine) or malware (Tsunami).
Searching for “xmrig” on Flare
2. We selected two sources. Open web – source code, which includes GitHub and Docker Hub. Additionally, we included Emerging sources and Docker Hub files, these are the actual files inside the different layers. This is the true strength of the Flare platform. To our best knowledge, no one is scanning these files inside the containers, thus you can find inside them gold nuggets such as malware, secrets, etc.
Optimizing the results, by marking Docker Hub as the source
3. Lastly, we scan all the results. We extracted all the findings to csv loaded into a Jupyter notebook, and ran a couple of algorithms to find clusters.
One of the results we found, and “xmrig” was hidden inside the container image (Flare link to post, sign up for the free trial to access if you aren’t already a customer)
Why This Matters
This research highlights a persistent and often underestimated risk in the container ecosystem: trust without verification. Public container registries are increasingly treated as safe defaults, yet they remain largely uncurated and vulnerable to abuse.
Malicious container images don’t need zero-day exploits to succeed. They rely on:
- Implicit trust
- Automation
- Scale
- And a lack of systematic image vetting
As organizations continue to shift toward cloud-native and container-first architectures, registry hygiene, image provenance, and runtime detection become critical controls, not optional best practices.
Find Malicious Container Images with Flare
The malicious container images we found are located here.
The Flare Threat Exposure Management solution empowers organizations to proactively detect, prioritize, and mitigate the types of exposures commonly exploited by threat actors. Our platform automatically scans the clear & dark web and prominent threat actor communities 24/7 to discover unknown events, prioritize risks, and deliver actionable intelligence you can use instantly to improve security.
Flare integrates into your security program in 30 minutes and often replaces several SaaS and open source tools. See what external threats are exposed for your organization by signing up for our free trial.
