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-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.
  • 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

to-top