cloud-container-escapelisted

# 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. 2. **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. 3. **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. ## Veri