MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 1
Learn about the first four threat vectors in Kubernetes: initial access, execution, persistence, and privilege escalation.
Overview
The MITRE ATT&CK Matrix for Kubernetes is a knowledge base of techniques and tactics, indexed and broken down into detail the exact steps and methods attackers use to infiltrate the Kubernetes cluster.
An attacker usually strategizes how to infiltrate a cluster and perform damage by following the stages that entail an attack lifecycle. The attacker must progress through each of these stages for the attack to be successful.
The MITRE ATT&CK Framework is a great guideline to use when establishing a security baseline, helping security teams better understand how attackers exploit Kubernetes-based environments and accordingly develop more effective practices against them.
In the above matrix, each column represents a different attack stage, and each item in each column represents a tactic employed by attackers during that stage. The categorization is intended to help organizations determine their attack surface and adopt suitable detection and mitigation strategies.
In this first piece of a 3-part series, we will dive into the MITRE ATT&CK Matrix of known tactics and techniques. This post discusses the first four threat vectors - Initial Access, Execution, Persistence, and Privilege Escalation.
Further reading on MITRE ATT&CK Matrix:
• MITRE ATT&CK Matrix Part II: Threat Vectors - Defense Evasion, Credential Access, Discovery
• MITRE ATT&CK Matrix Part III: Threat Vectors - Lateral Movement, Collection, Impact
Initial Access
Initial Access refers to tactics an attacker may use to access a Kubernetes cluster. They may do this either by compromising various resources deployed on the cluster or directly by compromising a component within the Kubernetes control plane that handles cluster management.
1- Using Cloud Credentials
If the Kubernetes cluster is deployed in a public cloud and if a cloud credential is compromised, attackers may get access to the cluster’s management layer. A compromised credential may lead to a compromise of the entire cluster and may also lead to a cluster takeover.
2- Compromised Images in Registry
A compromised, untrusted or unsafe image running in a cluster can lead to its compromise. It may be downloaded from a public image registry (e.g., Docker Hub), built from untrusted base images, or added to a private registry by an attacker and pulled by a user. It may contain malicious code that allows an attacker to access a cluster.
3- Kubeconfig File
The kubeconfig file, used by kubectl, contains the location and credentials of clusters. A compromised client could issue cloud commands to download this file if the cluster is hosted as a cloud service. If a bad actor gets access to this file, they can use it to access the clusters.
4- Application Vulnerability
Containerized, public-facing applications with vulnerabilities leave an organization susceptible to exploits by threat actors. If they run in a cluster, the threat actor may gain initial access to the cluster. They may also exploit the vulnerability to reach other applications, access sensitive data, or launch a Denial of Service (DoS) attack.
5- Exposed Sensitive Interfaces
When a sensitive interface is exposed to the Internet, it creates a security risk. Frameworks that don’t require authentication by default are particularly vulnerable. Exposing such frameworks allows malicious actors to gain unauthenticated access to a sensitive interface and run code or deploy containers in the cluster. One such interface that has been exploited previously is the Kubernetes dashboard.
Execution
This second tactic describes an attacker’s various techniques to run malicious code inside a Kubernetes cluster to achieve some objective. To run this code, they may start a new pod, gain access to a running pod, or exploit an application vulnerability.
1- Exec Into Container
An attacker could use the exec command kubectl exec to remotely run malicious commands in cluster containers. If they have permissions, they may use legitimate images, such as an OS image as a backdoor container, to execute malicious code and compromise resources within a cluster.
2- Bash/CMD Inside Container
In this technique, an attacker with permissions could run a bash script inside a container to execute malicious code and compromise cluster resources.
3- New Container
A threat actor with permissions may use malicious code in the Kubernetes cluster by deploying a container. They may deploy a new pod or a controller in the cluster, such as Deployments, DaemonSets, or ReplicaSets. They can then create a new resource to execute their malicious code and compromise cluster resources.
4- Application Exploit (RCE)
Applications in some clusters may contain a vulnerability that allows for remote code execution. Attackers may exploit this vulnerability to execute malicious code in the cluster. They may also compromise other resources in the cluster, access sensitive data on metadata servers, or cause a DoS attack. If the service account is mounted to the container, they may use its credentials to send requests to the kubelet read-only API server.
5- SSH Server Running Inside Container
An SSH (Secure Socket Shell) server running inside a container is vulnerable to threat actors. If an attacker gains credentials to that container by brute force or phishing, they may remotely access the container to run malicious code and compromise resources.
6- Sidecar Injection
A sidecar container is an additional container that resides alongside the main container and shares storage and network resources with other containers in a Kubernetes pod. Attackers may inject a sidecar container into a legitimate Kubernetes pod in the cluster to run their malicious code and hide their activity.
Persistence
Attackers use persistence techniques to retain access to a Kubernetes cluster and maintain a presence within it, even if they lose their initial foothold. To do this, they may take advantage of Kubernetes controllers, mount a file to a container, or run recurring Kubernetes jobs.
1- Backdoor Container
An attacker could utilize Kubernetes controllers like DaemonSets or Deployments to ensure that a constant number of containers are always running in one or all nodes of the cluster. They may execute malicious code in a cluster container.
2- Writeable hostPath Mount
The hostPath volume mounts a file or directory from the host to the container. If the attacker has permission to create a new container in the cluster, they may do so with a writable hostPath volume. This allows them to persist on the underlying container host, for example, by creating a cron job on the host.
3- Kubernetes CronJob
A Kubernetes Job controller creates one or more pods to accomplish a specific task. It also ensures that a specified number of pods terminate successfully. It may be used to run containers that perform finite tasks for batch jobs. Kubernetes CronJob creates Jobs on a recurring schedule. An attacker can leverage CronJob to schedule the execution of malicious code, which would run as a container in a cluster.
4- Malicious Admission Controller
A threat actor may use a malicious admission controller in Kubernetes to access credentials. One such controller is ValidatingAdmissionWebhook, a generic, built-in controller whose behavior is determined by an admission webhook deployed in the cluster. Attackers may use this webhook to intercept sensitive information like requests to the API server, and to record secrets.
Privilege Escalation
This tactic includes techniques that enable attackers to gain additional or higher privileges in the environment. They can use these privileges to get access to more resources in the cluster or take other actions within the cluster. In containerized environments, they may get access to the node from a container.
1- Privileged Container
A privileged container has all the capabilities of the host machine and none of the limitations of a regular container. If an attacker gains access to a privileged container or has the permissions to start a new privileged container, they can gain access to the host’s resources, or compromise other containers running on the same host.
2- Cluster-admin Binding
Cluster-admin is a built-in high privileged role in Kubernetes. Users with this role have full access to the cluster, and can potentially compromise it. Attackers with RBAC (Role-based access control) permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin role or other roles with high privileges.
3- HostPath Mount
The hostPath volume mounts a file or directory from the host to the container. This can allow attackers to gain access to the underlying host or resources, break from the container to the host, or compromise other containers running on the same host.
4- Access Cloud Resources
An adversary may use this technique to gain access to a single container in a Kubernetes cloud cluster to access other cloud resources outside the cluster. For instance, if they gain access to the service principal credential file in Azure Kubernetes Service (AKS), they may be able to use these credentials to access or modify the cloud resources.
MITRE ATT&CK and Weave GitOps
In our March 2022 product release, we introduced Trusted Delivery: a practice of codifying security policies within software delivery pipelines. With Trusted Delivery, businesses can now enforce security best practices, in code form, and protect the applications and environments they run on.
Weave GitOps’ Trusted Delivery now includes MITRE ATT&CK OPA-based policies, as part of the larger Weave Policy Library. This library includes a wide array of security best practices, and industry standards such as CIS, NIST, GDPR, PCI DSS, and many more. This off-the-shelf policy library eliminates the need for teams to research, identify, and enforce these baseline security policies.
Request a demo now to learn more about Trusted Delivery and explore our Weave Policy Library.
Request a DemoWhitepaper: Trusted Delivery with GitOps and Policy as Code
Download our latest whitepaper and learn how automated security and compliance checks, in the form of policy as code, make automated continuous deployments safe and secure.
