AWS EKS Creation of a RoleBinding Referencing a ServiceAccount

  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 RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may
 13indicate privilege delegation or potential RBAC misconfiguration leading to elevated access.
 14"""
 15from = "now-6m"
 16index = ["logs-aws.eks_audit-*"]
 17language = "kuery"
 18license = "Elastic License v2"
 19name = "AWS EKS Creation of a RoleBinding Referencing a ServiceAccount"
 20note = """## Triage and analysis
 21
 22> **Disclaimer**:
 23> 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.
 24
 25### Investigating AWS EKS Creation of a RoleBinding Referencing a ServiceAccount
 26This rule detects creation of a RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, a common way to delegate access inside the cluster and a frequent precursor to stealthy privilege escalation or persistence. Attackers who gain the ability to create bindings often attach an over-privileged role (or cluster-wide role) to an existing ServiceAccount used by a workload, then use that workload’s token to operate with elevated rights without creating new user identities.
 27
 28### Possible investigation steps
 29
 30- Identify the principal that created the binding (user/service account), along with the source IP, user-agent, and authentication method, to determine whether it originated from an expected controller, CI/CD system, or a suspicious client.
 31- Review the new RoleBinding/ClusterRoleBinding’s `roleRef` and subjects to determine what permissions were granted, and assess blast radius by inspecting the referenced Role/ClusterRole rules for high-impact verbs/resources (e.g., secrets, pods/exec, nodes, RBAC).
 32- Determine where the referenced ServiceAccount is used by enumerating pods/deployments in the namespace that run under it, checking whether service account tokens are mounted, and whether this SA is associated with privileged workloads or externally reachable services.
 33- Correlate nearby audit activity for additional RBAC or identity changes (new roles, bindings, service accounts, token requests) and for follow-on actions performed using the ServiceAccount that indicate attempted privilege escalation or persistence.
 34- Validate the change against approved deployment/change records and, if unauthorized or overly permissive, remove/roll back the binding and rotate or invalidate the ServiceAccount credentials while tightening RBAC to least privilege.
 35
 36### False positive analysis
 37
 38- A cluster administrator or GitOps-driven deployment legitimately creates or updates RoleBindings/ClusterRoleBindings to grant a workload ServiceAccount the minimal permissions required for a new release, namespace onboarding, or routine RBAC refactoring.
 39- Kubernetes controllers or automation running under authorized identities (e.g., internal operators, admission policies, or namespace provisioning jobs) create bindings for default or system ServiceAccounts as part of standard cluster bootstrap, reconciliation, or multi-tenant namespace setup.
 40
 41### Response and remediation
 42
 43- Immediately fetch and snapshot the created RoleBinding/ClusterRoleBinding manifest, its referenced Role/ClusterRole, and recent Kubernetes audit events around the creator and the ServiceAccount to preserve evidence and establish scope.
 44- Contain potential misuse by deleting or scaling down workloads that use the referenced ServiceAccount and temporarily revoking the new binding (or applying an emergency deny policy via admission controls) until the change is validated.
 45- Eradicate unauthorized privilege delegation by removing the binding, replacing it with a least-privilege Role/RoleBinding scoped to the required namespace/resources, and rotating credentials by recreating the ServiceAccount or forcing token/key rotation for any dependent workloads.
 46- Recover safely by redeploying affected applications with the corrected RBAC, validating that required operations succeed without cluster-admin-equivalent rights, and monitoring for repeated binding creation or follow-on access to secrets, pod exec, or node-level resources.
 47- Escalate to platform security/incident response immediately if the binding references a high-privilege ClusterRole (e.g., cluster-admin), targets a broadly used ServiceAccount, or is followed by suspicious actions such as secret reads, new token requests, or pod exec sessions from the same identity.
 48- Harden by enforcing RBAC guardrails with admission policies that restrict who can create RoleBindings/ClusterRoleBindings and which roles may be referenced, disabling auto-mounting of service account tokens where not needed, and adopting GitOps-only RBAC changes with mandatory review."""
 49references = [
 50    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
 51]
 52risk_score = 47
 53rule_id = "ab4144ab-ca7c-5a62-b8bd-bfbd55093532"
 54setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
 55into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
 56pipelines normalize each audit record under `aws.eks.audit.*`.
 57
 58Enable the `audit` control-plane log type on the EKS cluster, send its
 59CloudWatch log group through the AWS integration, and confirm events carry
 60`data_stream.dataset: aws.eks_audit` and
 61`cloud.provider: aws` before enabling this rule.
 62"""
 63severity = "medium"
 64tags = [
 65    "Domain: Cloud",
 66    "Domain: Containers",
 67    "Platform: AWS",
 68    "Platform: Kubernetes",
 69    "Data Source: AWS",
 70    "Data Source: Amazon Web Services",
 71    "Data Source: Kubernetes API Server Audit Logs",
 72    "Service: AWS EKS",
 73    "Use Case: Threat Detection",
 74    "Tactic: Persistence",
 75    "Tactic: Privilege Escalation",
 76    "Rule Type: Custom Query (KQL)",
 77    "Resources: Investigation Guide",
 78    "Profile: Beta",
 79]
 80timestamp_override = "event.ingested"
 81type = "query"
 82
 83query = '''
 84data_stream.dataset: "aws.eks_audit" and aws.eks.audit.requestObject.subjects.kind:"ServiceAccount" and
 85aws.eks.audit.verb:"create" and aws.eks.audit.objectRef.resource:("rolebindings" or "clusterrolebindings") and
 86aws.eks.audit.annotations.authorization_k8s_io/decision:"allow"
 87'''
 88
 89
 90[[rule.threat]]
 91framework = "MITRE ATT&CK"
 92[[rule.threat.technique]]
 93id = "T1098"
 94name = "Account Manipulation"
 95reference = "https://attack.mitre.org/techniques/T1098/"
 96[[rule.threat.technique.subtechnique]]
 97id = "T1098.006"
 98name = "Additional Container Cluster Roles"
 99reference = "https://attack.mitre.org/techniques/T1098/006/"
100
101
102
103[rule.threat.tactic]
104id = "TA0003"
105name = "Persistence"
106reference = "https://attack.mitre.org/tactics/TA0003/"
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1098"
111name = "Account Manipulation"
112reference = "https://attack.mitre.org/techniques/T1098/"
113[[rule.threat.technique.subtechnique]]
114id = "T1098.006"
115name = "Additional Container Cluster Roles"
116reference = "https://attack.mitre.org/techniques/T1098/006/"
117
118
119
120[rule.threat.tactic]
121id = "TA0004"
122name = "Privilege Escalation"
123reference = "https://attack.mitre.org/tactics/TA0004/"