Kubernetes Service Account Modified RBAC Objects

  1[metadata]
  2creation_date = "2026/02/04"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/02/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles,
 11ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC
 12directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized
 13privilege escalation.
 14"""
 15index = ["logs-kubernetes.audit_logs-*"]
 16language = "kuery"
 17license = "Elastic License v2"
 18name = "Kubernetes Service Account Modified RBAC Objects"
 19note = """ ## Triage and analysis
 20
 21> **Disclaimer**:
 22> 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.
 23
 24### Investigating Kubernetes Service Account Modified RBAC Objects
 25
 26This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control.
 27
 28### Possible investigation steps
 29
 30- Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions.
 31- Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators.
 32- Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests.
 33- Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior.
 34- Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege.
 35
 36### False positive analysis
 37
 38- A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings.  
 39- A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources.
 40
 41### Response and remediation
 42
 43- Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes.  
 44- Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or `kubectl rollout undo` where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access.  
 45- Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused.  
 46- Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors.  
 47- Escalate to incident response and cluster administrators immediately if any change grants `cluster-admin`, introduces `*` verbs/resources, or binds a service account to privileged ClusterRoles across namespaces.  
 48- Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints.
 49"""
 50references = [
 51    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
 52]
 53risk_score = 47
 54rule_id = "f2e21713-1eac-4908-a782-1b49c7e9d53b"
 55severity = "medium"
 56tags = [
 57    "Data Source: Kubernetes",
 58    "Domain: Kubernetes",
 59    "Use Case: Threat Detection",
 60    "Tactic: Privilege Escalation",
 61    "Tactic: Persistence",
 62    "Resources: Investigation Guide",
 63]
 64timestamp_override = "event.ingested"
 65type = "query"
 66query = '''
 67event.dataset:"kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
 68kubernetes.audit.user.username:(
 69  system\:serviceaccount\:* and not (
 70    "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or
 71    "system:serviceaccount:kube-system:generic-garbage-collector"
 72  )
 73) and
 74kubernetes.audit.objectRef.resource:("clusterrolebindings" or "clusterroles" or "rolebindings" or "roles") and
 75kubernetes.audit.verb:("create" or "delete" or "patch" or "update")
 76'''
 77
 78[[rule.threat]]
 79framework = "MITRE ATT&CK"
 80
 81[[rule.threat.technique]]
 82id = "T1098"
 83name = "Account Manipulation"
 84reference = "https://attack.mitre.org/techniques/T1098/"
 85
 86[[rule.threat.technique.subtechnique]]
 87id = "T1098.006"
 88name = "Additional Container Cluster Roles"
 89reference = "https://attack.mitre.org/techniques/T1098/006/"
 90
 91[rule.threat.tactic]
 92id = "TA0004"
 93name = "Privilege Escalation"
 94reference = "https://attack.mitre.org/tactics/TA0004/"
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98
 99[[rule.threat.technique]]
100id = "T1098"
101name = "Account Manipulation"
102reference = "https://attack.mitre.org/techniques/T1098/"
103
104[[rule.threat.technique.subtechnique]]
105id = "T1098.006"
106name = "Additional Container Cluster Roles"
107reference = "https://attack.mitre.org/techniques/T1098/006/"
108
109[rule.threat.tactic]
110id = "TA0003"
111name = "Persistence"
112reference = "https://attack.mitre.org/tactics/TA0003/"