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…
Description
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.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersIaaSIdentity ProviderLinuxmacOSOffice SuiteSaaSWindows
The rule states no platform. This is derived from the 2 ATT&CK techniques it maps to.
- Log source category
- event_index
Known benign triggers
- SelfSubjectAccessReview ("can I do X") is routinely issued by controllers checking their own permissions, so busy clusters generate benign volume from platform and add-on service accounts (for example kube-system managed add-ons such as azure-policy, Microsoft Defender, metrics-server, and konnectivity, plus operators like cert-manager, ingress controllers, and Argo/Flux). The rule ships with only the Azure Arc agent accounts (system:serviceaccount:azure-arc:*) excluded; that namespace exists only on Arc-enabled clusters and is one example, not a complete list. Treat the exclusion set as a per-environment denylist: baseline the calling service accounts and add validated platform/observability controllers after review. SelfSubjectRulesReview ("list everything I can do") is far rarer from non-human identities and higher signal. Admin impersonation workflows can also trigger this via an impersonated service account; validate the impersonating user.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| github.com/inguardians/peirates | 6 |
| kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access | 5 |
| microsoft.github.io/Threat-Matrix-for-Kubernetes/ | 15 |
From the source
- At source
- Open at source
- Upstream identifier
- 11afa743-5264-460b-9d0a-b687efd38a71
- Tagged by the source as
- Data Source: AzureData Source: Azure Platform LogsData Source: KubernetesDomain: CloudDomain: ContainersDomain: KubernetesNoise: HighPerformance: FastPlatform: AzurePlatform: KubernetesProfile: AggressiveResources: Investigation GuideRule Type: Custom Query (KQL)Tactic: DiscoveryUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3