AWS EKS Anonymous User Create/Update/Patch Pods Request

This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common activity for attackers to gain access to the cluster and execute commands.

Elastic rule (View on GitHub)

  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 attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is
 13not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common
 14activity for attackers to gain access to the cluster and execute commands.
 15"""
 16from = "now-6m"
 17index = ["logs-aws.eks_audit-*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "AWS EKS Anonymous User Create/Update/Patch Pods Request"
 21note = """## Triage and analysis
 22
 23### Investigating AWS EKS Anonymous User Create/Update/Patch Pods Request
 24
 25This rule fires when the EKS API server records a `create`, `update`, or `patch` request against the `pods` resource
 26from the anonymous identity (`system:anonymous` or the `system:unauthenticated` group), directly or through
 27impersonation. Anonymous access to the Kubernetes API is disabled by default on EKS, and the anonymous identity should
 28never be able to write workloads. A matching event indicates either a misconfigured RoleBinding or ClusterRoleBinding
 29that grants pod write access to anonymous callers, or an attacker exploiting such a binding to run a container in the
 30cluster.
 31
 32### Possible investigation steps
 33
 34- Review `aws.eks.audit.annotations.authorization_k8s_io/decision` and `aws.eks.audit.responseStatus.code` to
 35  determine whether the request was allowed or forbidden. An allowed request is a confirmed exposure.
 36- Inspect `aws.eks.audit.requestObject.spec` for the pod definition: image, command, privileged settings, host
 37  namespaces, hostPath volumes, and the service account the pod would run as.
 38- Identify the client from `source.ip`, `aws.eks.audit.sourceIPs`, and `user_agent.original`, and check whether the
 39  address is inside the VPC or external.
 40- Search the audit log for other anonymous activity from the same source around the alert, such as discovery requests,
 41  secret reads, or exec into the created pod.
 42- Review RoleBindings and ClusterRoleBindings that reference `system:anonymous` or `system:unauthenticated` to find
 43  the binding that permitted the request, and check the cluster endpoint access configuration.
 44
 45### False positive analysis
 46
 47- Security scanners or penetration tests that probe anonymous access may generate forbidden requests. Confirm the
 48  source and schedule, and scope the rule or an exception to the testing window and source addresses.
 49
 50### Response and remediation
 51
 52- If the request was allowed, treat the cluster as compromised: delete or quarantine the created or modified pod,
 53  capture its image and spec for analysis, and review what it accessed.
 54- Remove any binding that grants write permissions to `system:anonymous` or `system:unauthenticated`, and restrict the
 55  cluster endpoint to private access or an allowlist of CIDR ranges.
 56- Rotate secrets and service account tokens reachable from the affected namespace, and review node and IAM activity
 57  for follow-on access.
 58"""
 59risk_score = 47
 60rule_id = "f45ce149-3f1f-5788-b07a-926a8d82dd15"
 61setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 62into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 63pipelines normalize each audit record under `aws.eks.audit.*`.
 64
 65Enable the `audit` control-plane log type on the EKS cluster, send its
 66CloudWatch log group through the AWS integration, and confirm events carry
 67`data_stream.dataset: aws.eks_audit` and
 68`cloud.provider: aws` before enabling this rule.
 69"""
 70severity = "medium"
 71tags = [
 72    "Domain: Cloud",
 73    "Domain: Containers",
 74    "Platform: AWS",
 75    "Platform: Kubernetes",
 76    "Data Source: AWS",
 77    "Data Source: Amazon Web Services",
 78    "Data Source: Kubernetes API Server Audit Logs",
 79    "Service: AWS EKS",
 80    "Use Case: Threat Detection",
 81    "Tactic: Execution",
 82    "Rule Type: Event Correlation (EQL)",
 83    "Resources: Investigation Guide",
 84    "Profile: Beta",
 85]
 86timestamp_override = "event.ingested"
 87type = "eql"
 88
 89query = '''
 90any where data_stream.dataset == "aws.eks_audit" and (
 91    aws.eks.audit.user.username in ("system:anonymous", "system:unauthenticated") or
 92    aws.eks.audit.impersonatedUser.username in ("system:anonymous", "system:unauthenticated") or
 93    aws.eks.audit.user.username == null or
 94    aws.eks.audit.user.username == ""
 95  ) and aws.eks.audit.level in ("RequestResponse", "ResponseComplete", "Request") and aws.eks.audit.verb in ("create", "update", "patch") and
 96aws.eks.audit.objectRef.resource == "pods"
 97'''
 98
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102[[rule.threat.technique]]
103id = "T1610"
104name = "Deploy Container"
105reference = "https://attack.mitre.org/techniques/T1610/"
106
107
108[rule.threat.tactic]
109id = "TA0002"
110name = "Execution"
111reference = "https://attack.mitre.org/tactics/TA0002/"

Triage and analysis

Investigating AWS EKS Anonymous User Create/Update/Patch Pods Request

This rule fires when the EKS API server records a create, update, or patch request against the pods resource from the anonymous identity (system:anonymous or the system:unauthenticated group), directly or through impersonation. Anonymous access to the Kubernetes API is disabled by default on EKS, and the anonymous identity should never be able to write workloads. A matching event indicates either a misconfigured RoleBinding or ClusterRoleBinding that grants pod write access to anonymous callers, or an attacker exploiting such a binding to run a container in the cluster.

Possible investigation steps

  • Review aws.eks.audit.annotations.authorization_k8s_io/decision and aws.eks.audit.responseStatus.code to determine whether the request was allowed or forbidden. An allowed request is a confirmed exposure.
  • Inspect aws.eks.audit.requestObject.spec for the pod definition: image, command, privileged settings, host namespaces, hostPath volumes, and the service account the pod would run as.
  • Identify the client from source.ip, aws.eks.audit.sourceIPs, and user_agent.original, and check whether the address is inside the VPC or external.
  • Search the audit log for other anonymous activity from the same source around the alert, such as discovery requests, secret reads, or exec into the created pod.
  • Review RoleBindings and ClusterRoleBindings that reference system:anonymous or system:unauthenticated to find the binding that permitted the request, and check the cluster endpoint access configuration.

False positive analysis

  • Security scanners or penetration tests that probe anonymous access may generate forbidden requests. Confirm the source and schedule, and scope the rule or an exception to the testing window and source addresses.

Response and remediation

  • If the request was allowed, treat the cluster as compromised: delete or quarantine the created or modified pod, capture its image and spec for analysis, and review what it accessed.
  • Remove any binding that grants write permissions to system:anonymous or system:unauthenticated, and restrict the cluster endpoint to private access or an allowlist of CIDR ranges.
  • Rotate secrets and service account tokens reachable from the affected namespace, and review node and IAM activity for follow-on access.

Related rules

to-top