Kubernetes RBAC Wildcard Elevation on Existing Role

This 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.

Attack Chain

1. An attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.
2. The attacker identifies a Role or ClusterRole that, if modified, would grant them broader privileges.
3. The attacker uses kubectl patch or kubectl update to modify the existing Role or ClusterRole.
4. The modification introduces wildcard permissions (verbs: ["*"] and resources: ["*"]) to the role’s rules.
5. The Kubernetes API server processes the patch or update request, granting the modified permissions.
6. The 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.
7. The attacker attempts to access other resources or namespaces within the Kubernetes cluster, taking advantage of the elevated permissions.

Impact

A 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.

Recommendation

• Deploy the Sigma rule “Kubernetes RBAC Wildcard Elevation on Existing Role” to your SIEM and tune for your environment to detect wildcard privilege escalations in Kubernetes audit logs.
• Investigate any alerts generated by the Sigma rule, focusing on the actor (user, group, impersonation) and their source IP.
• Diff the Role or ClusterRole YAML before and after the change to understand the scope of the permission change.
• Review RoleBindings and ClusterRoleBindings that reference the modified role to identify which subjects gained the widened access.
• Implement policy-as-code to prevent unauthorized modifications to RBAC configurations.
• Monitor Kubernetes audit logs for suspicious activity related to account manipulation (T1098) and privilege escalation (TA0004).