Attackers Exploit Docker and Kubernetes Misconfigurations to Breach Hosts and Clusters

Overview

As organisations continue migrating applications and services into containerised environments, attackers are increasingly turning their attention to Docker and Kubernetes infrastructure.

Recent research highlights a growing number of attacks targeting container platforms through a combination of software supply chain compromises, exposed management interfaces, excessive privileges, and configuration weaknesses. Rather than relying solely on software vulnerabilities, threat actors are increasingly abusing misconfigurations and trusted tooling to gain access to cloud-native environments.

Of particular concern is reporting linking the TeamPCP threat group to the compromise of a Docker Hub repository associated with Checkmarx KICS, a widely used infrastructure-as-code security scanning tool. Researchers claim attackers embedded credential-stealing malware into a trusted container image, allowing them to harvest Kubernetes secrets, API tokens, and cloud credentials during routine security scanning activities.

The findings serve as a reminder that container environments are now a primary target for attackers seeking access to applications, cloud resources, and enterprise infrastructure.

What Happened?

Researchers identified several attack paths being actively exploited across containerised environments, with many of them relying on configuration weaknesses rather than sophisticated exploits.

The most notable example involved a malicious container image hosted within a trusted software supply chain. Organisations using the compromised image as part of their development or security scanning workflows may have unknowingly exposed sensitive credentials and Kubernetes secrets to attackers.

At the same time, threat actors continue to exploit exposed Docker and Kubernetes management interfaces, over-privileged containers, and container runtime vulnerabilities to move from an initially compromised workload to full host or cluster compromise.

The common theme across these attacks is that compromising a single container can often provide a pathway to much broader access if security controls and permissions are not properly configured.

How the Attack Works

Container attacks rarely stop at the initial point of compromise. Instead, attackers typically use a multi-stage approach designed to expand access and extract valuable credentials.

A typical attack may begin with a compromised container image, exposed API, or vulnerable workload. From there, attackers often focus on harvesting credentials stored within the container, including cloud API keys, Kubernetes secrets, service account tokens, and CI/CD credentials.

Once sufficient access has been obtained, they may move laterally through the environment, abuse Kubernetes permissions, deploy additional workloads, or attempt to compromise the underlying host system.

In many cases, attackers do not even need to “escape” the container if valuable credentials and cloud identities are already available within the workload itself.

Why This Matters

Container environments have become a high-value target because they often sit at the centre of modern cloud infrastructure.

Unlike traditional servers, containers frequently have direct access to:

Cloud platforms
Application secrets
CI/CD pipelines
Kubernetes clusters
Production workloads

As a result, a seemingly minor compromise can quickly escalate into a much larger incident affecting multiple systems and services.

The TeamPCP supply chain activity is particularly concerning because it demonstrates how trusted security tooling can be weaponised to gain access to enterprise environments. Organisations typically place significant trust in security scanning tools, making them attractive targets for attackers seeking widespread access.

The Risks of Privileged Containers

One of the most common issues highlighted in the research is the continued use of overly privileged containers.

While container isolation is designed to limit the impact of a compromise, those protections can be significantly weakened when excessive permissions are granted.

Containers running with privileged access or powerful Linux capabilities may allow attackers to:

Access the host operating system
Modify system files
Extract credentials
Inject code into other processes
Establish persistence

In many environments, misconfigurations are a common cause of container escapes because they are generally more prevalent than sophisticated vulnerability exploits or something to that effect.

This reinforces a key lesson for security teams: attackers often take the easiest route available, and configuration weaknesses frequently provide a simpler path to compromise than exploiting complex software flaws.

Why Docker and Kubernetes APIs Remain Attractive Targets

Management interfaces continue to be a common entry point for attackers targeting container environments.

If an attacker obtains access to Docker or Kubernetes API credentials, they may be able to enumerate resources, deploy new workloads, access sensitive data, or create privileged containers that provide broader access across the environment.

Because many of these activities resemble legitimate administrative behaviour, detecting malicious activity can be challenging without detailed visibility into authentication and authorisation events.

This is particularly true in large environments where administrators regularly create, modify, and manage workloads through these same interfaces.

Docker Socket Exposure: A Critical Risk

One of the most significant risks identified in the research is the continued exposure of the Docker socket:

/var/run/docker.sock

Mounting the Docker socket inside a container effectively grants that container access to the Docker daemon itself.

If an attacker compromises a workload with Docker socket access, they may be able to create new containers, access other workloads, interact with the host filesystem, and ultimately take full control of the underlying host.

This remains one of the most common paths observed in real-world cloud-native attack chains.

Detection & Monitoring Recommendations

Defenders should focus on behavioural monitoring and visibility across both container workloads and orchestration platforms.

Security teams should be alert to:

Unexpected privileged container deployments
Host filesystem mounts
Kubernetes secret enumeration activity
Unusual API token usage
Docker socket access
Signs of container breakout attempts
Unexpected outbound communications from CI/CD systems

Monitoring Kubernetes audit logs, runtime activity, and API access events can provide valuable visibility into attacker behaviour that may otherwise appear legitimate.

Organisations should also investigate sudden changes in privilege levels, new administrative workloads, and unexpected access to cloud credentials or secrets.

Recommended Actions

Organisations should begin by reviewing container configurations and identifying workloads running with unnecessary privileges. Linux capability assignments, hostPath mounts, and Docker socket exposure should all be carefully audited and removed where not explicitly required.

Container runtime software should be kept fully up to date, with particular attention paid to known container escape vulnerabilities affecting runC and Linux cgroups.

Access to Docker and Kubernetes APIs should be tightly controlled through strong authentication and least-privilege role-based access control (RBAC) policies. Service account credentials should be regularly rotated and monitored for misuse.

From a supply chain perspective, organisations should implement image signing, image verification, and approved image repositories wherever possible. Security teams should also continuously scan container images for malicious content and unauthorised modifications before deployment.

Analyst Assessment

This reporting reinforces a growing reality for organisations operating cloud-native environments: attackers no longer need sophisticated zero-day exploits to achieve significant impact.

The combination of supply chain compromise, excessive permissions, exposed management interfaces, and poor secrets management continues to provide multiple pathways into containerised infrastructure.

The reported TeamPCP activity demonstrates how trusted security tools themselves can become an attack vector, while the continued abuse of privileged containers and exposed APIs highlights the importance of strong configuration management and access controls.

For organisations running Kubernetes or Docker workloads, visibility into runtime behaviour, API activity, credential usage, and container image integrity should now be considered essential security requirements rather than optional security enhancements.

How NormCyber MDR Helps Secure Cloud-Native Environments

Modern attacks against Docker and Kubernetes environments often leave behind few traditional malware indicators, making continuous monitoring and behavioural analysis essential. NormCyber’s Managed Detection and Response (MDR) service provides organisations with 24/7 visibility across cloud, endpoint, identity, and infrastructure telemetry, helping security teams detect suspicious activity before it escalates into a wider compromise.

Our SOC analysts monitor for indicators such as unusual Kubernetes API activity, privilege escalation attempts, abnormal container behaviour, credential misuse, suspicious cloud access patterns, and potential supply chain compromise. By correlating signals across cloud platforms, identities, workloads, and endpoints, NormCyber MDR helps organisations identify threats that may otherwise remain hidden within complex containerised environments.

As attackers increasingly target cloud-native infrastructure, trusted software supply chains, and privileged workloads, proactive monitoring and rapid response capabilities are critical to reducing the risk of host compromise, cluster takeover, and cloud-wide impact.