部署容器技术指攻击者通过创建恶意容器实例实施攻击的行为，通常用于执行恶意负载、绕过环境防御或进行容器逃逸。传统防御手段主要依赖容器镜像扫描、运行时行为监控及集群日志分析，例如检测非常规端口绑定、特权模式启用或异常子进程创建等特征。在Kubernetes环境中，安全团队可通过审计工作负载部署事件、监控Pod安全策略违规日志来识别可疑容器活动。
| 效应类型 | 是否存在 |
|---|---|
| 特征伪装 | ✅ |
| 行为透明 | ✅ |
| 数据遮蔽 | ✅ |
| 时空释痕 | ✅ |
通过镜像元数据伪造、服务标签克隆等手段，使恶意容器在资源配置、网络策略等方面与合法服务保持高度一致。例如伪装成Prometheus Exporter组件，复用其监控端口与API路径，规避基于服务特征的检测规则。
利用零日漏洞进行容器逃逸，或通过内存加载执行恶意代码，使得传统基于文件监控或进程树分析的检测手段失效。攻击过程不触发常规异常指标，呈现"合法权限滥用"特征。
采用TLS加密的容器控制通道，在镜像分层中实施AES加密混淆恶意文件，并通过内存加密技术保护反射加载的恶意载荷，阻断基于流量解密或静态扫描的分析路径。
通过动态容器注入技术实现攻击任务的时空分散化执行，利用云平台自动日志轮转机制消除持久化痕迹。短期容器的瞬时特性使得攻击特征在集群监控的时间序列数据中被自然稀释。
| ID | Name | Description |
|---|---|---|
| S0600 | Doki | |
| S0599 | Kinsing | |
| S0683 | Peirates |
Peirates can deploy a pod that mounts its node’s root file system, then execute a command to create a reverse shell on the node.[3] |
| G0139 | TeamTNT |
TeamTNT has deployed different types of containers into victim environments to facilitate execution.[4][5] TeamTNT has also transferred cryptocurrency mining software to Kubernetes clusters discovered within local IP address ranges.[6] |
| ID | Mitigation | Description |
|---|---|---|
| M1047 | Audit |
Scan images before deployment, and block those that are not in compliance with security policies. In Kubernetes environments, the admission controller can be used to validate images after a container deployment request is authenticated but before the container is deployed.[7] |
| 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, Kubernetes API Server, and container orchestration web applications.[8][9] 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.[10] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[11] |
| M1030 | Network Segmentation |
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls. |
| M1018 | User Account Management |
Enforce the principle of least privilege by limiting container dashboard access to only the necessary users. When using Kubernetes, avoid giving users wildcard permissions or adding users to the |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0015 | Application Log | Application Log Content |
Monitor application logs for any unexpected or suspicious container deployment activities through the management API or service-specific logs (e.g., Docker Daemon logs, Kubernetes event logs). Analytic 1 - Container creation and start activities in Docker and Kubernetes
|
| DS0032 | Container | Container Creation |
Monitor container creation to detect suspicious or unknown images being deployed. Ensure that only authorized images are being used in the environment, especially in sensitive areas. Analytic 1 - Creation of unexpected or unauthorized containers
|
| Container Start |
Monitor for the start of containers, especially those not aligned with expected images or known administrative schedules. Analytic 1 - Unexpected container starts
|
||
| DS0014 | Pod | Pod Creation |
Monitor for newly constructed pods that may deploy a container into an environment to facilitate execution or evade defenses. |
| Pod Modification |
Monitor for changes made to pods for unexpected modifications to settings and/or control data that may deploy a container into an environment to facilitate execution or evade defenses. |