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/decisionandaws.eks.audit.responseStatus.codeto determine whether the request was allowed or forbidden. An allowed request is a confirmed exposure. - Inspect
aws.eks.audit.requestObject.specfor 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, anduser_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:anonymousorsystem:unauthenticatedto 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:anonymousorsystem: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
- AWS EKS Forbidden Creation Request
- AWS EKS Forbidden Request from Unusual User Agent
- AWS EKS Pod Exec Potential Reverse Shell
- AWS EKS Pod Exec with Curl or Wget to HTTPS
- AWS EKS Unusual Decision by User Agent