Direct Interactive Kubernetes API Request by Unusual Utilities

This detection rule, originating from Elastic's detection-rules repository and designed for use with Defend for Containers and Kubernetes audit logs, identifies potential malicious activity within Kubernetes environments. Specifically, it focuses on detecting interactive commands executed inside containers that utilize unusual utilities to interact with the Kubernetes API. The rule flags instances where these interactions are coupled with near-simultaneous API activity on sensitive resources like pods, secrets, and service accounts. The rule aims to detect adversaries who might be using custom scripts or binaries to evade standard tool allowlists. The rule was introduced in Elastic stack version 9.3.0.

Attack Chain

1. An attacker gains initial access to a container within a Kubernetes pod, potentially through exploiting a vulnerability in the application running within the container.
2. The attacker establishes an interactive shell session within the compromised container.
3. Instead of using common tools like kubectl, curl, or wget, the attacker leverages an unusual utility (e.g., a custom Python script, busybox or ncat) to interact with the Kubernetes API.
4. The attacker uses this utility to enumerate Kubernetes resources such as pods, services, secrets, and service accounts, attempting to discover sensitive information and potential lateral movement paths.
5. The attacker queries the Kubernetes API to gather information about service account tokens or other credentials that could be used to authenticate to other services or pods.
6. The attacker initiates a pods/exec or pods/attach request to gain access to another pod, using the compromised credentials, or forward ports to access services.
7. The attacker uses the newly accessed pod or service to further explore the Kubernetes environment, potentially escalating privileges or accessing sensitive data.

Impact

A successful attack could lead to the compromise of sensitive data stored in Kubernetes secrets and configmaps, the unauthorized access to other pods and services, and the potential for privilege escalation within the Kubernetes cluster. The rule aims to detect early stages of a potential breach, limiting the damage to a contained workload.

Recommendation

• Deploy the provided Sigma rules to your SIEM and tune for your environment to detect suspicious Kubernetes API activity.
• Investigate any alerts generated by the Sigma rule to determine if they are indicative of malicious activity or legitimate container activity.
• Enforce least-privilege RBAC, deny pods/exec and attach for application service accounts, and set automountServiceAccountToken: false on workloads that don't need it.
• Use network policies to restrict egress traffic from pods to the Kubernetes API server (kubernetes.default.svc:443) or other critical services.