{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/rbac/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","rbac","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, sourced from Elastic\u0026rsquo;s detection-rules repository, focuses on identifying malicious activity within Kubernetes environments. Specifically, it targets the creation, update, or patching of Roles and ClusterRoles that introduce high-risk RBAC permissions. These permissions include wildcard access (e.g., \u003ccode\u003e*\u003c/code\u003e) and escalation verbs such as \u003ccode\u003ebind\u003c/code\u003e, \u003ccode\u003eescalate\u003c/code\u003e, or \u003ccode\u003eimpersonate\u003c/code\u003e. The rule leverages audit logs to monitor these actions and flags those that could lead to privilege escalation or unauthorized access. The rule aims to detect attackers attempting to add a new ClusterRole with \u003ccode\u003e*\u003c/code\u003e verbs/resources and then using it to bind themselves or a service account to cluster-admin–equivalent access. This is important because attackers can silently expand privileges and enable persistence or lateral movement across the cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new ClusterRole or Role with broad permissions, including wildcard verbs and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker may use \u003ccode\u003ekubectl\u003c/code\u003e or a similar tool to apply a YAML manifest defining the malicious role.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server receives the request to create the role, and the audit logging system captures the event.\u003c/li\u003e\n\u003cli\u003eThe attacker then attempts to bind the newly created role to a service account or user, granting them the elevated permissions. This is achieved by creating or modifying a RoleBinding or ClusterRoleBinding object.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server logs the creation or modification of the RoleBinding or ClusterRoleBinding.\u003c/li\u003e\n\u003cli\u003eWith the elevated permissions, the attacker can now perform actions they were previously unauthorized to do, such as accessing sensitive data, deploying malicious containers, or modifying cluster configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages these elevated privileges to establish persistence within the cluster and potentially move laterally to other resources or environments.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to full cluster compromise, allowing the attacker to control all resources and data within the Kubernetes environment. This can result in data breaches, service disruptions, and significant financial losses. The severity depends on the scope of the compromised role and the resources it grants access to. Even seemingly minor modifications can have a cascading effect, enabling attackers to gain complete control over critical systems.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Creation or Modification of Sensitive Role\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious RBAC changes (rule.name).\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for the creation or modification of Roles and ClusterRoles with wildcard permissions or escalation verbs (kubernetes.audit.requestObject.rules.verbs, kubernetes.audit.requestObject.rules.resources).\u003c/li\u003e\n\u003cli\u003eImplement RBAC guardrails, such as OPA Gatekeeper or Kyverno policies, to prevent the creation of overly permissive roles (references).\u003c/li\u003e\n\u003cli\u003eRestrict who can create or update RBAC objects and require all RBAC changes to go through code review and signed GitOps automation (references).\u003c/li\u003e\n\u003cli\u003eRegularly review existing Roles and ClusterRoles to identify and remove any unnecessary or overly broad permissions.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging on nodes to enhance detection capabilities around kubectl usage.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-05T13:13:30Z","date_published":"2026-03-05T13:13:30Z","id":"/briefs/2026-03-kubernetes-role-modification/","summary":"This rule detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), potentially leading to privilege escalation or unauthorized access within the cluster.","title":"Kubernetes Sensitive Role Creation or Modification","url":"https://feed.craftedsignal.io/briefs/2026-03-kubernetes-role-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","rbac","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule focuses on identifying suspicious activities related to Kubernetes Role-Based Access Control (RBAC). It specifically targets the creation, update, or patching of Kubernetes Roles or ClusterRoles that introduce high-risk permissions. These include wildcard access, where a single rule grants access to all resources, and escalation verbs like \u0026lsquo;bind\u0026rsquo;, \u0026rsquo;escalate\u0026rsquo;, or \u0026lsquo;impersonate\u0026rsquo;, which can be used to elevate privileges. The rule is designed to alert security teams to potential privilege escalation or unauthorized access attempts within Kubernetes environments. The Elastic detection rule was last updated on April 27, 2026, and aims to detect malicious actors attempting to gain cluster-admin-equivalent access by creating new ClusterRoles with \u003ccode\u003e*\u003c/code\u003e verbs/resources and binding them to their accounts or service accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create or modify a Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe attacker adds high-risk permissions to the Role or ClusterRole, such as wildcard verbs/resources (\u003ccode\u003e*\u003c/code\u003e) or escalation verbs (bind, escalate, impersonate).\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server authorizes the request, potentially due to misconfigured RBAC policies.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies a RoleBinding or ClusterRoleBinding to associate the modified Role or ClusterRole with a target user, group, or service account.\u003c/li\u003e\n\u003cli\u003eThe target user, group, or service account now possesses the elevated privileges granted by the modified Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to perform unauthorized actions within the cluster, such as accessing sensitive data or deploying malicious workloads.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence by maintaining the modified Role or ClusterRole and its associated bindings, allowing continued access to elevated privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to significant security breaches within a Kubernetes environment. Attackers can gain unauthorized access to sensitive data, deploy malicious workloads, disrupt services, and potentially compromise the entire cluster. This can result in data breaches, financial losses, and reputational damage. The rule aims to prevent attackers from silently expanding privileges, enabling persistence, or facilitating lateral movement across the cluster.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Creation of Sensitive Role\u003c/code\u003e to your SIEM to detect the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions.\u003c/li\u003e\n\u003cli\u003eEnable Kubernetes audit logging to capture the necessary events for the Sigma rules to function effectively (reference: Kubernetes audit logs in \u003ccode\u003elogsource\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement RBAC guardrails using tools like OPA Gatekeeper or Kyverno to prevent the creation of Roles/ClusterRoles with wildcard or escalation verbs (reference: harden recommendation in the content).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit RBAC configurations to identify and remediate overly permissive roles and bindings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T12:00:00Z","date_published":"2024-01-04T12:00:00Z","id":"/briefs/2024-01-kubernetes-sensitive-role-creation/","summary":"Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs, potentially leading to privilege escalation or unauthorized access within the cluster.","title":"Kubernetes Sensitive Role Creation or Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-sensitive-role-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","rbac","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies modifications to Kubernetes Roles or ClusterRoles that result in the granting of wildcard permissions for both verbs and resources. This effectively elevates the privileges associated with the role to be similar to that of a cluster-admin, granting near-complete control over the Kubernetes environment. This type of privilege escalation is often intentional and may indicate malicious activity, such as an attacker attempting to gain broader access within the cluster. The rule requires Kubernetes audit logs with RequestResponse level and the response body to inspect the final merged role. It excludes loopback source IPs to avoid false positives from local system processes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a Role or ClusterRole that, if modified, would grant them broader privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl patch\u003c/code\u003e or \u003ccode\u003ekubectl update\u003c/code\u003e to modify the existing Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe modification introduces wildcard permissions (\u003ccode\u003everbs: [\u0026quot;*\u0026quot;]\u003c/code\u003e and \u003ccode\u003eresources: [\u0026quot;*\u0026quot;]\u003c/code\u003e) to the role\u0026rsquo;s rules.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server processes the patch or update request, granting the modified permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly acquired privileges to perform actions they were previously unauthorized to do, such as accessing sensitive data, deploying malicious workloads, or further escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access other resources or namespaces within the Kubernetes cluster, taking advantage of the elevated permissions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation can allow an attacker to gain complete control over a Kubernetes cluster. This can lead to data breaches, denial of service, deployment of malicious containers, and other security incidents. The severity of the impact depends on the scope of the compromised cluster and the sensitivity of the data and applications it hosts. A single compromised role can lead to a full cluster compromise if not detected and remediated quickly.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes RBAC Wildcard Elevation on Existing Role\u0026rdquo; to your SIEM and tune for your environment to detect wildcard privilege escalations in Kubernetes audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the actor (user, group, impersonation) and their source IP.\u003c/li\u003e\n\u003cli\u003eDiff the Role or ClusterRole YAML before and after the change to understand the scope of the permission change.\u003c/li\u003e\n\u003cli\u003eReview RoleBindings and ClusterRoleBindings that reference the modified role to identify which subjects gained the widened access.\u003c/li\u003e\n\u003cli\u003eImplement policy-as-code to prevent unauthorized modifications to RBAC configurations.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious activity related to account manipulation (T1098) and privilege escalation (TA0004).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:23:00Z","date_published":"2024-01-03T18:23:00Z","id":"/briefs/2024-01-kubernetes-rbac-elevation/","summary":"The rule detects when a Kubernetes Role or ClusterRole is patched or updated to grant wildcard verbs and resources, effectively granting cluster-admin-like privileges, which is often a deliberate privilege expansion and could indicate malicious activity.","title":"Kubernetes RBAC Wildcard Elevation on Existing Role","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-rbac-elevation/"}],"language":"en","title":"CraftedSignal Threat Feed — Rbac","version":"https://jsonfeed.org/version/1.1"}