Escaping Containers to Host

Legal Notice: This skill is for authorized security testing and educational purposes only. Container breakout grants full host compromise. Only run these techniques against systems you own or have explicit written authorization to test. Unauthorized use is illegal and may violate computer fraud laws.

Overview

Container escape (MITRE ATT&CK T1611, Escape to Host) is the act of breaking the isolation boundary between a container and the host operating system, giving an attacker code execution in the host namespace — and, on Kubernetes, frequently a route to the entire node and then the cluster. Containers share the host kernel and rely on namespaces, cgroups, capabilities, seccomp, and LSMs (AppArmor/SELinux) for isolation. When any of these controls are weakened (a --privileged container, a mounted Docker socket, a hostPath mount of /, excess Linux capabilities such as CAP_SYS_ADMIN) or when a runtime contains a vulnerability, that boundary collapses.

This skill covers the four highest-impact, real-world escape primitives observed by Sysdig, Unit 42, and the runC maintainers:

1. Misconfiguration escapes — privileged containers, CAP_SYS_ADMIN, host PID/IPC/Network namespaces, and hostPath mounts.
2. Exposed Docker socket (/var/run/docker.sock) — mounting the daemon socket into a container hands an attacker root on the host via a new privileged container.
3. The "Leaky Vessels" runC fd leak, CVE-2024-21626 — runC leaks an internal file descriptor (/proc/self/fd/7/8) referencing the host filesystem before pivot_root; setting the container working directory to that fd lands the process on the host. Patched in runC 1.1.12 (containerd 1.6.28/1.7.13, Docker 25.0.2).
4. The November 2025 runC procfs write-redirect family — CVE-2025-31133, CVE-2025-52565, CVE-2025-52881 — race/symlink abuse of the /dev/null, /dev/console, and other bind mounts performed before runC applies maskedPaths/readonlyPaths, allowing read-write access to /proc entries (e.g. /proc/sysrq-trigger, core_pattern) and arbitrary write redirection. Patched in runC 1.2.8, 1.3.3, and 1.4.0-rc.3.

Sources: Palo Alto Networks "Leaky Vessels" advisory; Sysdig "New runc vulnerabilities allow container escape" (2025); opencontainers/runc security advisories GHSA-cgrx-mc8f-2prm and GHSA-9493-h29p-rfm2; Unit 42 container-escape research.

When to Use

• During an authorized container or Kubernetes penetration test after obtaining initial code execution inside a container or pod
• When validating that runtime defenses (Falco, seccomp, AppArmor) detect or block breakout attempts
• When assessing the blast radius of a compromised microservice
• When verifying patch levels of runC/containerd/Docker against the CVEs above

Prerequisites

• Authorization (signed rules of engagement) covering host/node compromise
• A foothold: a shell inside a target container
• Reconnaissance utilities inside the container or staged in:

  # deepce - Docker enumeration and escape
  git clone https://github.com/stealthcopter/deepce.git
  # amicontained - container introspection (capabilities, seccomp, namespaces)
  curl -L https://github.com/genuinetools/amicontained/releases/download/v0.4.9/amicontained-linux-amd64 -o amicontained
  chmod +x amicontained
  # CDK - zero-dependency K8s/container pentest toolkit
  curl -L https://github.com/cdk-team/CDK/releases/latest/download/cdk_linux_amd64 -o cdk
  chmod +x cdk
  

• A lab cluster/host you are permitted to break out of (e.g., kind, minikube, or a dedicated VM)

Objectives

• Enumerate the container's privilege posture (capabilities, namespaces, mounts, seccomp)
• Identify which escape primitive is available
• Execute a host breakout and prove host-level code execution
• Capture evidence (host hostname, host /etc/shadow access, or a host file write)
• Document the root-cause misconfiguration or vulnerable runtime version for remediation

MITRE ATT&CK Mapping

Workflow

Step 1: Enumerate the Container Environment

Determine privilege level, capabilities, namespaces, and mounted host paths.

…