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.
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.
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.
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.
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.
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.