Kubernetes Anonymous Request Authorized by Unusual User Agent
This rule detects when an unauthenticated user request is authorized within a Kubernetes cluster via an unusual user agent, potentially indicating an attacker attempting to gain initial access or avoid attribution by exploiting anonymous accounts.
This detection rule identifies unauthorized access attempts in Kubernetes environments by monitoring audit logs for unusual, authorized anonymous requests. Kubernetes, by default, allows anonymous access, creating a potential attack vector. Threat actors might exploit this to gain initial access to the cluster or to mask their activities. This rule focuses on detecting anomalous user agents associated with anonymous requests, excluding common health check endpoints like /healthz, /livez, /readyz, /version, and /.well-known/oauth-authorization-server to minimize false positives. The rule is designed for Kubernetes environments using Audit Logs and aims to catch deviations from expected anonymous traffic patterns. The detection logic specifically looks for authorized requests made by the system:anonymous or system:unauthenticated users, coupled with unusual user-agent strings.
Attack Chain
- The attacker leverages the default Kubernetes configuration that allows anonymous access.
- An unauthenticated request is sent to the Kubernetes API server.
- The Kubernetes API server authorizes the anonymous request based on existing RBAC policies (misconfiguration).
- The request bypasses standard authentication procedures due to the anonymous access allowance.
- The attacker uses a non-standard user agent to interact with the API, attempting to avoid detection.
- The unusual user agent triggers the detection rule, flagging the anomalous behavior.
- If successful, the attacker gains unauthorized access to cluster resources.
- The attacker attempts to perform privileged actions.
Impact
Successful exploitation of anonymous access can lead to unauthorized access to sensitive resources within the Kubernetes cluster. This may result in data breaches, service disruption, or complete compromise of the cluster. The rule aims to detect and prevent attackers from leveraging anonymous access to escalate privileges or deploy malicious workloads. If successful, an attacker could potentially deploy malicious containers, modify cluster configurations, or exfiltrate sensitive data.
Recommendation
- Enable the Kubernetes Fleet integration with Audit Logs or ensure similarly structured data is available, which is required for the detection rule to function (Setup section).
- Deploy the Sigma rule
Kubernetes Anonymous Request Authorized by Unusual User Agentto your SIEM and tune the exclusion list to fit your environment to reduce false positives (rule section). - Revoke any unnecessary anonymous access permissions within the Kubernetes cluster to minimize the attack surface, in accordance with the referenced hardening guidance (references section).
- Investigate any alerts generated by the Sigma rule to identify the specific request, source IP, and targeted resource to determine the scope and severity of the potential breach (rule section).
Detection coverage 2
Kubernetes Anonymous Request Authorized by Unusual User Agent
mediumDetects authorized Kubernetes API requests from anonymous users with unusual user agents, excluding common health check endpoints.
Kubernetes Anonymous Request - High Volume
lowDetect a high volume of kubernetes API requests from anonymous users, potentially indicating scanning or brute force attempts
Detection queries are available on the platform. Get full rules →