noorqureshi/security-skills/cloud-container-escape

Container escape → host

When it applies

You have code execution inside a container and want the underlying host (and from there, other containers / the cluster / cloud creds).

Why it works

Containers are isolation by configuration, not a hard boundary. Privileged mode, extra capabilities, mounted host resources, or an exposed Docker socket give processes inside the container direct control over the host kernel/daemon.

Method

1. Confirm & enumerate: /.dockerenv, /proc/1/cgroup; run amicontained/deepce to list

capabilities, seccomp, and mounts.

1. Exploit the misconfig:

• Docker socket mounted (/var/run/docker.sock): docker -H unix://... run -v /:/host ...

→ mount host FS as root → escape.

• Privileged / CAP_SYS_ADMIN: mount the host disk, or use the classic release_agent

cgroup notify_on_release trick to run a command on the host.

• hostPath / host mounts: write to host filesystem (cron, ssh keys, kubelet config).
• hostPID: access host processes; nsenter into PID 1's namespaces.

1. From the host: grab cloud metadata creds (→ cloud-imds-ssrf), pivot to other

containers/nodes (→ cloud-kubernetes).

Gotchas

• Enumerate capabilities/mounts first — the escape depends entirely on which misconfig exists.
• Kernel-exploit escapes are last-resort and risky on live targets; prefer the config-based paths.
• On bug bounty, a proven mount of the host FS is enough — don't disrupt the node.

Verify success

Command execution or file read/write on the host (outside the container namespace) — e.g. host /etc/shadow, other containers, or the kubelet/cloud creds.

References

deepce/amicontained; "Understanding Docker container escapes" (Trail of Bits); HackTricks.