Containers on fire: from container escapes to supply chain attacks
This report details primary attack vectors against containerized environments, focusing on container escapes, orchestration API abuse, and supply chain compromises. Threat actors exploit misconfigurations such as excessive Linux capabilities and exposed Docker sockets to break out of containers, while also targeting CI/CD pipelines and public image repositories to establish initial footholds.
Authors:
Detection / HunterGoogle
What Happened
Cyber attackers are increasingly targeting container technologies like Docker and Kubernetes to compromise corporate networks. They do this by exploiting weak settings, stealing passwords stored inside containers, or sneaking malicious code into the software supply chain before the application even runs. If successful, attackers can break out of the isolated container to take full control of the underlying server. Organizations should review their container configurations, restrict unnecessary permissions, and secure their software building processes to prevent these attacks.
Key Takeaways
- Container escapes frequently leverage misconfigurations like the --privileged flag and excessive Linux capabilities (e.g., CAP_SYS_ADMIN, CAP_SYS_MODULE).
- Exposed or misconfigured orchestration APIs (Docker socket, Kubernetes API) allow attackers to deploy privileged containers and take over host nodes.
- Supply chain attacks are rising, targeting CI/CD pipelines and public image repositories to inject malicious code before runtime.
- Compromised containers are often used to harvest sensitive data like Kubernetes ServiceAccount tokens, API keys, and environment variables.
Affected Systems
- Docker
- Kubernetes
- Linux container runtimes (runC)
- CI/CD pipelines
Vulnerabilities (CVEs)
- CVE-2019-5736
- CVE-2022-0492
- CVE-2024-21626
Attack Chain
Attackers typically gain initial access via supply chain compromise, poisoned images, or exploiting vulnerable applications running in containers. Once inside, they harvest secrets like ServiceAccount tokens or exploit misconfigurations (e.g., CAP_SYS_ADMIN, mounted Docker sockets) to escalate privileges. Finally, they execute container escapes using techniques like kernel module injection or API abuse to achieve full host compromise and lateral movement.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article discusses conceptual attack vectors and misconfigurations but does not provide specific detection rules or queries.
Detection Engineering Assessment
EDR Visibility: Medium — EDR solutions on the host can detect suspicious processes spawned from container runtimes (e.g., nsenter, capsh) and kernel module loading, but may lack visibility into API-level orchestration abuse without specific integrations. Network Visibility: Low — Container-to-container traffic and API requests are often encrypted or internal to the cluster, making network-based detection difficult without a dedicated CNI or service mesh monitoring tool. Detection Difficulty: Moderate — Distinguishing legitimate administrative container deployment from malicious API abuse requires well-tuned baseline profiles and RBAC monitoring.
Required Log Sources
- Kubernetes Audit Logs
- Docker Daemon Logs
- Linux Auditd
- CI/CD Pipeline Logs
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
Consider hunting for the execution of nsenter or capsh within containerized environments, which may indicate reconnaissance or container escape attempts. | Process execution logs (Linux Auditd, EDR) | Privilege Escalation | Medium |
Consider hunting for unexpected insmod or modprobe commands originating from container processes, indicating potential CAP_SYS_MODULE abuse. | Process execution logs (Linux Auditd, EDR) | Privilege Escalation | Low |
If you have visibility into Kubernetes audit logs, consider hunting for anomalous create pod requests specifying privileged: true or mounting sensitive host paths like /var/run/docker.sock. | Kubernetes Audit Logs | Execution | Medium |
Consider hunting for processes interacting with the Docker socket (/var/run/docker.sock) using curl or similar tools from within a container. | Process execution logs, File access logs | Execution | Low |
Control Gaps
- Lack of runtime container security monitoring
- Overly permissive Pod Security Policies / Pod Security Admissions
- Unrestricted egress network policies for containers
Key Behavioral Indicators
- Container processes running as root with excessive capabilities (e.g., CAP_SYS_ADMIN)
- Mounting of host root filesystem (/) or Docker socket into containers
- Unexpected modifications to host files (e.g., ~/.bashrc) from containerized processes
False Positive Assessment
- Medium
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting.
- Evaluate whether any currently running containers use the
--privilegedflag or mount the Docker socket, and restrict them if not strictly necessary. - Consider auditing Kubernetes RBAC permissions to identify and restrict overly permissive ServiceAccounts.
Infrastructure Hardening
- Consider implementing Pod Security Admission controllers to enforce baseline or restricted security standards across Kubernetes clusters.
- Evaluate dropping unnecessary Linux capabilities (e.g., CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_NET_ADMIN) from container deployments.
- If applicable, ensure the Docker API and Kubernetes API servers are not exposed to untrusted networks and require strong authentication.
User Protection
- Consider enforcing the use of read-only root filesystems for containers where supported by your applications.
- Evaluate implementing strict secrets management solutions (e.g., HashiCorp Vault, AWS Secrets Manager) instead of passing secrets via environment variables.
Security Awareness
- Consider training development and DevOps teams on the risks of using untrusted public container images and the importance of image scanning.
- Evaluate incorporating container security best practices into existing secure SDLC and CI/CD pipeline training.
MITRE ATT&CK Mapping
- T1611 - Escape to Host
- T1610 - Deploy Container
- T1609 - Container Administration Command
- T1525 - Implant Internal Image
- T1068 - Exploitation for Privilege Escalation
Additional IOCs
- Command Lines:
- Purpose: Attempting container escape by executing a shell in the host's namespace | Tools:
nsenter| Stage: Privilege Escalation |nsenter --target 1 --mount --uts --ipc - Purpose: Interacting with a mounted Docker socket to create a privileged container | Tools:
curl,docker| Stage: Execution |curl --unix-socket /var/run/docker.sock -X POST - Purpose: Deploying a malicious pod via the Kubernetes API using a compromised token | Tools:
curl,kubernetes| Stage: Execution |curl -k -X POST https://<kubernetes-url>/api/v1/namespaces/default/pods - Purpose: Loading a malicious kernel module to execute code in kernel space | Tools:
insmod| Stage: Privilege Escalation |insmod shell.ko
- Purpose: Attempting container escape by executing a shell in the host's namespace | Tools: