Kubernetes Multi-Resource Discovery

This detection rule identifies potential reconnaissance activity within Kubernetes clusters. It focuses on scenarios where an attacker, having gained initial access or leveraging an over-privileged token, attempts to map the cluster environment. This reconnaissance involves rapidly querying multiple distinct API resource kinds such as namespaces, workloads, roles, and cluster-wide roles. The rule triggers when a single client fingerprint (defined by user name, source IP, and user agent) exhibits a burst of get/list requests across three or more distinct resource types within a one-minute window. This behavior is less typical for steady-state controllers, which usually interact with a narrow set of resources repeatedly. The rule aims to highlight such cross-resource bursts, enabling analysts to distinguish routine automation from potential discovery and permission reconnaissance.

Attack Chain

1. Attacker gains initial access to the Kubernetes cluster, either through compromised credentials or by exploiting a vulnerability.
2. The attacker uses a valid Kubernetes API token or compromised service account to interact with the API server.
3. The attacker begins enumerating cluster resources using get and list actions, targeting various API endpoints.
4. The attacker queries resources such as namespaces, nodes, pods, roles, configmaps, serviceaccounts, clusterroles, clusterrolebindings, and rolebindings.
5. These queries are executed within a short time frame (one-minute window) to rapidly gather information about the cluster’s structure and permissions.
6. The attacker analyzes the collected information to identify potential targets for privilege escalation or data exfiltration.
7. Based on the discovered information, the attacker might attempt to read secrets or configmaps, modify rolebindings, or execute commands within pods.
8. The attacker achieves their final objective, such as gaining elevated privileges, exfiltrating sensitive data, or deploying malicious workloads.

Impact

A successful reconnaissance attempt can provide attackers with a comprehensive understanding of the Kubernetes cluster’s layout, security policies, and available resources. This information can then be used to facilitate further malicious activities, such as privilege escalation, lateral movement, data exfiltration, or the deployment of malicious containers. Failure to detect and respond to such reconnaissance attempts can significantly increase the risk of a successful attack on the Kubernetes environment, leading to potential data breaches, service disruptions, or other security incidents.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect suspicious multi-resource discovery activity in Kubernetes audit logs.
• Investigate any alerts generated by the Sigma rule by pivoting on Esql.time_interval and the same identity or IP in raw audit logs to see the ordering of events.
• Review Esql.decisions and namespaces touched, correlating with RBAC for that identity to see if the scope matches a known job or breaks least-privilege expectations.
• Monitor for follow-on activity, such as secret/configmap reads, rolebinding changes, or pod executions, originating from the same user or IP address.
• Tune the Sigma rule by allowlisting known service accounts or source networks that legitimately span these resource types in a short window.