Initial access Execution Persistence Privilege escalation Defense evasion Credential access Discovery Lateral movement Collection Impact
Using Cloud Exec into Container Backdoor Container Privileged Container Clear Container Logs List K8s secrets Access the K8s API server Access cloud resources Images from a private repository Data Destruction
Compromised images in registry bash/cmd in container Writable hostPath mount Cluster-admin binding Delete k8s events Mount service principal Access Kubelet API Container service account Ressource hijacking
Kubeconfig file New container Kubernetes CronJob hostPath mount Pod / container name similarity Access container service account Network mapping Cluster internal networking Denial of Service
Application vulnerability Application exploit (RCE) Malicious admission controller Access cloud resources Connect from proxy server Applications credentials in configuration files Access Kubernetes dashboard Applications credentials in configuration files
Exposed sensitive interfaces SSH server running in inside container Disable Namespacing Access managed identity credentials Instance metadata API Writable volume mounts on the host
Sidecar injection Malicious admission controller CoreDNS poisoning
ARP poisoning and IP spoofing

Network mapping

Attackers may try to map the cluster network to get information on the running applications, including scanning for known vulnerabilities. By default, there is no restriction on pods communication in Kubernetes. Therefore, attackers who gain access to a single container, may use it to probe the network.

Example

An attacker can for example use a network port scanning tool like naabu to scan the cluster for available pods and services.

apiVersion: v1
kind: Pod
metadata:
  name: naabu
spec:
  containers:
  - image: projectdiscovery/naabu
    name: naabu
    command: [ "naabu", "--host", "10.42.0.0/24", 
      "-p", "22,53,80,8080,443,8443,6443,2379-2380,10250,10259,10257,10250",
      "-silent" 
      ]

Please note that neither the IP address range nor port range is representing a full list on what could be of interest and it can vary for each cluster.

$ kubectl logs naabu
10.42.0.0:80
10.42.0.0:443
10.42.0.7:80
10.42.0.9:8443
10.42.0.1:80
10.42.0.1:6443
10.42.0.1:10250
10.42.0.1:443
10.42.0.8:443
10.42.0.8:80
10.42.0.2:53
10.42.0.2:8080

The following command assumes you have a pod called my-pod running and it offers you to execute the nslookup command.

$ kubectl exec -it my-pod -- nslookup 10.42.0.2
2.0.42.10.in-addr.arpa  name = 10-42-0-2.kube-dns.kube-system.svc.cluster.local.

References