T1098.006 Sumo Logic CSE · Sumo

Detect Additional Container Cluster Roles in Sumo Logic CSE

An adversary may add additional roles or permissions to an adversary-controlled user or service account to maintain persistent access to a container orchestration system. For example, an adversary with sufficient permissions may create a RoleBinding or ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account. Where ABAC is in use, an adversary may modify a Kubernetes ABAC policy to give the target account additional permissions. This technique may also be used in conjunction with cloud-based RBAC assignments in managed Kubernetes services such as GKE, EKS, and AKS.

MITRE ATT&CK

Tactic
Persistence Privilege Escalation
Technique
T1098 Account Manipulation
Sub-technique
T1098.006 Additional Container Cluster Roles
Canonical reference
https://attack.mitre.org/techniques/T1098/006/

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql
_sourceCategory=kubernetes/audit OR _sourceCategory=*kube*audit*
| json field=_raw "verb" as verb nodrop
| json field=_raw "objectRef.resource" as resource nodrop
| json field=_raw "objectRef.name" as resourceName nodrop
| json field=_raw "objectRef.namespace" as namespace nodrop
| json field=_raw "user.username" as username nodrop
| json field=_raw "sourceIPs[0]" as sourceIP nodrop
| json field=_raw "userAgent" as userAgent nodrop
| json field=_raw "responseStatus.code" as responseCode nodrop
| json field=_raw "requestObject" as requestObject nodrop
| where verb in ("create", "update", "patch")
| where resource in ("clusterrolebindings", "rolebindings", "clusterroles", "roles")
| where responseCode >= 200 and responseCode < 300
| where !(username matches "system:*" and !(username matches "system:serviceaccount:*"))
| if(requestObject matches "*cluster-admin*" or requestObject matches "*system:masters*" or requestObject matches "*system:node-admin*" or requestObject matches "*admin*", 1, 0) as isSensitiveRole
| if(username matches "system:serviceaccount:*", 1, 0) as isServiceAccount
| if(resource = "clusterrolebindings" or resource = "clusterroles", 1, 0) as isClusterScoped
| (isSensitiveRole * 3 + isClusterScoped * 2 + isServiceAccount) as riskScore
| fields _messageTime, verb, resource, resourceName, namespace, username, sourceIP, userAgent, isSensitiveRole, isServiceAccount, isClusterScoped, riskScore, requestObject
| sort by riskScore desc, _messageTime desc
high severity high confidence

Detects Kubernetes RBAC role binding creation and modification from kube-apiserver audit logs ingested into Sumo Logic. Parses JSON-structured audit log entries to extract verb, resource type, user identity, response code, and request payload. Applies a weighted risk scoring model (cluster-scoped +2, sensitive role reference +3, service account actor +1) to prioritise high-severity findings. Intended as both a saved search and a signal source for Sumo Logic Cloud SIEM Enterprise (CSE) rule development.

Data Sources

Kubernetes audit logs collected via Sumo Logic Kubernetes Collection Helm chartFluentd or Fluent Bit DaemonSet forwarding kube-apiserver audit logs to Sumo Logic HTTP SourceEKS audit logs via CloudWatch Logs subscription to Sumo LogicGKE audit logs via Cloud Logging export to Sumo Logic

Required Tables

_sourceCategory=kubernetes/audit

False Positives & Tuning

  • Cluster provisioning automation (Terraform, Pulumi, eksctl) that creates default RBAC bindings for managed node groups and system components during cluster creation
  • Service mesh installations (Istio, Linkerd, Cilium) that create numerous ClusterRoles and bindings for their control plane components during initial deployment
  • Development and staging environments where developers have broad permissions and frequently iterate on RBAC configurations as part of application development workflows
Download portable Sigma rule (.yml)

Other platforms for T1098.006


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Create Privileged ClusterRoleBinding for Service Account

    Expected signal: Kubernetes API server audit log: verb=create, objectRef.resource=clusterrolebindings, objectRef.name=attacker-cluster-admin-binding, responseStatus.code=201. Second audit event for serviceaccounts create. The requestObject will contain roleRef.name=cluster-admin and subjects referencing the service account.

  2. Test 2Create Namespace-Scoped RoleBinding for External User

    Expected signal: Kubernetes API server audit log: verb=create, objectRef.resource=rolebindings, objectRef.namespace=attacker-test-ns, objectRef.name=attacker-ns-admin-binding, responseStatus.code=201. The requestObject includes roleRef.name=admin and subjects with kind=User and [email protected].

  3. Test 3Modify Existing ClusterRole to Add Wildcard Permissions

    Expected signal: Kubernetes API server audit log: verb=patch, objectRef.resource=clusterroles, objectRef.name=attacker-test-role, responseStatus.code=200. The requestObject contains JSON patch operations adding wildcard rules. This differs from 'create' operations and may be missed by detections that only look for verb=create.

  4. Test 4Create ABAC Policy Entry via ConfigMap Modification

    Expected signal: Kubernetes API server audit log: verb=create, objectRef.resource=configmaps, objectRef.name=attacker-abac-policy. If this were a real kube-system ABAC policy modification: verb=update/patch, objectRef.resource=configmaps, objectRef.namespace=kube-system. The ConfigMap data contains ABAC policy JSON granting wildcard permissions.

Unlock Pro Content

Get the full detection package for T1098.006 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections