AWS EKS Anonymous Request Authorized by Unusual User Agent

  1[metadata]
  2creation_date = "2026/08/03"
  3integration = ["aws"]
  4maturity = "production"
  5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
  6min_stack_version = "9.6.0"
  7updated_date = "2026/10/21"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent.
 13Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their
 14activities within the cluster. This rule excludes the /healthz, /livez, /version and
 15/.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously.
 16"""
 17false_positives = [
 18    """
 19    Anonymous access to the API server is a dangerous setting enabled by default. Common anonymous connections (e.g.,
 20    health checks) have been excluded from this rule. All other instances of authorized anonymous requests should be
 21    investigated.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-aws.eks_audit-*"]
 26language = "kuery"
 27license = "Elastic License v2"
 28name = "AWS EKS Anonymous Request Authorized by Unusual User Agent"
 29note = """## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating AWS EKS Anonymous Request Authorized by Unusual User Agent
 35Kubernetes, 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.
 36
 37### Possible investigation steps
 38
 39- Review the audit logs for the specific event.dataset:aws.eks_audit to identify the context and details of the anonymous request.
 40- Examine the aws.eks.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.
 41- Analyze the aws.eks.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.
 42- 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.
 43- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster.
 44
 45### False positive analysis
 46
 47- 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.
 48- 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.
 49- 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.
 50- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise.
 51- 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.
 52
 53### Response and remediation
 54
 55- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary.
 56- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized.
 57- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster.
 58- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access.
 59- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users.
 60- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
 61- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future."""
 62references = [
 63    "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF",
 64]
 65risk_score = 47
 66rule_id = "08cf729b-3e3c-5508-bcba-974cea74413e"
 67setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 68into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 69pipelines normalize each audit record under `aws.eks.audit.*`.
 70
 71Enable the `audit` control-plane log type on the EKS cluster, send its
 72CloudWatch log group through the AWS integration, and confirm events carry
 73`data_stream.dataset: aws.eks_audit` and
 74`cloud.provider: aws` before enabling this rule.
 75"""
 76severity = "medium"
 77tags = [
 78    "Domain: Cloud",
 79    "Domain: Containers",
 80    "Platform: AWS",
 81    "Platform: Kubernetes",
 82    "Data Source: AWS",
 83    "Data Source: Amazon Web Services",
 84    "Data Source: Kubernetes API Server Audit Logs",
 85    "Service: AWS EKS",
 86    "Use Case: Threat Detection",
 87    "Tactic: Initial Access",
 88    "Rule Type: New Terms",
 89    "Resources: Investigation Guide",
 90    "Profile: Beta",
 91]
 92timestamp_override = "event.ingested"
 93type = "new_terms"
 94
 95query = '''
 96data_stream.dataset:"aws.eks_audit" and
 97aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
 98(aws.eks.audit.user.username:("system:anonymous" or "system:unauthenticated") or
 99aws.eks.audit.impersonatedUser.username:("system:anonymous" or "system:unauthenticated")) and
100user_agent.original:(* and not (*kubernetes/$Format)) and
101not aws.eks.audit.requestURI:(/healthz* or /livez* or /readyz* or /version)
102'''
103
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107[[rule.threat.technique]]
108id = "T1078"
109name = "Valid Accounts"
110reference = "https://attack.mitre.org/techniques/T1078/"
111[[rule.threat.technique.subtechnique]]
112id = "T1078.001"
113name = "Default Accounts"
114reference = "https://attack.mitre.org/techniques/T1078/001/"
115
116
117
118[rule.threat.tactic]
119id = "TA0001"
120name = "Initial Access"
121reference = "https://attack.mitre.org/tactics/TA0001/"
122
123[rule.new_terms]
124field = "new_terms_fields"
125value = ["user_agent.original"]
126[[rule.new_terms.history_window_start]]
127field = "history_window_start"
128value = "now-7d"