---
title: Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity
description: Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely...
url: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/integrations/azure/discovery_azure_aks_suspicious_self_subject_review
products:
  - Elastic Security
---

# 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**:
- [[https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access)](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access)
- [[https://microsoft.github.io/Threat-Matrix-for-Kubernetes/](https://microsoft.github.io/Threat-Matrix-for-Kubernetes/)](https://microsoft.github.io/Threat-Matrix-for-Kubernetes/)
- [[https://github.com/inguardians/peirates](https://github.com/inguardians/peirates)](https://github.com/inguardians/peirates)

**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
- Noise: High
- Performance: Fast
- Profile: Aggressive
- Rule Type: Custom Query (KQL)
- Platform: Azure
- Platform: Kubernetes
- Domain: Containers

**Version**: 2
**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.

## 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.


## Rule Query

```kuery
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
- Tactic:
  - Name: Discovery
  - Id: TA0007
  - Reference URL: [[https://attack.mitre.org/tactics/TA0007/](https://attack.mitre.org/tactics/TA0007/)](https://attack.mitre.org/tactics/TA0007/)
- Technique:
  - Name: Permission Groups Discovery
  - Id: T1069
  - Reference URL: [[https://attack.mitre.org/techniques/T1069/](https://attack.mitre.org/techniques/T1069/)](https://attack.mitre.org/techniques/T1069/)
- Sub Technique:
  - Name: Cloud Groups
  - Id: T1069.003
  - Reference URL: [[https://attack.mitre.org/techniques/T1069/003/](https://attack.mitre.org/techniques/T1069/003/)](https://attack.mitre.org/techniques/T1069/003/)
- Technique:
  - Name: Container and Resource Discovery
  - Id: T1613
  - Reference URL: [[https://attack.mitre.org/techniques/T1613/](https://attack.mitre.org/techniques/T1613/)](https://attack.mitre.org/techniques/T1613/)