Loading

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

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.

Rule type: query
Rule indices:

  • logs-azure.platformlogs-*

Rule Severity: low
Risk Score: 21
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Cloud
  • Domain: Kubernetes
  • Data Source: Azure
  • Data Source: Azure Platform Logs
  • Data Source: Kubernetes
  • Use Case: Threat Detection
  • Tactic: Discovery
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2
The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the azure.platformlogs data stream is required for this rule. Enable either the kube-audit or the kube-audit-admin log category (Microsoft recommends kube-audit-admin alone to reduce volume, as it only drops read-only get/list events). Self-subject review creates are recorded in both categories with the same auditID, so clusters that enable both categories may generate two alerts per review.

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.

  • 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.
  • 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.
  • 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.
data_stream.dataset:azure.platformlogs and
  event.action:Microsoft.ContainerService/managedClusters/diagnosticLogs/Read and
  azure.platformlogs.category:(kube-audit or kube-audit-admin) and
  azure.platformlogs.properties.log.stage:ResponseComplete and
  azure.platformlogs.properties.log.verb:create and
  azure.platformlogs.properties.log.objectRef.resource:(selfsubjectaccessreviews or selfsubjectrulesreviews) and
  azure.platformlogs.properties.log.user.username:((system\:node\:* or system\:serviceaccount\:*) and
  not system\:serviceaccount\:azure-arc\:*)

Framework: MITRE ATT&CK