AWS EKS RBAC Wildcard Elevation on Existing Role

Flags an existing Role or ClusterRole being changed (patch or update) to a wildcard on every API resource and verb. This may be indicative of a deliberate privilege expansion but may also be a nefarious attempt at privilege escalation.

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 = """
 12Flags an existing Role or ClusterRole being changed (patch or update) to a wildcard on every API resource and verb. This
 13may be indicative of a deliberate privilege expansion but may also be a nefarious attempt at privilege escalation.
 14"""
 15false_positives = [
 16    """
 17    Platform installers, GitOps controllers, and emergency break-glass roles sometimes ship or widen wildcard
 18    ClusterRoles; correlate with change records and narrow by user or service account when baselined.
 19    """,
 20]
 21from = "now-9m"
 22language = "esql"
 23license = "Elastic License v2"
 24name = "AWS EKS RBAC Wildcard Elevation on Existing Role"
 25note = """## Triage and analysis
 26
 27### Investigating AWS EKS RBAC Wildcard Elevation on Existing Role
 28Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near
 29cluster-admin breadth on that scope. Confirm the actor (user, group, impersonation), client, and non-loopback source
 30IP; then see who can bind that role.
 31
 32### Possible investigation steps
 33
 34- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects
 35  gained the widened access.
 36- In the same window, check secret reads, exec, and further RBAC changes from the same identity.
 37
 38### False positive analysis
 39
 40- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.
 41
 42### Response and remediation
 43
 44- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside
 45  governed pipelines (policy-as-code, PR-only RBAC)."""
 46references = ["https://kubernetes.io/docs/reference/access-authn-authz/rbac/"]
 47risk_score = 73
 48rule_id = "af625960-3595-5008-ad7b-7ed2a11becda"
 49setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 50into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 51pipelines normalize each audit record under `aws.eks.audit.*`.
 52
 53Enable the `audit` control-plane log type on the EKS cluster, send its
 54CloudWatch log group through the AWS integration, and confirm events carry
 55`data_stream.dataset: aws.eks_audit` and
 56`cloud.provider: aws` before enabling this rule.
 57"""
 58severity = "high"
 59tags = [
 60    "Domain: Cloud",
 61    "Domain: Containers",
 62    "Platform: AWS",
 63    "Platform: Kubernetes",
 64    "Data Source: AWS",
 65    "Data Source: Amazon Web Services",
 66    "Data Source: Kubernetes API Server Audit Logs",
 67    "Service: AWS EKS",
 68    "Use Case: Threat Detection",
 69    "Tactic: Privilege Escalation",
 70    "Rule Type: ES|QL",
 71    "Resources: Investigation Guide",
 72    "Profile: Beta",
 73]
 74timestamp_override = "event.ingested"
 75type = "esql"
 76
 77query = '''
 78from logs-aws.eks_audit-* metadata _id, _index, _version
 79| where
 80  aws.eks.audit.objectRef.resource in ("roles", "clusterroles") and
 81  aws.eks.audit.verb in ("update", "patch") and
 82  `aws.eks.audit.annotations.authorization_k8s_io/decision` == "allow" and
 83  aws.eks.audit.level == "RequestResponse" and
 84  aws.eks.audit.stage == "ResponseComplete" and
 85  aws.eks.audit.sourceIPs is not null and
 86  not aws.eks.audit.sourceIPs in ("::1", "127.0.0.1") and
 87  KQL(""" aws.eks.audit.responseObject.rules.verbs:"*" and aws.eks.audit.responseObject.rules.resources:"*" """)
 88| keep user.name, user_agent.original, event.action, source.ip, aws.eks.audit.verb, aws.eks.audit.objectRef.resource, aws.eks.audit.objectRef.name, aws.eks.audit.requestURI, aws.eks.audit.user.username, aws.eks.audit.user.groups, `aws.eks.audit.annotations.authorization_k8s_io/decision`, event.original, _id, _version, _index, data_stream.namespace
 89'''
 90
 91
 92[[rule.threat]]
 93framework = "MITRE ATT&CK"
 94[[rule.threat.technique]]
 95id = "T1098"
 96name = "Account Manipulation"
 97reference = "https://attack.mitre.org/techniques/T1098/"
 98[[rule.threat.technique.subtechnique]]
 99id = "T1098.006"
100name = "Additional Container Cluster Roles"
101reference = "https://attack.mitre.org/techniques/T1098/006/"
102
103
104
105[rule.threat.tactic]
106id = "TA0004"
107name = "Privilege Escalation"
108reference = "https://attack.mitre.org/tactics/TA0004/"

Triage and analysis

Investigating AWS EKS RBAC Wildcard Elevation on Existing Role

Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near cluster-admin breadth on that scope. Confirm the actor (user, group, impersonation), client, and non-loopback source IP; then see who can bind that role.

Possible investigation steps

  • Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects gained the widened access.
  • In the same window, check secret reads, exec, and further RBAC changes from the same identity.

False positive analysis

  • Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.

Response and remediation

  • Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside governed pipelines (policy-as-code, PR-only RBAC).

References

Related rules

to-top