AWS EKS Cluster-Admin Role Binding Created

  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 the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which
 13provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or
 14misconfiguration.
 15"""
 16from = "now-6m"
 17index = ["logs-aws.eks_audit-*"]
 18language = "kuery"
 19license = "Elastic License v2"
 20name = "AWS EKS Cluster-Admin Role Binding Created"
 21note = """## Triage and analysis
 22
 23> **Disclaimer**:
 24> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 25
 26### Investigating AWS EKS Cluster-Admin Role Binding Created
 27This rule flags when someone creates a RoleBinding or ClusterRoleBinding that assigns the cluster-admin role, which grants unrestricted control over every Kubernetes resource and enables rapid privilege escalation or persistence. Attackers often abuse a stolen namespace service account to bind it to cluster-admin, then pivot to read secrets, change security controls, or deploy a privileged DaemonSet across all nodes to maintain control.
 28
 29### Possible investigation steps
 30
 31- Identify who created the binding by reviewing the audit event user identity, groups, source IP, and user agent, and confirm whether it matches an approved admin workflow or automation.
 32- Inspect the created RoleBinding or ClusterRoleBinding to determine which subject received cluster-admin, whether it targets a service account or external identity, and whether the subject is expected to have cluster-wide privileges.
 33- Correlate the creator and bound subject with recent authentication events and credential changes to spot compromised accounts, unusual access locations, or use of long-lived tokens.
 34- Review subsequent Kubernetes audit activity from the same actor or newly privileged subject for rapid follow-on actions such as listing secrets, creating privileged pods/daemonsets, modifying RBAC, or disabling admission controls.
 35- Validate the change against change management records and repository-based RBAC manifests, and if unauthorized, assess scope by enumerating other recent privileged RBAC grants created around the same time.
 36
 37### False positive analysis
 38
 39- A cluster bootstrap, upgrade, or recovery workflow legitimately creates or re-creates a ClusterRoleBinding/RoleBinding to `cluster-admin` for a break-glass admin user or core control-plane service account as part of restoring expected RBAC state.
 40- An approved operational change temporarily grants `cluster-admin` to a namespace service account or automation identity to perform broad maintenance tasks (e.g., installing cluster-scoped resources), and the binding creation is captured during the allowed change window.
 41
 42### Response and remediation
 43
 44- Immediately identify and delete or edit the newly created RoleBinding/ClusterRoleBinding granting `cluster-admin`, then revoke the bound subject’s access by rotating the affected service account token or disabling the implicated user/identity provider account.
 45- Quarantine likely-abused workloads by scaling down or deleting pods/deployments created by the newly privileged subject and blocking its network access with namespace isolation policies while you preserve relevant audit logs and YAML manifests.
 46- Enumerate and undo follow-on changes made after the binding creation, including additional RBAC grants, new cluster-scoped resources (CRDs, webhooks), privileged DaemonSets, secret reads, or changes to admission controllers, and rotate any exposed credentials found in Secrets.
 47- Recover by restoring RBAC and critical cluster resources from GitOps or known-good backups, then re-apply least-privilege roles and validate access with `kubectl auth can-i` for impacted identities and namespaces.
 48- Escalate to incident response leadership immediately if the binding targets a service account, an external identity not in the admin group, or if there is evidence of secret access, privileged workload creation, or persistence mechanisms (e.g., new webhooks or DaemonSets).
 49- Harden by enforcing RBAC via GitOps-only change control, restricting `cluster-admin` binding creation with admission policy (ValidatingAdmissionPolicy/Kyverno/OPA Gatekeeper), requiring MFA and short-lived tokens for admins, and alerting on any creation or modification of cluster-wide RBAC bindings."""
 50references = [
 51    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
 52]
 53risk_score = 47
 54rule_id = "dc6bae24-10f3-5e85-a1b4-691454942862"
 55setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 56into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 57pipelines normalize each audit record under `aws.eks.audit.*`.
 58
 59Enable the `audit` control-plane log type on the EKS cluster, send its
 60CloudWatch log group through the AWS integration, and confirm events carry
 61`data_stream.dataset: aws.eks_audit` and
 62`cloud.provider: aws` before enabling this rule.
 63"""
 64severity = "medium"
 65tags = [
 66    "Domain: Cloud",
 67    "Domain: Containers",
 68    "Platform: AWS",
 69    "Platform: Kubernetes",
 70    "Data Source: AWS",
 71    "Data Source: Amazon Web Services",
 72    "Data Source: Kubernetes API Server Audit Logs",
 73    "Service: AWS EKS",
 74    "Use Case: Threat Detection",
 75    "Tactic: Persistence",
 76    "Tactic: Privilege Escalation",
 77    "Rule Type: Custom Query (KQL)",
 78    "Resources: Investigation Guide",
 79    "Profile: Beta",
 80]
 81timestamp_override = "event.ingested"
 82type = "query"
 83
 84query = '''
 85data_stream.dataset: "aws.eks_audit" and aws.eks.audit.objectRef.resource:("clusterrolebindings" or "rolebindings") and
 86aws.eks.audit.verb:"create" and aws.eks.audit.requestObject.roleRef.name:"cluster-admin" and
 87aws.eks.audit.annotations.authorization_k8s_io/decision:"allow" and
 88aws.eks.audit.level:"RequestResponse" and aws.eks.audit.stage:"ResponseComplete"
 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 = "TA0003"
107name = "Persistence"
108reference = "https://attack.mitre.org/tactics/TA0003/"
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1098"
113name = "Account Manipulation"
114reference = "https://attack.mitre.org/techniques/T1098/"
115[[rule.threat.technique.subtechnique]]
116id = "T1098.006"
117name = "Additional Container Cluster Roles"
118reference = "https://attack.mitre.org/techniques/T1098/006/"
119
120
121
122[rule.threat.tactic]
123id = "TA0004"
124name = "Privilege Escalation"
125reference = "https://attack.mitre.org/tactics/TA0004/"