Detection of Unauthorized Interactive Kubernetes API Probing

This detection pattern identifies unauthorized interactive access attempts within a Kubernetes cluster. When an attacker gains access to a container, they often utilize shell environments to perform discovery and lateral movement. By leveraging utilities such as kubectl, curl, or openssl, attackers attempt to communicate with the Kubernetes API server to enumerate resources, probe for secrets, or test service account privileges. Because these actions are often performed by under-privileged accounts or against sensitive endpoints, they result in 'forbid' decisions within the Kubernetes audit logs. This rule provides a mechanism for detection engineers to correlate the specific interactive shell activity within a container with these denied API requests, identifying potential hands-on-keyboard probing even when the attacker lacks the necessary permissions to succeed. This visibility is critical for identifying compromised workloads that are being repurposed for cluster-level discovery.

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.