Update: Help Shape ATT&CK for Containers
Last December, we sent out a call to the community to help us shape ATT&CK for Containers as part of a Center for Threat-Informed Defense research project. Thanks to contributions and feedback received from the community and Center members, we’ve proposed a first draft of an ATT&CK for Containers matrix! You can click here or scroll to the bottom of this post to read a short description for each technique and sub-technique.
How did we build this matrix?
We started by gathering, analyzing, and organizing open-source intelligence and contributions from the community that dealt with adversary behaviors involving containers. Microsoft’s Threat Matrix for Kubernetes, which the Azure Security Center team built out to map the security landscape of Kubernetes, provided us a great starting point.
Since ATT&CK is focused on in-the-wild adversary behaviors, with Microsoft’s help we first focused on determining which behaviors in their matrix have been carried in-the-wild. We then supplemented that list with other open-source intelligence and contributions from the community. Finally, we went through the current Enterprise ATT&CK matrix for each unique behavior and determined if there’s a current technique or sub-technique that the behavior could fit into with the following guidelines in mind:
- If the behavior fit into a current technique or sub-technique, we plan to add a new platform tag and update the description and other fields to convey how that technique fits into ATT&CK for Containers if we publish this content in ATT&CK.
- If the behavior fit into a current technique but seemed unique enough that a new sub-technique should be generated, we proposed a new sub-technique for that technique.
- If the behavior didn’t fit into a current technique or sub-technique, we proposed new techniques or sub-techniques for ATT&CK.
We also decided that we would combine all orchestration-level (e.g. Kubernetes) and container-level (e.g. Docker) adversary behaviors in a single platform. Similar to the abstraction level of ATT&CK for Cloud, if a behavior happens inside a container but that behavior is what we would generally think of as a host-based technique, we did not include it in Containers. For example, if an adversary installs a cron job within a container, that behavior would be covered by the Linux matrix instead of the Containers matrix.
When are we adding this to ATT&CK?
We have a few questions we’d still like to answer before adding container techniques into ATT&CK. The most critical question we’re trying to answer is whether or not adversary behaviors related to containers ever ultimately lead to objectives other than cryptomining. Throughout our research and conversations we’ve had with contributors, the common theme we’ve heard is that most behaviors ultimately lead to cryptomining activities, even when they involve accessing secrets such as cloud credentials.
We’re curious whether anyone has seen adversaries using containers for more “traditional” purposes such as exfiltration or collection of sensitive data. If we can better understand how adversary behavior in containers ties into the rest of Enterprise ATT&CK, that will provide a stronger case for adding this content in a future ATT&CK release.
How can you help?
We’ve already received some excellent feedback and contributions from the community, and we gladly welcome any additional information! Here are some questions that you can help us answer as we determine how to move forward with this draft matrix:
1. Do we have any gaps in the matrix? Have you seen or heard of in-the-wild adversary behaviors that are currently not represented?
2. Do you have any intel on adversaries using containers for other “traditional” purposes such as for exfiltration or collection?
3. Besides deploying new containers, do you have intel on lateral movement behaviors that would fit into the Containers matrix, such as moving from container-to-container or pod-to-pod?
4. Did we get something wrong? Is there anything inaccurate, or did we name something weirdly?
One thing to keep in mind as you review this draft, is that ATT&CK is focused on behaviors that have been carried out in-the-wild by adversaries. This draft matrix does not represent every possible technique that could theoretically be carried out, but it expresses behaviors that we have either gathered from open-source intelligence or through outside contributions from folks that have visibility into adversary behavior in containers.
Thanks again to everyone in the community that’s contributed to ATT&CK for Containers so far! If you have additional contributions or thoughts, please feel free to send us an email at attack@mitre.org.
Container Technique Descriptions
To complement the draft matrix, we’ve written a short description for each technique and sub-technique. These descriptions are not necessarily what we would include in ATT&CK, but we’re providing them so you can better understand how each technique applies to adversary behavior in containers. If a technique or sub-technique falls under multiple tactics, we only describe it once below.
Initial Access
Exploit Public-Facing Application
Adversaries may exploit vulnerabilities in public-facing applications, including those that are containerized. This may lead to compromise of or access to the underlying containers, which can in turn allow the adversary to access container APIs or exploit container host access.
Adversaries may leverage external facing remote services to gain initial access into containerized environments. In Docker, initial access may be gained through an exposed Docker API on port 2375. In Kubernetes environments, adversaries may leverage exposed components including the API server, the kubelet, or administrative tools such as the Kubernetes dashboard to gain unauthenticated remote management of a cluster.
Adversaries may obtain and abuse credentials for existing accounts within container and container orchestration contexts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.
Valid Accounts: Local Accounts
Adversaries may gain remote access via SSH or similar means using valid container credentials. If the container is configured such that those credentials are sufficiently privileged, they may grant an adversary increased privilege and additional access to host/cluster resources which they may use to maintain persistence or remain undetected within the environment.
Execution
Container Service (NEW)
Adversaries may abuse a container service to execute commands within a container. This may involve leveraging an exposed Docker API port to tell the Docker daemon to execute certain specified commands after deploying a container. In Kubernetes, if an adversary has sufficient permissions, they may gain remote execution in a container in the cluster via interaction with the API server, the kubelet, or by running “kubectl exec”.
Deploy Container (NEW)
Adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container to simply execute its associated process(es). In others, an adversary may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment. Adversaries may use the Docker API to retrieve a malicious image and run that image on a host, or they may retrieve a benign image that downloads a malicious payload at runtime. In Kubernetes, adversaries may deploy one or more containers from the dashboard or via another application such as Kubeflow.
Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code via deployment of containers within a cluster.
Scheduled Task/Job: Container Orchestration Job (NEW)
Adversaries may abuse task scheduling functionality provided by container orchestration tools to schedule deployment of containers configured to execute malicious code. This malicious code may expand adversary privilege/access, and deployments of this type can be configured to maintain a quantity of containers over time, automating the process of maintaining persistence within the cluster. For example, in Kubernetes CronJobs may be used to schedule Kubernetes Jobs that execute malicious code within one or more containers in a cluster.
Adversaries may rely upon specific actions by a user in order to gain execution within a container context.
User Execution: Malicious Image (NEW)
Adversaries may rely on a user downloading and running a malicious image to facilitate execution. For example, a user may pull down an image from a public image repository like Docker
Hub and deploy a container from the image without realizing the image is malicious. This may lead to the execution of malicious code, such as code that executes cryptocurrency mining in the container.
Persistence
Implant Internal Image (Name change for Implant Container Image)
An adversary may implant an image in an internal environment to establish persistence. For example, and adversary may implant an image in a local Docker registry as opposed to uploading a container image to a public repository like Docker Hub.
Privilege Escalation
Escape to Host (NEW)
Adversaries may break out of a containerized environment to gain access to the underlying host. For example, an adversary may create a container configured to mount the host’s filesystem using the bind parameter or utilize a privileged container to run commands on the underlying host. Gaining access to the host may provide the adversary the opportunity to achieve follow-on objectives, such as establishing persistence or a command and control channel on the host.
Defense Evasion
Build Image on Host (NEW)
Adversaries may build a container image directly on a host to bypass defenses that monitor for the deployment or retrieval of images from a public registry. Rather than pulling a malicious image or a vanilla image that downloads malicious elements during runtime, an adversary may build
an image directly on the host that downloads malicious scripts through the Docker daemon API.
Adversaries may attempt to manipulate their resources to appear legitimate or benign to users and/or security tools. This may include using a Kubernetes deployment to deploy a container or downloading an image from a public image repository like Docker Hub with seemingly legitimate names.
Masquerading: Match Legitimate Name or Location
Adversaries may match or approximate the name or location of container resources when naming/placing them. For example, adversaries may pull down images from a public image repository like Docker Hub with “ubuntu” or “alpine” in the name that house malicious code. In Kubernetes, adversaries may match the naming convention of pods and containers in clusters to disguise their own malicious resources or deploy containers in the kube-system namespace where the administrative containers reside.
Credential Access
Adversaries may use brute force techniques to gain access to container and container orchestration accounts when passwords are unknown.
Brute Force: Password Guessing
Adversaries with no prior knowledge of legitimate credentials within the container or container orchestration platform may guess passwords to attempt access to accounts.
Brute Force: Password Spraying
Adversaries may use a single or small list of commonly used passwords against many different container or container orchestration platform accounts to attempt to acquire valid account credentials.
Brute Force: Credential Stuffing
Adversaries may use credentials obtained from breach dumps of unrelated accounts to gain access to target container or container orchestration platform accounts through credential overlap.
Adversaries may search compromised container environment systems to find and obtain insecurely stored credentials.
Unsecured Credentials: Credentials in Files
Adversaries may search plaintext configuration files for containers or other cluster resources to access exposed credentials within that configuration. For example, an adversary may access credentials that can be found as plaintext parameters to deployment commands, secrets within the Kubernetes dashboard, or service account tokens.
Unsecured Credentials: Container API (NEW)
Adversaries may enumerate and gather credentials by accessing APIs within a container environment. For example, an adversary may access the Docker API to collect logs that contain credentials to resources in the environment. An adversary with sufficient permissions, such as via using the pod service account, may use the Kubernetes API to retrieve credentials from the Kubernetes API server.
Discovery
Container Resource Discovery (NEW)
Adversaries may attempt to discover resources that are available within a container environment, such as containers or components deployed on a cluster. These resources can be viewed within environment dashboards or can be queried via container and container orchestration APIs.
Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users. Those attacks can be performed from containers within compromised environments, and can be targeted against containerized services.
Adversaries may perform Network Denial of Service (DoS) attacks to degrade or block the availability of targeted resources to users. Those attacks can be performed from containers within compromised environments, and can be targeted against containerized services and environments.
Adversaries may leverage the resources of co-opted systems in order to solve resource intensive problems which may impact system and/or hosted service availability. Within a compromised cluster, this may include repurposing compromised containers or deploying new containers to run services, such as those that perform cryptocurrency mining, using environment resources.
About the Center for Threat-Informed Defense
The Center for Threat-Informed Defense is a non-profit, privately funded research and development organization operated by MITRE Engenuity. The Center’s mission is to advance the state of the art and the state of the practice in threat-informed defense globally. Comprised of participant organizations from around the globe with highly sophisticated security teams, the Center builds on MITRE ATT&CK®, an important foundation for threat-informed defense used by security teams and vendors in their enterprise security operations. Because the Center operates for the public good, outputs of its research and development are available publicly and for the benefit of all.
© 2021 MITRE Engenuity. Approved for Public Release. Document number CT0013
