AWS EKS API Request Impersonating Privileged Identity
Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement.
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/20"
8
9[rule]
10author = ["Elastic"]
11description = """
12Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as
13system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These
14identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create
15tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating
16system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants
17access to every secret in every namespace and the ability to mint service account tokens for lateral movement.
18"""
19false_positives = [
20 """
21 Break-glass admin tooling, security scanners, or approved controllers that legitimately use impersonation with
22 privileged targets may match if not covered by exclusions. Map expected callers and expand `not user.name` filters
23 as needed for your environment.
24 """,
25]
26from = "now-9m"
27index = ["logs-aws.eks_audit-*"]
28language = "kuery"
29license = "Elastic License v2"
30name = "AWS EKS API Request Impersonating Privileged Identity"
31note = """## Triage and analysis
32
33### Investigating AWS EKS API Request Impersonating Privileged Identity
34Compare the real actor (user.name, groups, source.ip, user_agent.original) with impersonated
35fields (aws.eks.audit.impersonatedUser.username, aws.eks.audit.impersonatedUser.groups). Confirm whether
36impersonation is authorized for that principal and target identity.
37
38### Possible investigation steps
39
40- Review aws.eks.audit.requestURI, aws.eks.audit.verb, and aws.eks.audit.objectRef for the scope of the
41 operation performed while impersonating.
42- Determine whether the real user or service account should have impersonate rights against the impersonated user
43 or group; inspect RBAC impersonate verb bindings and any recent changes.
44- Correlate with adjacent audit activity (secrets, tokens, RBAC writes, CSR approval) from the same source identity.
45- Hunt for repeated impersonation across namespaces or rapid pivoting after the event.
46
47### False positive analysis
48
49- Cluster administrators legitimately use `kubectl --as` / `--as-group` to test RBAC policies or reproduce a user's view of the cluster. Confirm the real actor is an authorized administrator and the activity aligns with a change or support ticket.
50- Platform tooling such as GitOps controllers, policy engines, multi-tenancy proxies, or identity brokers may impersonate privileged identities by design. If the real actor is a known controller identity, consider adding a scoped exception on user.name rather than on the impersonated identity.
51- EKS control-plane components already excluded in the query (eks:*, eks-event-service, service-linked roles) should not fire; if they do, verify the identity format rather than widening the exclusion.
52
53### Response and remediation
54
55- Revoke or tighten impersonate permissions for unexpected identities; rotate credentials for any account that may
56 have abused impersonation.
57- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift;
58 engage incident response per policy."""
59references = ["https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation"]
60risk_score = 73
61rule_id = "292f6a8c-9b61-5fca-b7d1-9a4b42e4bc43"
62setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
63into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
64pipelines normalize each audit record under `aws.eks.audit.*`.
65
66Enable the `audit` control-plane log type on the EKS cluster, send its
67CloudWatch log group through the AWS integration, and confirm events carry
68`data_stream.dataset: aws.eks_audit` and
69`cloud.provider: aws` before enabling this rule.
70"""
71severity = "high"
72tags = [
73 "Domain: Cloud",
74 "Domain: Containers",
75 "Platform: AWS",
76 "Platform: Kubernetes",
77 "Data Source: AWS",
78 "Data Source: Amazon Web Services",
79 "Data Source: Kubernetes API Server Audit Logs",
80 "Service: AWS EKS",
81 "Use Case: Threat Detection",
82 "Tactic: Privilege Escalation",
83 "Tactic: Defense Evasion",
84 "Rule Type: Custom Query (KQL)",
85 "Resources: Investigation Guide",
86 "Profile: Beta",
87]
88timestamp_override = "event.ingested"
89type = "query"
90
91query = '''
92data_stream.dataset:aws.eks_audit and
93aws.eks.audit.impersonatedUser.username:(* and not ("eks-event-service:event-controller" or eks\:*)) and
94aws.eks.audit.annotations.authorization_k8s_io/decision:allow and
95aws.eks.audit.verb:(create or delete or get or list or patch or update) and
96(aws.eks.audit.impersonatedUser.username:(admin or cluster-admin or kubernetes-admin or "system:admin" or "system:anonymous" or "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or "system:kube-scheduler" or "system:volume-scheduler" or system\:node\:* or system\:serviceaccount\:kube-system\:*) or aws.eks.audit.impersonatedUser.groups:(cluster-admin or "system:cluster-admins" or "system:masters")) and
97not user.name:("system:kube-controller-manager" or "system:kube-scheduler" or arn\:aws\:iam\:*\:role/aws-service-role* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKS* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKSNodegroup* or eks\:* or system\:node\:* or system\:serviceaccount\:kube-system\:*)
98'''
99
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103[[rule.threat.technique]]
104id = "T1134"
105name = "Access Token Manipulation"
106reference = "https://attack.mitre.org/techniques/T1134/"
107
108
109[rule.threat.tactic]
110id = "TA0004"
111name = "Privilege Escalation"
112reference = "https://attack.mitre.org/tactics/TA0004/"
113[[rule.threat]]
114framework = "MITRE ATT&CK"
115[[rule.threat.technique]]
116id = "T1134"
117name = "Access Token Manipulation"
118reference = "https://attack.mitre.org/techniques/T1134/"
119
120
121[rule.threat.tactic]
122id = "TA0005"
123name = "Defense Evasion"
124reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating AWS EKS API Request Impersonating Privileged Identity
Compare the real actor (user.name, groups, source.ip, user_agent.original) with impersonated fields (aws.eks.audit.impersonatedUser.username, aws.eks.audit.impersonatedUser.groups). Confirm whether impersonation is authorized for that principal and target identity.
Possible investigation steps
- Review aws.eks.audit.requestURI, aws.eks.audit.verb, and aws.eks.audit.objectRef for the scope of the operation performed while impersonating.
- Determine whether the real user or service account should have impersonate rights against the impersonated user or group; inspect RBAC impersonate verb bindings and any recent changes.
- Correlate with adjacent audit activity (secrets, tokens, RBAC writes, CSR approval) from the same source identity.
- Hunt for repeated impersonation across namespaces or rapid pivoting after the event.
False positive analysis
- Cluster administrators legitimately use
kubectl --as/--as-groupto test RBAC policies or reproduce a user's view of the cluster. Confirm the real actor is an authorized administrator and the activity aligns with a change or support ticket. - Platform tooling such as GitOps controllers, policy engines, multi-tenancy proxies, or identity brokers may impersonate privileged identities by design. If the real actor is a known controller identity, consider adding a scoped exception on user.name rather than on the impersonated identity.
- EKS control-plane components already excluded in the query (eks:*, eks-event-service, service-linked roles) should not fire; if they do, verify the identity format rather than widening the exclusion.
Response and remediation
- Revoke or tighten impersonate permissions for unexpected identities; rotate credentials for any account that may have abused impersonation.
- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift; engage incident response per policy.
References
Related rules
- AWS EKS Container Created with Excessive Linux Capabilities
- AWS EKS API Server Proxying Request to Kubelet
- AWS EKS Ephemeral Container Added to Pod
- AWS EKS Pod Created With HostIPC
- AWS EKS Pod Created With HostNetwork