SelfSubjectRulesReviews

Sigma #

• RBAC Permission Enumeration Attempt source low: Detects identities attempting to enumerate their Kubernetes RBAC permissions. In the early stages of a breach, attackers will aim to list the permissions they have within the compromised environment. In a Kubernetes cluster, this can be achieved by interacting with the API server, and querying the SelfSubjectAccessReview API via e.g. a "kubectl auth can-i --list" command. This will enumerate the Role-Based Access Controls (RBAC) rules defining the compromised user's authorization.T1069, T1069.003, T1087, T1087.004

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.T1059, T1059.004, T1069, T1087, T1609, T1610
  Investigation guide

  Triage and analysis#

  Disclaimer: 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.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity source low: Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation.T1069, T1069.003, T1613
  Investigation guide

  Triage and analysis#

  Investigating Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity#

  AKS kube-audit events are carried under the flattened azure.platformlogs.properties.log.* subtree and share the ARM operation event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read. A selfsubjectaccessreviews or selfsubjectrulesreviews create lets the caller enumerate its own effective permissions. Service account and node identities issuing these reviews outside of known controllers can indicate a stolen token mapping out what it can reach.

  Possible investigation steps#

  • Confirm the acting identity in azure.platformlogs.properties.log.user.username and its groups in azure.platformlogs.properties.log.user.groups, and whether that service account or node routinely performs self-subject reviews. Check azure.platformlogs.properties.log.impersonatedUser.username: when populated, the review was issued via impersonation (e.g. kubectl auth can-i --as=<service account>) and the real actor is the impersonating user, not the service account in user.username.
  • Review azure.platformlogs.properties.log.objectRef.resource (selfsubjectaccessreviews or selfsubjectrulesreviews) and the azure.platformlogs.properties.log.requestObject to see what access was checked, plus the API path in azure.platformlogs.properties.log.requestURI. Inspect azure.platformlogs.properties.log.userAgent to distinguish interactive tooling (kubectl) from custom recon tooling or in-cluster SDKs.
  • Evaluate the source in azure.platformlogs.properties.log.sourceIPs. Control-plane and in-cluster agents use loopback (127.0.0.1/::1) or pod-network addresses (e.g. 10.244.0.0/16); an external caller wielding a service account token is more suspicious. Pivot on the source for related API activity, denied requests, exec sessions, or RBAC changes from the same identity.

  False positive analysis#

  • Known observability or workflow controllers may issue self-subject reviews; extend exclusions for validated identities. Azure Arc's agent service accounts (system:serviceaccount:azure-arc:*) legitimately submit these reviews and are already excluded; add other validated platform controllers as they are baselined.
  • Admin impersonation workflows can trigger this via an impersonated service account; validate the impersonating user in azure.platformlogs.properties.log.impersonatedUser.username.

  Response and remediation#

  • If unauthorized, revoke the service account token and review the RBAC bindings granted to it.
  • Correlate with any successful privileged actions the identity performed after the review.
  • Collect kube-audit and identity artifacts per incident response procedures.
• GKE Suspicious Self-Subject Review via Service Account source low: Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC.T1069, T1069.003, T1613
  Investigation guide

  Triage and analysis#

  Investigating GKE Suspicious Self-Subject Review via Service Account#

  Review the calling service account or node identity and subsequent API activity.

  Investigation steps#

  • Confirm user.email and event.action (selfsubjectaccessreviews or selfsubjectrulesreviews).
  • Correlate with denied requests, secret access, or RBAC changes from the same identity.

  False positives#

  • Known observability or workflow controllers; extend exclusions if needed.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

Show 1 more (4 total) on the rules page