**Key Takeaways **

• Pulling container images from public registries is a trust decision, not a neutral operational step. The impact extends to infrastructure stability, cloud spend, and security risk.

• Cryptomining is the most common form of malicious abuse in public container images, driven by the ease of distribution and low visibility inside container layers.

• Simple indicators such as non-pronounceable names, low pull counts, and unexpected binaries often distinguish malicious images from trusted ones.

• Typo squatting remains an effective technique that exploits familiarity with popular base images and application stacks.

• Effective container security requires controls across the full lifecycle, from image ingestion and validation to continuous runtime monitoring.

• Organizations that embed trust checks early preserve development speed while reducing exposure at scale.

The Risk Introduced by Implicit Trust in Public Container Images

Public container registries have become foundational to modern software development. A single docker pull can accelerate application delivery, standardize environments, and reduce operational friction across teams. However, that same convenience has quietly shifted trust decisions earlier in the development lifecycle, often without sufficient scrutiny of what is actually being deployed.

Container ecosystems like DockerHub as well as public cloud registries such as Amazon ECR, Google Artifact Registry, and Azure ACR have transformed how applications are built, shared, and deployed across modern cloud-native environments. Docker Hub, the largest public container registry, allows the Docker community to store, share, and distribute container images that bundle application code, runtime, libraries, and configuration into a single deployable unit.

This openness enables speed and scale, but it also creates an attractive distribution channel for malicious actors seeking to hide harmful payloads inside seemingly legitimate images.

Discovering and Analyzing Malicious Container Images

Identifying malicious container images in public registries requires more than surface-level inspection. While most images appear benign at first glance, closer analysis often reveals patterns that distinguish trusted images from those designed to deceive or abuse runtime resources.

When investigating malicious container images, several indicators can help identify potential threats:

• Suspicious and non-pronounceable repository names

Attackers often use names that closely resemble legitimate software or popular images, or deliberately choose completely non-pronounceable names (random-looking strings) to evade detection and mislead users into pulling malicious containers.

• Low pull count

Legitimate images typically accumulate thousands or millions of pulls over time, reflecting widespread adoption and community trust. In contrast, malicious images often have very low pull counts, indicating they are not widely trusted or used.

• Image layers with malicious content

Inspecting image layers can expose execution artifacts, such as embedded cryptomining binaries, obfuscated scripts, or tools for persistence and lateral movement. These indicators frequently point to intentional misuse rather than misconfiguration.

Our analysis of more than 34,000 container images revealed consistent indicators of risk. Approximately 8% had non-pronounceable names, while nearly 60% had pull counts below 1,000. Additionally, roughly 4% showed direct links to cryptomining activities. Together, these patterns highlight why blind trust in public container images introduces measurable operational and financial risk.

Verification before pulling, combined with the use of trusted publishers and image scanning, is essential to reducing exposure in containerized environments.

Key Threat Categories of Malicious Container Images

Malicious container images observed in public registries generally fall into a small number of recurring threat categories. While the techniques vary, the underlying objective remains consistent: exploit the implicit trust placed in container images to gain compute access, persistence, or opportunities for data exfiltration.

One of the most prevalent forms of abuse in public container registries is the rise of cryptomining malware hidden within public container images. In our recent analysis of more than 2,500 confirmed malicious images hosted on Docker Hub, 70% were identified as cryptomining images. The remaining images were distributed across categories such as trojans, backdoors, exploits, ransomware, keyloggers, and proxy infrastructure.

Chart 1 illustrates the distribution of malicious container images by threat category

Cryptomining in Containers

Cryptomining is the computational process used to validate blockchain transactions, requiring significant CPU/GPU resources. Rather than investing in expensive, dedicated servers, attackers hide mining scripts and binaries directly within container images and rely on unsuspecting users to pull and run them to steal computing power for mining, effectively externalizing compute costs. Victims typically become aware only when Server performance suddenly drops, or Cloud bills skyrocket due to increased cloud resource consumption.

**Why are the containers an effective delivery vehicle for cryptominers? **

• Easy Distribution via public Docker registries – Uploading an image requires minimal effort, and downloads often appear legitimate within standard workflows.

• **Plug-and-Play Execution – **Containers require no environment setup. A malicious image usually contains all required dependencies and can run instantly without additional setup.

• **Scalability Across Environments – **Infected images can spread fast through developers, CI/CD pipelines, and Kubernetes clusters.

• **Low Detection **– Security tools frequently prioritize hosts and workloads, leaving container internals less scrutinized. Malicious software inside a container can easily go unnoticed.

More than 85% of the identified cryptomining images on Docker Hub were configured to mine Monero (XMR) using tools like XMRig, which leverage its CPU-friendly RandomX algorithm. A smaller subset targeted other RandomX-based or compute-efficient cryptocurrencies such as Zcash, Ethereum, Bytecoin, Twitch, IronFish, Base, Alephium, Flux, and related variants.

Chart 2 highlights the distribution of cryptocurrencies observed across cryptomining container images

Typo Squatting in Cryptomining Container Images

Typo squatting remains a common and effective technique used by attackers distributing cryptomining container images through public registries. By exploiting familiar software names and minor spelling variations, attackers increase the likelihood that malicious images are mistaken for legitimate ones during routine pulls.

We observed that cryptomining attackers frequently abused legitimate software names when publishing cryptocurrency miner images, which may trick users into downloading the miner images on the host.

These images are often designed to visually resemble well-known base images or popular application stacks, relying on subtle differences that are easy to miss in fast-moving development workflows.

kkbb46xuq6s/nginx:l w1695426/docker001:latest n0bility6/ubuntu-haven:latest eylnhyk904ar/centos:v72 arrghgluiistk/drupal:latest eiprtvchdcom/drupal:latest pumevnezdiroorg/drupal:latest ganodndentcom/drupal:latest dogigeronracom/drupal:latest vesnpsexga/joomla:latest yujikimura/liferay-poc:latest

Inspection of the layers from one of the above images, kkbb46xuq6s/nginx, provides clear evidence of embedded cryptomining activity and illustrates how naming deception is paired with malicious payloads.

Figure 1 shows a layered inspection of a cryptomining container image, revealing embedded miner binaries and execution artifacts

MITRE Tactics and Techniques in Container Image Abuse

Mapping observed container image abuse to the MITRE ATT&CK framework helps contextualize attacker behavior and clarify the intent behind specific techniques observed in malicious container images.

T1036 – Masquerading

• This technique involves using names that appear legitimate by closely resembling official vendor names, commonly used software names, or popular image names to deceive users into pulling malicious container images under the guise of trust.

T1496 – Resource Hijacking

• The objective of resource hijacking is to covertly consume CPU or GPU resources for cryptomining by executing malicious workloads within compromised container environments.

Together, these techniques illustrate how naming deception and resource abuse are combined to exploit implicit trust in public container registries while minimizing the likelihood of early detection.

Operationalizing Trust Across the Container Lifecycle

Pulling container images from public registries introduces multiple risk factors, including exploitable vulnerabilities, embedded malware, and exposed secrets. Addressing these risks requires controls that span the full container lifecycle, from image ingestion to runtime execution.

Qualys TotalCloud™ helps secure containers as a continuous risk surface through:

• Container Registry Scanning Automatically scans container registries to identify vulnerabilities, zero-day malware, and secrets in packages and applications before deployment. Perform continuous assessment against in-use and mission-critical images as needed.

• **Identify Zero-Day Malware In Your Supply Chain: **Qualys leverages deep learning to help you identify malicious binaries and malware that cannot be identified through typical static/YARA scanners. Detect known and unknown variants of malware at a high detection rate across a wide variety of payload types (ELF, PE, DOC, XLS, PPT, PDF, DMG, ZIP, etc.)

• **Enforce From Build To Runtime: **Enforce key measures to prevent the build and deployment of images containing critical vulnerabilities, malware, secrets, or unauthorized software.

• **Only Allow Trusted Deployments with Qualys Admission Controller: **Enforce Image Pulls From trusted deployments. With Admission Controllers deployed on any Kubernetes cluster (EKS, GKE, Red Hat OpenShift, AKS, and more), you can enforce baseline SLAs – not scanned by Qualys registry scan, cannot run in production.

• **Remediate **Toxic Attack Paths Stemming From Images and Containers: Visualize and remediate attack paths that combine container exposure with exploitable vulnerabilities, secrets, excessive identity permissions, and/or zero-day malware.

• Secrets Exposure Identification Flags exposed secrets, keys, and passwords within an image, preventing credential leaks. Configure custom secret detectors as needed.

• **Real-time threat detection with Container Runtime Security ** Continuously monitors running containers to detect threats and suspicious activity at runtime using eBPF Sensors.

When integrated from build to runtime, these controls help ensure that only verified, security-reviewed container images progress to production, reducing operational risk and improving overall container governance.

Important Safety Measures

Follow these essential practices to reduce exposure when using container images from public registries and to maintain consistent security standards across development and production environments.

• Use Trusted Sources Only – Pull images from verified publishers or official repositories whenever possible.

• Scan Images Before Deployment – Use vulnerability and malware scanners to detect cryptomining binaries, malicious scripts, and exploitable packages before images reach production.

• Monitor for Typo squatting – Review image names carefully for subtle spelling errors or variations that mimic legitimate software or popular base images.

• Apply Least Privilege Principles – Run containers with minimal permissions and avoid privileged mode unless explicitly required.

• Regularly Audit Container Images – Maintain an inventory of approved images and periodically review them for anomalies or unexpected changes.

• Monitor Runtime Behavior – Watch for unusual CPU usage, unexpected outbound network connections to mining pools, or unexpected processes running inside containers.

Conclusion

Pulling container images from public registries is no longer a neutral operational step. It is a trust decision that directly affects infrastructure stability, cloud costs, and security risk.

As container ecosystems continue to scale, attackers will continue to exploit openness and automation to distribute malicious images at speed. Organizations that treat image validation, scanning, and runtime monitoring as standard workflow controls, rather than optional safeguards, are better positioned to reduce exposure without slowing development.

Building trust in the container lifecycle ensures that speed and scale do not come at the expense of control.

---

Close the trust gap in public container registries with Qualys TotalCloud™

---

Frequently Asked Questions (FAQs)

What are the security risks of pulling container images from public registries?

Pulling container images from public registries can introduce malware, cryptomining binaries, vulnerable packages, and exposed secrets into cloud and Kubernetes environments, often through automated CI/CD pipelines.

Why are public container images used for cryptomining attacks?

Public container images are abused for cryptomining because containers run immediately with bundled dependencies, allowing attackers to hijack CPU and GPU resources at scale

How do attackers hide malicious code inside container images?

Attackers embed cryptomining binaries, obfuscated scripts, or persistence tools inside container image layers, making them difficult to detect without image scanning.

What is typo squatting in container registries?

Typo squatting occurs when attackers publish container images with names that closely resemble legitimate software or popular base images, increasing the chance of accidental pulls.

How can malicious container images be detected before deployment?

Malicious container images can be detected before deployment by scanning for malware, vulnerabilities, exposed secrets, and suspicious binaries, and by verifying the identity of image publishers.

Why is container runtime security still necessary after image scanning?

Container runtime security is needed because image scanning only evaluates risk before deployment, while runtime monitoring detects malicious behavior after containers start running.