<img src="https://ws.zoominfo.com/pixel/JHVDdRXH2uangmUMQBZd" width="1" height="1" style="display: none;">

MITRE ATT&CK Matrix for Kubernetes

These pages cover what Magalix is, how to get started using it, and reference materials for its features and supported cloud providers.

Get started quickly, and get all your questions answered now!

Talk to an Expert

    Lateral Movement

    MITRE ATTACK - Lateral Movement

    Overview

    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.

    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.

    MITRE ATTACK - Access Cloud Resources

    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.

    MITRE ATTACK - Container Service Account

    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.

    MITRE ATTACK - Cluster Internal Networking

    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.

    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.

    MITRE ATTACK - Writable Volume Mounts on The Host

    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.

    MITRE ATTACK - CoreDNS Poisoning

    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.

    arrow