容器逃逸至主机是指攻击者突破容器隔离环境获取宿主机控制权的技术，通常利用配置缺陷、内核漏洞或管理接口滥用等途径实现。传统防御手段侧重于监控特权容器创建、异常系统调用（如mount、unshare）以及可疑的容器镜像部署行为，通过审计日志分析和行为基线对比识别异常操作。缓解措施包括实施最小权限原则、强化容器运行时安全策略、监控集群级配置变更等。
现有逃逸至主机匿迹技术的核心在于攻击路径的合法化重构与执行环境的深度融合。合法工具链滥用逃逸通过模仿运维操作模式，将恶意指令分解为多个合规API调用，利用白名单工具的信誉规避检测；内核级漏洞静默触发逃逸专注于内存层面的无痕利用，通过动态代码生成和即时痕迹清除实现零特征攻击；容器管理接口劫持逃逸则利用加密通信和权限滥用，将逃逸过程伪装成授权管理行为；隐藏式进程注入逃逸通过内存驻留技术和进程克隆手段，实现逃逸行为的运行时隐匿。这些技术的共性在于突破传统隔离机制监控维度，通过权限滥用合法化、漏洞利用无痕化、操作过程碎片化等策略，构建出"形神兼备"的伪装逃逸链。
| 效应类型 | 是否存在 |
|---|---|
| 特征伪装 | ✅ |
| 行为透明 | ✅ |
| 数据遮蔽 | ✅ |
| 时空释痕 | ❌ |
攻击者通过完全复现合法容器管理操作的工作流，将逃逸行为伪装成标准的运维活动。例如使用合规的docker命令参数创建恶意容器，或通过Kubernetes Job资源调度逃逸载荷，使得攻击指令在协议特征、API调用序列等方面与正常操作完全一致，规避基于操作模式的检测。
利用零日内核漏洞实现逃逸时，攻击过程不产生任何可被现有监控系统识别的异常行为特征。通过内存漏洞的精准利用和即时痕迹清除，使得逃逸操作在容器审计日志、系统调用跟踪等维度均表现为正常状态，形成"完美犯罪"式的透明攻击路径。
在管理接口劫持逃逸场景中，攻击者全程使用TLS加密通道传输恶意指令，并通过篡改容器运行时日志组件，对逃逸操作的关键元数据（如敏感API参数、异常错误代码）进行实时过滤或混淆，使得网络流量和日志审计层面均无法获取有效攻击证据。
| ID | Name | Description |
|---|---|---|
| S0600 | Doki |
Doki’s container was configured to bind the host root directory.[1] |
| S0601 | Hildegard |
Hildegard has used the BOtB tool that can break out of containers. [2] |
| S0683 | Peirates |
Peirates can gain a reverse shell on a host node by mounting the Kubernetes hostPath.[3] |
| S0623 | Siloscape |
Siloscape maps the host’s C drive to the container by creating a global symbolic link to the host through the calling of |
| G0139 | TeamTNT |
TeamTNT has deployed privileged containers that mount the filesystem of victim machine.[5][6] |
| ID | Mitigation | Description |
|---|---|---|
| M1048 | Application Isolation and Sandboxing |
Consider utilizing seccomp, seccomp-bpf, or a similar solution that restricts certain system calls such as mount. In Kubernetes environments, consider defining Pod Security Standards that limit container access to host process namespaces, the host network, and the host file system.[7] |
| M1042 | Disable or Remove Feature or Program |
Remove unnecessary tools and software from containers. |
| M1038 | Execution Prevention |
Use read-only containers, read-only file systems, and minimal images when possible to prevent the running of commands.[7] Where possible, also consider using application control and software restriction tools (such as those provided by SELinux) to restrict access to files, processes, and system calls in containers.[8] |
| M1026 | Privileged Account Management |
Ensure containers are not running as root by default and do not use unnecessary privileges or mounted components. In Kubernetes environments, consider defining Pod Security Standards that prevent pods from running privileged containers.[7] |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0032 | Container | Container Creation |
Monitor for the deployment of suspicious or unknown container images and pods in your environment, particularly containers running as root. |
| DS0008 | Kernel | Kernel Module Load |
Monitor for the installation of kernel modules that could be abused to escape containers on a host. |
| DS0009 | Process | OS API Execution |
Monitor for unexpected usage of syscalls such as |
| Process Creation |
Monitor for process activity (such as unexpected processes spawning outside a container and/or on a host) that might indicate an attempt to escape from a privileged container to host. |
||
| DS0034 | Volume | Volume Modification |
Monitor cluster-level (Kubernetes) data and events associated with changing containers' volume configurations. |