容器管理命令指攻击者通过容器编排系统的管理接口（如Docker daemon、Kubernetes API）在容器内执行恶意指令的技术手段。该技术通常利用合法管理工具（kubectl exec、docker exec）或篡改容器配置实现代码执行，为后续横向移动、持久化等攻击阶段建立据点。防御措施主要依赖容器运行时的进程监控、API调用审计日志分析，以及镜像完整性校验机制。
为规避容器安全解决方案的检测，攻击者发展出深度结合云原生特性的隐蔽式命令执行技术，通过寄生在容器生命周期管理流程、滥用供应链信任机制、伪造控制平面通信等手段，将恶意操作融入正常的云原生运维模式。
当前容器管理命令匿迹技术的核心在于攻击载体与云原生组件的深度耦合。攻击者通过三个维度重构攻击链：首先，时间维度上选择容器创建、更新等关键生命周期节点实施寄生，利用系统对初始化操作的宽容性规避运行时检测；其次，空间维度上借助镜像层级结构、内存文件系统等容器特有机制隐藏攻击痕迹，突破传统主机安全防护的检测边界；最后，协议维度上精确模仿控制平面通信规范，使恶意请求在加密通道和API审计层面均表现为合法操作。四项子技术的共性在于突破命令执行与运维操作的二元对立，通过将攻击要素分解重构为符合云原生技术范式的原子操作，实现恶意行为在容器生态中的"合法化生存"。
匿迹技术的演进使得传统基于日志规则匹配或镜像漏洞扫描的防御体系面临失效风险，防御方需构建覆盖镜像供应链、控制平面通信、运行时行为的全链路监控体系，并引入容器行为基线分析、加密流量元数据检测等新型技术，实现对隐蔽命令执行的多维度感知。
| 效应类型 | 是否存在 |
|---|---|
| 特征伪装 | ✅ |
| 行为透明 | ✅ |
| 数据遮蔽 | ✅ |
| 时空释痕 | ❌ |
攻击者通过精确模仿容器管理协议（如Kubernetes gRPC调用格式）和运维操作模式（如镜像更新流程），将恶意命令执行请求伪装成合法的集群管理行为。例如构造符合OpenAPI规范的API请求，使恶意负载在协议特征层面与正常控制平面流量完全一致，规避网络层异常检测。
利用容器编排系统对自动化操作的内置支持，攻击者通过API凭证滥用和RBAC权限逃逸，使恶意命令执行过程在审计日志中表现为授权用户的标准运维行为。这种权限层与行为层的双重伪装，导致防御方难以通过常规审计手段发现异常。
在服务端API伪装通信中，攻击者利用控制平面组件间的mTLS加密通道传输恶意指令，使得网络流量内容无法被深度包检测工具解析。同时，通过将控制指令编码为Base64加密的环境变量或ConfigMap条目，实现攻击载荷在存储层和传输层的双重加密遮蔽。
| ID | Name | Description |
|---|---|---|
| S0601 | Hildegard |
Hildegard was executed through the kubelet API run command and by executing commands on running containers.[1] |
| S0599 | Kinsing |
Kinsing was executed with an Ubuntu container entry point that runs shell scripts.[2] |
| S0683 | Peirates |
Peirates can use |
| S0623 | Siloscape |
Siloscape can send kubectl commands to victim clusters through an IRC channel and can run kubectl locally to spread once within a victim cluster.[4] |
| G0139 | TeamTNT |
TeamTNT executed Hildegard through the kubelet API run command and by executing commands on running containers.[1] |
| ID | Mitigation | Description |
|---|---|---|
| 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 execution of commands.[5] 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.[6] |
| M1035 | Limit Access to Resource Over Network |
Limit communications with the container service to managed and secured channels, such as local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API and Kubernetes API Server.[7][8] In Kubernetes clusters deployed in cloud environments, use native cloud platform features to restrict the IP ranges that are permitted to access to API server.[9] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[10] |
| M1026 | Privileged Account Management |
Ensure containers are not running as root by default. In Kubernetes environments, consider defining Pod Security Standards that prevent pods from running privileged containers and using the |
| M1018 | User Account Management |
Enforce authentication and role-based access control on the container service to restrict users to the least privileges required.[5] When using Kubernetes, avoid giving users wildcard permissions or adding users to the |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0017 | Command | Command Execution |
Monitor command execution within containers to detect suspicious activity. Commands executed via Docker ( Analytic 1 - Unusual command executions in container services
|
| DS0009 | Process | Process Creation |
Track the creation of new processes within a container environment, which could indicate suspicious activity initiated via the Docker daemon or Kubernetes API server. Analytic 1 - Unusual process creation within containers
|