GKE Anonymous Request Authorized by Unusual User Agent

Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/16"
  3integration = ["gcp"]
  4maturity = "production"
  5updated_date = "2026/07/16"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent.
 11Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches
 12"system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for
 13unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded.
 14"""
 15false_positives = [
 16    """
 17    Anonymous API access is a dangerous default. Health probes are excluded; investigate all other authorized
 18    anonymous requests and disable anonymous authentication where possible.
 19    """,
 20]
 21from = "now-6m"
 22index = ["logs-gcp.audit-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "GKE Anonymous Request Authorized by Unusual User Agent"
 26note = """## Triage and analysis
 27
 28### Investigating GKE Anonymous Request Authorized by Unusual User Agent
 29
 30Anonymous success outside health endpoints can indicate a publicly reachable API server or overly permissive RBAC for
 31`system:anonymous` / `system:unauthenticated`. On GKE via GCP audit, some unauthenticated clients omit
 32`client.user.email`; those successes are included when the user agent is unusual.
 33
 34### Investigation steps
 35
 36- Review `client.user.email`, `event.action`, `gcp.audit.resource_name`, `source.ip`, and `user_agent.original`.
 37- Confirm whether the API server is Internet-exposed and whether anonymous auth is intentionally enabled.
 38- Hunt for follow-on anonymous pod mutations, secret reads, or RBAC changes from the same source.
 39
 40### False positives
 41
 42- Custom health or readiness endpoints not covered by the built-in exclusions; add environment-specific exceptions after review.
 43
 44"""
 45references = [
 46    "https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF",
 47    "https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging",
 48]
 49risk_score = 47
 50rule_id = "189f0f31-8f31-48eb-bb3e-c0db8c8b8c4c"
 51severity = "medium"
 52tags = [
 53    "Domain: Cloud",
 54    "Domain: Kubernetes",
 55    "Data Source: GCP",
 56    "Data Source: Google Cloud Platform",
 57    "Use Case: Threat Detection",
 58    "Tactic: Initial Access",
 59    "Tactic: Defense Evasion",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "new_terms"
 64setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
 65
 66query = '''
 67data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and user_agent.original:(* and not (*kubernetes/$Format or kube-probe*)) and not gcp.audit.resource_name:(healthz or livez or readyz or version or .well-known*)
 68'''
 69
 70[rule.new_terms]
 71field = "new_terms_fields"
 72value = ["user_agent.original"]
 73
 74[[rule.new_terms.history_window_start]]
 75field = "history_window_start"
 76value = "now-7d"
 77
 78[[rule.threat]]
 79framework = "MITRE ATT&CK"
 80
 81[[rule.threat.technique]]
 82id = "T1078"
 83name = "Valid Accounts"
 84reference = "https://attack.mitre.org/techniques/T1078/"
 85
 86[[rule.threat.technique.subtechnique]]
 87id = "T1078.001"
 88name = "Default Accounts"
 89reference = "https://attack.mitre.org/techniques/T1078/001/"
 90
 91[rule.threat.tactic]
 92id = "TA0001"
 93name = "Initial Access"
 94reference = "https://attack.mitre.org/tactics/TA0001/"
 95
 96[rule.investigation_fields]
 97field_names = [
 98    "@timestamp",
 99    "client.user.email",
100    "source.ip",
101    "user_agent.original",
102    "event.action",
103    "event.outcome",
104    "gcp.audit.resource_name",
105    "orchestrator.resource.name",
106    "orchestrator.namespace",
107]

Triage and analysis

Investigating GKE Anonymous Request Authorized by Unusual User Agent

Anonymous success outside health endpoints can indicate a publicly reachable API server or overly permissive RBAC for system:anonymous / system:unauthenticated. On GKE via GCP audit, some unauthenticated clients omit client.user.email; those successes are included when the user agent is unusual.

Investigation steps

  • Review client.user.email, event.action, gcp.audit.resource_name, source.ip, and user_agent.original.
  • Confirm whether the API server is Internet-exposed and whether anonymous auth is intentionally enabled.
  • Hunt for follow-on anonymous pod mutations, secret reads, or RBAC changes from the same source.

False positives

  • Custom health or readiness endpoints not covered by the built-in exclusions; add environment-specific exceptions after review.

References

Related rules

to-top