MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 3
Learn about the last three threat vectors in Kubernetes: lateral movement, collection, and impact.
Overview
In this second piece of a 3-part series, we will take a deep dive into the MITRE ATT&CK Matrix of known tactics and techniques. This post discusses these remaining three threat vectors - Lateral Movement, Collection, and Impact
Further reading on MITRE ATT&CK Matrix:
- MITRE ATT&CK Matrix Part I: Threat Vectors - Initial Access, Execution, Persistence, and Privilege Escalation
- MITRE ATT&CK Matrix Part II: Threat Vectors - Defense Evasion, Credential Access, Discovery
Lateral Movement
Attackers use lateral movement techniques to move through a victim’s environment following a breach. The goal is usually to gain access to other resources, such as other containers or nodes. In containerized environments, they may try to gain access to various resources in the cluster from given access to one container, to the underlying node from a container, or to the cloud environment.
1- Access Cloud Resources
In this technique, attackers may gain access to a single container to compromise it, and then move from this compromised container to the cloud environment and its resources.
2- Container Service Account
By default, a service account (SA) in Kubernetes is mounted to every pod in a cluster. It allows containers to send requests to the Kubernetes API server. An attacker who gains access to a pod can obtain the SA token to send requests to the API server, and gain access to additional resources in the cluster. If RBAC is enabled, SA privileges are determined by the role bindings associated with it. But if RBAC is not enabled, the SA token will grant the attacker full access to the cluster.
3- Cluster Internal Networking
By default, Kubernetes does not restrict network traffic (communication) between pods in the cluster. If an attacker gains access to a single container, they may use the compromised container to expand their network reachability, and gain access to other containers, pods, and applications in the cluster.
4- Application Credentials in Configuration Files
Secrets are stored in the Kubernetes configuration files, for example, as environment variables in the pod configuration. If an attacker has access to these configurations, they may be able to steal these secrets, and use them to access resources inside and outside the cluster.
5- Writable Volume Mounts on The Host
In this technique, the hostPath volume mounts a file or directory to the container. Attackers may try to gain access to the underlying host from a compromised container and persist on the container host.
6- CoreDNS Poisoning
CoreDNS is the main Domain Name Server (DNS) service used in Kubernetes. Its configuration can be modified by a file named corefile which is stored in a ConfigMap object located at the kube-system namespace. An attacker with permission to modify the ConfigMap (say, by using the container’s service account) can change the behavior of the cluster’s DNS. It can then poison it, and take the network identity of other services.
7- ARP Poisoning and IP Spoofing
Kubernetes has multiple Container Network Interfaces (CNIs) – network plugins that can be used in the cluster. Often, the default network plugin is Kubenet. In this configuration, a bridge is created on each node (cbr0). Various pods are connected to nodes using veth pairs.
The bridge is a level-2 component that carries cross-pod traffic, which makes ARP poisoning in the cluster possible. An attacker with access to a pod in the cluster can perform ARP poisoning, and spoof the traffic of other pods. They can perform several attacks at the network level, leading to lateral movements, such as DNS spoofing or stealing cloud identities of other pods.
Collection
In Kubernetes, attackers use collection techniques to collect information from the cluster or by using the cluster. One way to mitigate such attacks is to implement read-only policies for the registry credentials used in Kubernetes.
1- Images from Private Registry
Images running in the cluster can be stored in a private registry. To pull these images, the container runtime engine must have valid credentials to those registries. If the registry is hosted by the cloud provider, it is authenticated with cloud credentials. But if an attacker gets access to the cluster, they may be able to gain access to the private registry and pull its images. One way is to use the managed identity token by leveraging the access of a Kubernetes pod to the IMDS endpoint.
Impact
Attackers use impact techniques to destroy, abuse, or disrupt the normal behavior of the target environment, and its resources and activities.
1- Data Destruction
An attacker may try to delete or remove resources in a Kubernetes cluster. These resources may include deployments, configurations, nodes, pods, storage, compute, or other data.
2- Resources Hijacking
In this technique, an attacker attempts to hijack and abuse a Kubernetes resource for a purpose that it was not originally intended for. One example is using compromised containers to run malicious tasks, such as digital currency mining (cryptomining), also known as a “cryptojacking” attack.
3- Denial of Service
An attacker may seek to make a service unavailable to legitimate users. They may impact the availability of components within the Kubernetes control plane, such as the API server, cluster nodes, or application components in pods.
MITRE ATT&CK and Weave GitOps
In Kubernetes-based environments and the growing threat landscape, security is crucial. One way organizations can fortify their infrastucture and verify in-place cybersecurity controls is by using the MITRE ATT&CK framework. Businesses can use this framework to bettern understand the attack surface in their environments and thus implement adequate detections and mitigations to the various risk.
GitOps, the operational paradigm used for Kubernetes management and continuous deployments, is by nature security-focused. To further bolster GitOps pipelines' security, Weaveworks has recently added policy as code capabilities to GitOps pipelines and dubbed it Trusted Delivery. With Trusted Delivery, teams can achieve continuous security and compliance through integrating policy as code into GitOps pipelines. The Weave Policy Library, a library of hundreds of OPA-based policies, includes the MITRE ATT&CK policies, eliminating the need for teams to research, identify, and implement them.
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.
