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

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

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-*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

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

Investigation guide

edit

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.

Setup

edit

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.

Rule query

edit

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^TM

Tactic:
- Name: Discovery
- ID: TA0007
- Reference URL: https://attack.mitre.org/tactics/TA0007/
Technique:
- Name: Permission Groups Discovery
- ID: T1069
- Reference URL: https://attack.mitre.org/techniques/T1069/
Sub-technique:
- Name: Cloud Groups
- ID: T1069.003
- Reference URL: https://attack.mitre.org/techniques/T1069/003/
Technique:
- Name: Container and Resource Discovery
- ID: T1613
- Reference URL: https://attack.mitre.org/techniques/T1613/

« Azure AKS Potential API Enumeration by User Azure AKS Ephemeral Container Added to Pod »