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. (Citation: AppSecco Kubernetes Namespace Breakout 2020)
Containers can be deployed by various means, such as via Docker's <code>create</code> and <code>start</code> APIs or via a web application such as the Kubernetes dashboard or Kubeflow. (Citation: Docker Containers API)(Citation: Kubernetes Dashboard)(Citation: Kubeflow Pipelines) In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DaemonSets, which can allow containers to be deployed across multiple nodes.(Citation: Kubernetes Workload Management) Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime.(Citation: Aqua Build Images on Hosts)
View in MITRE ATT&CK®| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| IAM-16 | Authorization Mechanisms | mitigates | T1610 | Deploy Container |
Comments
This control requires both CSP and CSC to independently enforce formal approval processes for user access, implement dynamic and explicit authorization mechanisms. The guidance focuses on implementing technical measures to verify authorization and prevent unauthorized access and execution.
References
|
| IPY-03 | Secure Interoperability and Portability Management | mitigates | T1610 | Deploy Container |
Comments
This control requires the CSP to encrypt communications using industry-standard protocols, securely manage API certificates and keys, and monitor/patch for vulnerabilities. The guidance for CSC requires it to classify API data, encrypt sensitive information during import/export, use secure protocols, and manage encryption keys independently to mitigate risks of data tampering, loss, or unauthorized access.
References
|
| DSP-15 | Limitation of Production Data Use | mitigates | T1610 | Deploy Container |
Comments
This control describes how the CSP and CSC must independently implement technical safeguards such as network segmentation, encryption (at rest and in transit), secure key management, and access controls to prevent unauthorized replication or use of production data in non-production environments. For this technique, adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container which could contain production data of the environment.
In terms of mitigation, enforcing the principle of least privilege by limiting container dashboard access to only the necessary users. Also, denying direct remote access to internal production systems through the use of network proxies, gateways, and firewalls in order to lessen the ability to use of production data in non-production environments.
References
|
| AIS-06 | Automated Secure Application Deployment | mitigates | T1610 | Deploy Container |
Comments
This control applies to the secure deployments of applications and emphasizes the prevention of misconfigurations and malicious deployment activities. Adversaries may deploy a container into a cloud environment to facilitate execution or evade defenses. The control outlines the use of scanning images before deployment, and block those that are not in compliance with security policies, which can mitigate this technique.
References
|