Adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container to execute processes associated with a particular image or deployment, such as processes that execute or download malware. In others, an adversary may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment. In Kubernetes environments, an adversary may attempt to deploy a privileged or vulnerable container into a specific node in order to Escape to Host and access other containers running on the node. [1]
Containers can be deployed by various means, such as via Docker's create and start APIs or via a web application such as the Kubernetes dashboard or Kubeflow. [2][3][4] In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DaemonSets, which can allow containers to be deployed across multiple nodes.[5] Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime.[6]
| 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.[9] |
| G0139 | TeamTNT |
TeamTNT has deployed different types of containers into victim environments to facilitate execution.[10][11] TeamTNT has also transferred cryptocurrency mining software to Kubernetes clusters discovered within local IP address ranges.[12] |
| 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.[13] |
| 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.[14][15] 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.[16] Where possible, consider enabling just-in-time (JIT) access to the Kubernetes API to place additional restrictions on access.[17] |
| 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. |