Kubernetes Sensitive RBAC Change Followed by Workload Modification

  1[metadata]
  2creation_date = "2026/02/04"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/02/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions
 11(e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet,
 12Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload
 13deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and
 14deploy malicious payloads.
 15"""
 16index = ["logs-kubernetes.audit_logs-*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Kubernetes Sensitive RBAC Change Followed by Workload Modification"
 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 Kubernetes Sensitive RBAC Change Followed by Workload Modification
 26
 27This rule detects when a user grants or broadens high-risk permissions in a Role/ClusterRole and then quickly creates or patches a DaemonSet, Deployment, or CronJob, a strong signal of RBAC-driven privilege escalation followed by payload deployment. Attackers often add wildcard access or escalation verbs to a new role, bind it to their identity, then patch a workload to run a malicious container across nodes or on a schedule to establish persistence.
 28
 29### Possible investigation steps
 30
 31- Review the Role/ClusterRole change diff to identify newly granted wildcard resources/verbs or escalation permissions (e.g., bind, impersonate, escalate) and determine the effective access increase for the actor.
 32- Identify any RoleBinding/ClusterRoleBinding creations or updates around the same time to see whether the modified role was bound to the same principal or a newly created service account.
 33- Inspect the subsequent DaemonSet/Deployment/CronJob spec changes for malicious indicators such as new images, added initContainers, elevated securityContext (privileged/hostPID/hostNetwork), hostPath mounts, or suspicious command/args.
 34- Correlate pod runtime activity from the modified workload (image pulls, container starts, outbound connections, and access to secrets/configmaps) to confirm execution and scope of impact.
 35- Validate the actor’s legitimacy by checking whether the request originated from expected IP/user-agent and whether the identity is associated with approved CI/CD automation or an unusual interactive session.
 36
 37### False positive analysis
 38
 39- A platform engineer performing an urgent, legitimate RBAC adjustment (e.g., expanding a Role/ClusterRole for a new feature rollout) and then immediately patching or deploying a DaemonSet/Deployment/CronJob as part of the same change window can match this sequence.  
 40- A CI/CD pipeline or GitOps-style workflow using a non-system:masters identity may update RBAC manifests and then apply workload updates within minutes during routine releases, producing this pattern without malicious intent.
 41
 42### Response and remediation
 43
 44- Immediately revoke or roll back the risky Role/ClusterRole changes and remove any new/updated RoleBinding/ClusterRoleBinding that ties the elevated permissions to the triggering user or service account.  
 45- Quarantine the modified Deployment/DaemonSet/CronJob by scaling it to zero or deleting it and cordon/drain affected nodes if pods ran privileged, used hostPath mounts, or executed on many nodes.  
 46- Rotate credentials and access paths exposed through the workload (service account tokens, kubeconfig files, mounted secrets, cloud keys) and invalidate any newly issued tokens tied to the actor.  
 47- For eradication and recovery, redeploy workloads from trusted Git/registry sources, block the suspicious images/digests in admission controls, and verify no persistence remains via CronJobs, DaemonSets, webhook configurations, or additional RBAC bindings.  
 48- Escalate to incident response and platform leadership if the RBAC change included wildcard permissions or escalation verbs, if the workload ran privileged/hostNetwork/hostPID, or if sensitive secrets were accessed or exfiltration is suspected.  
 49- Harden by enforcing least-privilege RBAC, requiring peer approval for RBAC changes, restricting workload mutations via GitOps-only service accounts, and using admission policies to deny privileged pods, hostPath mounts, and unapproved registries.
 50"""
 51references = [
 52    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
 53]
 54risk_score = 47
 55rule_id = "3c82bf84-5941-495b-ac41-0302f28e1a90"
 56severity = "medium"
 57tags = [
 58    "Data Source: Kubernetes",
 59    "Domain: Kubernetes",
 60    "Use Case: Threat Detection",
 61    "Tactic: Privilege Escalation",
 62    "Tactic: Persistence",
 63    "Resources: Investigation Guide",
 64]
 65timestamp_override = "event.ingested"
 66type = "eql"
 67query = '''
 68sequence by user.name with maxspan=5m
 69  [any where event.dataset == "kubernetes.audit_logs" and
 70   `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
 71    kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and
 72    kubernetes.audit.verb in ("create", "update", "patch")]
 73  [any where event.dataset == "kubernetes.audit_logs" and
 74   `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
 75    kubernetes.audit.objectRef.resource in ("daemonsets", "deployments", "cronjobs") and
 76    kubernetes.audit.verb in ("create", "patch") and
 77    /* reduce control-plane / bootstrap noise */
 78    not kubernetes.audit.user.groups == "system:masters"
 79  ]
 80'''
 81
 82[[rule.threat]]
 83framework = "MITRE ATT&CK"
 84
 85[[rule.threat.technique]]
 86id = "T1098"
 87name = "Account Manipulation"
 88reference = "https://attack.mitre.org/techniques/T1098/"
 89
 90[[rule.threat.technique.subtechnique]]
 91id = "T1098.006"
 92name = "Additional Container Cluster Roles"
 93reference = "https://attack.mitre.org/techniques/T1098/006/"
 94
 95[rule.threat.tactic]
 96id = "TA0004"
 97name = "Privilege Escalation"
 98reference = "https://attack.mitre.org/tactics/TA0004/"
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1098"
105name = "Account Manipulation"
106reference = "https://attack.mitre.org/techniques/T1098/"
107
108[[rule.threat.technique.subtechnique]]
109id = "T1098.006"
110name = "Additional Container Cluster Roles"
111reference = "https://attack.mitre.org/techniques/T1098/006/"
112
113[rule.threat.tactic]
114id = "TA0003"
115name = "Persistence"
116reference = "https://attack.mitre.org/tactics/TA0003/"