[New Rules] Misc. K8s RBAC Abuse Rules

[Aegrah]

New Rules Summary

1. Kubernetes Cluster-Admin Role Binding Created

Description: This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration.

Detection: Monitors for create operations on rolebindings or clusterrolebindings where the roleRef.name is cluster-admin.

---

2. Kubernetes Creation or Modification of Sensitive Role

Description: 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), which may enable privilege escalation or unauthorized access within the cluster.

Detection: Monitors for create, update, or patch operations on roles or clusterroles where the rules include sensitive verbs (*, escalate, bind, impersonate) or target RBAC resources.

---

3. Kubernetes Creation of a RoleBinding Referencing a ServiceAccount

Description: This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access.

Detection: Monitors for create operations on rolebindings or clusterrolebindings where the request object includes a serviceAccountName.

---

4. Kubernetes Sensitive RBAC Change Followed by Workload Modification

Description: Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment.

Detection: Correlates two events within 5 minutes by the same user: (1) a Role/ClusterRole creation or modification, followed by (2) a DaemonSet, Deployment, or CronJob creation or patch.

---

5. Kubernetes Service Account Modified RBAC Objects

Description: Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation.

Detection: Monitors for create, update, patch, or delete operations on RBAC resources performed by principals with usernames matching system:serviceaccount:*, excluding known system controllers.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[Aegrah]

Most k8s rules don't have an interval/timing set. I assume these will use the default. I copy-pasted these templates so I left them out as well - if we should still include these, I can add them in a large PR to all k8s rules.

[terrancedejesus]

Queries, rules and behavior they match on look good. My biggest question is parity between K8s integration and each provider audit logs. Example - I searched for rolebindings and found some GCP audit log based rules with similar visibility. Have we considered when to use what vs what? Can maybe be discussed async.

[terrancedejesus]

Suggested change

	"Data Source: Kubernetes",
	"Data Source: Kubernetes",
	"Data Source: Kubernetes Audit Logs"

Just a thought. Faceted search should still show these if only Kubernetes is available vs container log searches. Ignore if you feel not necessary or we can circle back with the tagging initiative.

[imays11]

@Aegrah I'm not sure why this one is malicious? Isn't this the normal process for assigning service accounts permissions?

[Aegrah]

The reason to detect it is that this is the exact mechanism attackers abuse for privilege escalation and persistence: if any compromised identity can create a RoleBinding, it can instantly grant elevated permissions to a ServiceAccount and turn a pod-level compromise into cluster-level access. It's meant as high-signal monitoring of a critical control-plane action, not per se malicious. Also, this activity should not be frequent, and it will be easy to exclude known identities once we get telemetry.