Attack Chain

1. Attacker gains initial access to a container process (e.g., via web application exploit).
2. Attacker executes an interactive shell (e.g., /bin/bash or /bin/sh) within the container.
3. Attacker identifies native tooling within the container (e.g., kubectl, curl, openssl) or drops malicious binaries.
4. Attacker uses the container's mounted ServiceAccount token to initiate an API request to the Kubernetes API server.
5. API request is sent from the pod to the API server endpoint (e.g., https://kubernetes.default.svc).
6. Kubernetes authorization policy evaluates the request and returns an HTTP 403 Forbidden status.
7. Audit logs record the forbidden action associated with the specific pod identity.
8. Security monitoring platform correlates the local shell activity with the denied API audit log.

Impact

Successful unauthorized discovery can provide an attacker with a map of the cluster's network, services, and secrets. If the attacker successfully leverages an over-privileged service account, they may escalate privileges or pivot to other nodes within the cluster. This activity indicates a breakdown in container isolation and least-privilege RBAC.

Recommendation

• Enable Kubernetes Audit Logging and stream to the SIEM to support the audit correlation logic described in this brief.
• Deploy the EQL detection logic to identify unauthorized interactive attempts originating from pods.
• Implement NetworkPolicies that restrict egress from non-admin containers to the Kubernetes API server IP addresses.
• Perform regular audits of ServiceAccount permissions, ensuring pods only possess the minimal RBAC roles required for their function.
• Rebuild container images to exclude administrative tooling (kubectl, curl, nmap, socat) where such functionality is not required for application operation.

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.