How to use the Container Escape Playbook agent skill

What the skill makes the agent do

The skill is an offensive playbook. Its stated objective is to take a shell that is already inside a container and reach the host operating system. It is organized as a workflow: confirm the container, enumerate capabilities, mounts, namespaces and sockets, identify the most likely escape vector, execute the matching technique, validate host access, and then pivot to other systems.

The source file covers these vector families: privileged container breakout through host filesystem mounts and nsenter, Docker socket abuse through /var/run/docker.sock, dangerous Linux capabilities such as CAP_SYS_ADMIN, CAP_SYS_PTRACE and CAP_NET_ADMIN, the cgroup v1 notify_on_release escape, runc CVEs including CVE-2019-5736 and CVE-2024-21626 (Leaky Vessels), kernel exploits from inside containers, and Dockerfile misconfigurations such as --privileged and host namespace sharing. It maps these techniques to MITRE ATT&CK T1611 Escape to Host.

How to install the skill

Download the skill ZIP from the directory page. Unzip it into your user skills folder, ~/.claude/skills/, so that the agent can use it in every project. To scope it to one project instead, unzip it into that project's .claude/skills/ folder.

If you use the Claude apps rather than a local setup, you can upload the skill in the app under Settings, then Capabilities, then Skills.

• Personal install: ~/.claude/skills/ (available across projects)
• Project install: .claude/skills/ inside the project folder
• Claude apps: Settings → Capabilities → Skills, then upload

How to trigger the skill with natural requests

You do not run the skill like a program. The agent decides to load it when your request matches the skill's description. The description says it applies when the engagement scope includes container breakout, Docker escape, container privilege escalation, host access from a container, or when you land inside a containerized environment and need to reach the host. Say those things plainly, and state your authorization and scope in the same message.

Vague requests such as 'help with my server' are unlikely to load it. Requests that name the goal and the setting work better.

• Our scope is a written container pentest. I have a shell in this container and need to check whether I can reach the host.
• This engagement includes Docker escape testing. Enumerate what this container can do before choosing a technique.
• I am validating that our container isolation holds. Check for privileged mode and an exposed Docker socket.

What the agent checks first

Most of the file is enumeration before any exploit. The agent is directed to confirm it is containerized, then map capabilities, mounts, namespaces and sockets. The commands in the file include checking /.dockerenv, reading /proc/1/cgroup for runtime identifiers, inspecting PID 1, reading CapEff from /proc/1/status and decoding it with capsh, and comparing namespace inodes to see whether host namespaces are shared.

The file names several enumeration tools: deepce, CDK (its evaluate command), amicontained, capsh and nsenter. Some of these are downloaded at runtime rather than bundled, which matters for the requirements below.

• Container check: /.dockerenv, /proc/1/cgroup, PID 1 command line, environment variables, hostname
• Capabilities: capsh --print, CapEff decoded with capsh --decode
• Namespaces and mounts: /proc/1/ns, /proc/1/mountinfo, findmnt, ip addr show

Escape vectors the file describes

Once enumeration points to a weakness, the file describes a technique for it. For a privileged container, the file covers listing block devices, mounting the host root filesystem into the container and reading host files, and using nsenter into host namespaces when host PID 1 is visible. It also covers direct device access. For an exposed Docker socket, the file shows how to check that the socket is writable and query the Docker API, then how to create and start a privileged container that binds the host root.

The file describes persistence on the host as well, including adding keys and accounts and scheduling jobs. This guide does not reproduce those steps. Treat them as part of what the skill contains, not as something to run without written authorization.

• Privileged mode: host disk mount, nsenter, device access
• Docker socket: check writability, query the API, create and start a container with the host root bound
• Capabilities, cgroup, runc CVE and kernel paths: described in the file

Safety notes: scripts and network

The skill runs scripts and uses the network. The file refers to downloading deepce from GitHub when outbound access is available, and to tools such as CDK being obtained at runtime. Before the agent fetches anything, confirm that your engagement permits outbound traffic from the target and that you are comfortable with the tools being pulled in.

The file's own guidance includes writing to host files and running exploit tooling. On a production system those actions can cause outages or data loss. Use a lab or an agreed test environment, and keep written scope in front of you before any write, mount or exploit step.

• Requires a Linux shell inside the target container
• Tools downloaded at runtime: deepce, CDK and others named in the file
• Needs python3 and curl for socket checks
• Needs network access to GitHub if the agent downloads deepce
• Not for production systems without explicit approval

Tips for getting useful results

Start with enumeration only and read the output before allowing any exploit step. The skill's workflow already orders the work this way, so ask the agent to stop after step 3 if you want a report first. Keep a record of each command the agent runs, because the file's techniques change host files and that record is your audit trail.

The source file is a SKILL.md and is written as an attack reference, not a hardening guide. If your goal is to defend a container, use the enumeration sections as a checklist to audit your own configuration rather than as an escape plan.

• Ask for enumeration first and a findings summary before any write or mount
• Log every command for the engagement report
• Use the skill to check your own isolation, for example whether --privileged or a mounted docker.sock is present