Forbidden Request from Unusual User Agent in Kubernetes

 1[metadata]
 2creation_date = "2025/06/17"
 3integration = ["kubernetes"]
 4maturity = "production"
 5updated_date = "2025/07/07"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment.
11Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which
12can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden
13request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations
14in the Kubernetes cluster.
15"""
16index = ["logs-kubernetes.audit_logs-*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Forbidden Request from Unusual User Agent in Kubernetes"
20note = """ ## Triage and analysis
21
22> **Disclaimer**:
23> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
24
25### Investigating Forbidden Request from Unusual User Agent in Kubernetes
26
27Kubernetes, a container orchestration platform, manages applications across clusters. It uses APIs for communication, which can be targeted by adversaries using atypical user agents to mask malicious activities. These agents may attempt unauthorized actions, exploiting vulnerabilities. The detection rule identifies such anomalies by flagging forbidden requests from non-standard user agents, indicating potential threats.
28
29### Possible investigation steps
30
31- Review the Kubernetes audit logs to identify the source IP address and user associated with the forbidden request. This can help determine if the request originated from a known or unknown entity.
32- Analyze the user agent string in the audit logs to understand its origin and purpose. Cross-reference it with known legitimate user agents to assess its legitimacy.
33- Check for any recent changes or deployments in the Kubernetes environment that might have introduced new user agents or configurations, potentially leading to the forbidden request.
34- Investigate the specific resource or API endpoint that was targeted by the forbidden request to understand what the adversary might have been attempting to access or exploit.
35- Correlate the event with other security logs and alerts to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort.
36- Assess the current security posture and configurations of the Kubernetes cluster to identify any vulnerabilities or misconfigurations that could be exploited by adversaries using unusual user agents.
37
38### False positive analysis
39
40- Legitimate internal tools or scripts may use non-standard user agents that are not included in the exclusion list. Review and identify these tools, then update the exclusion list to prevent them from being flagged.
41- Automated processes or third-party integrations might use unique user agents that trigger the rule. Verify these processes and consider adding their user agents to the exclusion list if they are deemed safe.
42- Development or testing environments often use custom user agents for API interactions. Ensure these environments are accounted for by excluding their user agents to avoid unnecessary alerts.
43- Regularly review and update the exclusion list to reflect changes in legitimate user agents used within your organization, ensuring that only truly unusual and potentially malicious agents are flagged.
44
45### Response and remediation
46
47- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary.
48- Revoke any suspicious or unauthorized credentials or tokens that may have been used in the forbidden request to ensure they cannot be reused.
49- Conduct a thorough review of the Kubernetes audit logs to identify any additional unauthorized or suspicious activities that may have occurred around the time of the alert.
50- Patch any identified vulnerabilities or misconfigurations in the Kubernetes environment that may have been exploited, ensuring all components are up to date with the latest security patches.
51- Implement stricter access controls and user agent validation to prevent non-standard user agents from interacting with the Kubernetes API unless explicitly allowed.
52- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary.
53- Enhance monitoring and alerting for similar activities by tuning detection systems to recognize patterns associated with this type of threat, ensuring rapid response to future incidents.
54"""
55risk_score = 47
56rule_id = "4b77d382-b78e-4aae-85a0-8841b80e4fc4"
57severity = "medium"
58tags = ["Data Source: Kubernetes", "Tactic: Execution", "Resources: Investigation Guide"]
59timestamp_override = "event.ingested"
60type = "eql"
61query = '''
62any where host.os.type == "linux" and event.dataset == "kubernetes.audit_logs" and
63kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid" and
64not user_agent.original like~ (
65  "/", "karpenter", "csi-secrets-store/*", "elastic-agent/*", "agentbeat/*", "insights-operator*", "oc/*", "cloud-defend/*",
66  "OpenAPI-Generator/*", "local-storage-operator/*", "falcon-client/*", "nginx-ingress-controller/*", "config-translator/*",
67  "kwatch/*", "PrometheusOperator/*", "kube*"
68)
69'''
70
71[[rule.threat]]
72framework = "MITRE ATT&CK"
73
74[rule.threat.tactic]
75id = "TA0002"
76name = "Execution"
77reference = "https://attack.mitre.org/tactics/TA0002/"