Detection of Interactive Kubernetes API Abuse via Container Utilities

This threat involves adversaries who have gained initial access to a containerized environment attempting to escalate privileges or perform reconnaissance by interacting directly with the Kubernetes API server. Attackers leverage existing containerized utilities such as 'curl', 'wget', 'kubectl', 'socat', or 'ncat' to perform 'hands-on-keyboard' discovery. By compromising a pod, an attacker can access the mounted Kubernetes service account token located at '/var/run/secrets/kubernetes.io/serviceaccount/token'. Using this token, they perform direct HTTP(S) requests to the Kubernetes API server to enumerate pods, secrets, and cluster-scoped RBAC objects, facilitating further lateral movement. This detection approach focuses on correlating interactive process execution within a container with near-simultaneous Kubernetes audit log events. Defenders should focus on workloads that do not require network utilities or direct API access to function as part of their standard operations.

Attack Chain

1. Attacker exploits a vulnerability in a containerized application to gain remote code execution.
2. Attacker invokes an interactive shell (e.g., '/bin/sh', 'bash') inside the compromised container.
3. Attacker locates the Kubernetes service account token at '/var/run/secrets/kubernetes.io/serviceaccount/token'.
4. Attacker uses an installed utility like 'curl' or 'kubectl' to initiate an interactive session.
5. Attacker executes a command targeting the Kubernetes API server endpoint (e.g., 'https://kubernetes.default.svc').
6. The Kubernetes API server logs the request in the audit logs, reflecting the pod's service account identity.
7. Attacker parses the API response to enumerate cluster resources, secrets, or RBAC configurations.
8. Attacker uses identified information to move laterally or exfiltrate sensitive data from the cluster.

Impact

Successful exploitation allows attackers to bypass pod-level isolation to discover cluster topology, gain unauthorized access to secrets, or modify RBAC configurations. This activity often precedes full cluster compromise, exfiltration of sensitive credentials stored in Kubernetes Secrets, or the deployment of persistent backdoor pods, potentially affecting any enterprise utilizing Kubernetes for production workloads.

Recommendation

Prioritize the following actions for your detection and response teams:

• Deploy the provided EQL-based logic to correlate 'logs-cloud_defend.process' events with 'kubernetes.audit_logs' entries to surface interactive API abuse.
• Audit all container images to remove unnecessary networking utilities (e.g., curl, wget, ncat, socat) and Kubernetes binaries (kubectl) to minimize the attack surface.
• Implement and enforce NetworkPolicies to restrict pod-level egress, specifically blocking traffic to the 'kubernetes.default.svc' API endpoint for pods that do not require cluster administration.
• Regularly rotate service account tokens and use fine-grained RBAC with 'automountServiceAccountToken' set to 'false' for all pods where it is not strictly necessary.