Lateral Movement Detection

Lateral movement in Kubernetes: common patterns

Kubernetes clusters often run multiple workloads in separate namespaces with the assumption of isolation. But overly permissive RBAC, missing NetworkPolicies, and service account token auto-mounting create lateral movement paths that attackers exploit.

• Service account token theft — reading /var/run/secrets/kubernetes.io/serviceaccount/token from a compromised pod to access the K8s API
• Cross-namespace service access — connecting to services in adjacent namespaces that lack NetworkPolicy enforcement
• RBAC escalation via ClusterRole bindings — exploiting overly broad ClusterRole bindings to access secrets across namespaces
• Pod-to-Pod credential harvesting — scraping environment variables and mounted secrets from accessible pods via the API server

How Kubesentry detects lateral movement

• Service account token file access — alerts when a process reads the auto-mounted service account token file outside expected application paths
• Anomalous cross-namespace connections — detects network connections to services in namespaces with no prior connection history from the originating pod
• kubectl binary execution in containers — flags execution of kubectl or curl against the K8s API server (10.96.0.1) from non-privileged containers
• Audit log correlation — cross-references API server audit events for unusual GET/LIST operations on secrets or cross-namespace resources
• Namespace boundary network anomalies — baseline-compares network egress patterns per pod and alerts on new destination IP/port combinations

Response playbook

1. Identify the originating pod and namespace. Review the service account token access event in the Kubesentry alert — note which service account was accessed.
2. Assess the compromised service account's RBAC permissions. Run kubectl auth can-i --list --as=system:serviceaccount:<ns>:<name> to understand blast radius.
3. Revoke the service account token. Delete and recreate the service account to invalidate the current token. Update any legitimate pods that use it.
4. Audit K8s API server logs. Check for API calls made using the compromised token — look for GET on secrets, creation of new pods, or exec into other pods.
5. Implement NetworkPolicy. Add deny-all-ingress/egress NetworkPolicies to the affected namespaces as immediate containment. Define explicit allow rules for required traffic.
6. Disable service account auto-mount. Set automountServiceAccountToken: false on pods that don't require API server access.

Related detections