Kubernetes Anonymous Request Authorized
This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2022/09/13"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects when an unauthenticated user request is authorized within the cluster. Attackers may attempt to use
11anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster.
12This rule excludes the /healthz, /livez and /readyz endpoints which are commonly accessed anonymously.
13"""
14false_positives = [
15 """
16 Anonymous access to the API server is a dangerous setting enabled by default. Common anonymous connections (e.g.,
17 health checks) have been excluded from this rule. All other instances of authorized anonymous requests should be
18 investigated.
19 """,
20]
21index = ["logs-kubernetes.*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "Kubernetes Anonymous Request Authorized"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating Kubernetes Anonymous Request Authorized
31
32Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.
33
34### Possible investigation steps
35
36- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.
37- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts.
38- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.
39- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.
40- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.
41
42### False positive analysis
43
44- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.
45- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.
46- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.
47- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.
48- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.
49
50### Response and remediation
51
52- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.
53- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.
54- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.
55- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.
56- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.
57- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
58- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.
59
60## Setup
61
62The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
63references = [
64 "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF",
65]
66risk_score = 47
67rule_id = "63c057cc-339a-11ed-a261-0242ac120002"
68severity = "medium"
69tags = ["Data Source: Kubernetes", "Tactic: Execution", "Tactic: Initial Access", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
70timestamp_override = "event.ingested"
71type = "query"
72
73query = '''
74event.dataset:kubernetes.audit_logs
75 and kubernetes.audit.annotations.authorization_k8s_io/decision:allow
76 and kubernetes.audit.user.username:("system:anonymous" or "system:unauthenticated" or not *)
77 and not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz*)
78'''
79
80
81[[rule.threat]]
82framework = "MITRE ATT&CK"
83[[rule.threat.technique]]
84id = "T1078"
85name = "Valid Accounts"
86reference = "https://attack.mitre.org/techniques/T1078/"
87[[rule.threat.technique.subtechnique]]
88id = "T1078.001"
89name = "Default Accounts"
90reference = "https://attack.mitre.org/techniques/T1078/001/"
91
92
93
94[rule.threat.tactic]
95id = "TA0001"
96name = "Initial Access"
97reference = "https://attack.mitre.org/tactics/TA0001/"
Triage and analysis
Disclaimer: 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.
Investigating Kubernetes Anonymous Request Authorized
Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse.
Possible investigation steps
- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request.
- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts.
- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity.
- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns.
- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.
False positive analysis
- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives.
- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts.
- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe.
- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.
- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases.
Response and remediation
- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.
- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.
- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.
- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.
- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.
- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future.
Setup
The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.
References
Related rules
- Potential Masquerading as Business App Installer
- Suspicious Explorer Child Process
- Suspicious MS Office Child Process
- Suspicious MS Outlook Child Process
- Command Execution via SolarWinds Process