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

  1[metadata]
  2creation_date = "2026/07/09"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2026/07/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review
 11APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen
 12tokens probing effective RBAC before privilege escalation.
 13"""
 14false_positives = [
 15    """
 16    SelfSubjectAccessReview ("can I do X") is routinely issued by controllers checking their own permissions, so busy
 17    clusters generate benign volume from platform and add-on service accounts (for example kube-system managed add-ons
 18    such as azure-policy, Microsoft Defender, metrics-server, and konnectivity, plus operators like cert-manager,
 19    ingress controllers, and Argo/Flux). The rule ships with only the Azure Arc agent accounts
 20    (system:serviceaccount:azure-arc:*) excluded; that namespace exists only on Arc-enabled clusters and is one example,
 21    not a complete list. Treat the exclusion set as a per-environment denylist: baseline the calling service accounts and
 22    add validated platform/observability controllers after review. SelfSubjectRulesReview ("list everything I can do")
 23    is far rarer from non-human identities and higher signal. Admin impersonation workflows can also trigger this via an
 24    impersonated service account; validate the impersonating user.
 25    """,
 26]
 27from = "now-9m"
 28index = ["logs-azure.platformlogs-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity"
 32note = """## Triage and analysis
 33
 34### Investigating Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity
 35
 36AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
 37operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. A `selfsubjectaccessreviews`
 38or `selfsubjectrulesreviews` create lets the caller enumerate its own effective permissions. Service account and node
 39identities issuing these reviews outside of known controllers can indicate a stolen token mapping out what it can reach.
 40
 41### Possible investigation steps
 42
 43- Confirm the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in
 44  `azure.platformlogs.properties.log.user.groups`, and whether that service account or node routinely performs
 45  self-subject reviews. Check `azure.platformlogs.properties.log.impersonatedUser.username`: when populated, the review
 46  was issued via impersonation (e.g. `kubectl auth can-i --as=<service account>`) and the real actor is the
 47  impersonating user, not the service account in `user.username`.
 48- Review `azure.platformlogs.properties.log.objectRef.resource` (selfsubjectaccessreviews or selfsubjectrulesreviews)
 49  and the `azure.platformlogs.properties.log.requestObject` to see what access was checked, plus the API path in
 50  `azure.platformlogs.properties.log.requestURI`. Inspect `azure.platformlogs.properties.log.userAgent` to distinguish
 51  interactive tooling (`kubectl`) from custom recon tooling or in-cluster SDKs.
 52- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. Control-plane and in-cluster agents use loopback
 53  (`127.0.0.1`/`::1`) or pod-network addresses (e.g. `10.244.0.0/16`); an external caller wielding a service account
 54  token is more suspicious. Pivot on the source for related API activity, denied requests, exec sessions, or RBAC
 55  changes from the same identity.
 56
 57### False positive analysis
 58
 59- Known observability or workflow controllers may issue self-subject reviews; extend exclusions for validated
 60  identities. Azure Arc's agent service accounts (`system:serviceaccount:azure-arc:*`) legitimately submit these reviews
 61  and are already excluded; add other validated platform controllers as they are baselined.
 62- Admin impersonation workflows can trigger this via an impersonated service account; validate the impersonating user in
 63  `azure.platformlogs.properties.log.impersonatedUser.username`.
 64
 65### Response and remediation
 66
 67- If unauthorized, revoke the service account token and review the RBAC bindings granted to it.
 68- Correlate with any successful privileged actions the identity performed after the review.
 69- Collect kube-audit and identity artifacts per incident response procedures.
 70"""
 71references = [
 72    "https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access",
 73    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
 74    "https://github.com/inguardians/peirates",
 75]
 76risk_score = 21
 77rule_id = "11afa743-5264-460b-9d0a-b687efd38a71"
 78setup = """
 79The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs`
 80data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft
 81recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Self-subject review
 82creates are recorded in both categories with the same `auditID`, so clusters that enable both categories may generate
 83two alerts per review.
 84"""
 85severity = "low"
 86tags = [
 87    "Domain: Cloud",
 88    "Domain: Kubernetes",
 89    "Data Source: Azure",
 90    "Data Source: Azure Platform Logs",
 91    "Data Source: Kubernetes",
 92    "Use Case: Threat Detection",
 93    "Tactic: Discovery",
 94    "Resources: Investigation Guide",
 95]
 96timestamp_override = "event.ingested"
 97type = "query"
 98
 99query = '''
100data_stream.dataset:azure.platformlogs and
101  event.action:Microsoft.ContainerService/managedClusters/diagnosticLogs/Read and
102  azure.platformlogs.category:(kube-audit or kube-audit-admin) and
103  azure.platformlogs.properties.log.stage:ResponseComplete and
104  azure.platformlogs.properties.log.verb:create and
105  azure.platformlogs.properties.log.objectRef.resource:(selfsubjectaccessreviews or selfsubjectrulesreviews) and
106  azure.platformlogs.properties.log.user.username:((system\:node\:* or system\:serviceaccount\:*) and
107  not system\:serviceaccount\:azure-arc\:*)
108'''
109
110[rule.investigation_fields]
111field_names = [
112    "@timestamp",
113    "event.action",
114    "azure.platformlogs.category",
115    "azure.platformlogs.properties.log.verb",
116    "azure.platformlogs.properties.log.user.username",
117    "azure.platformlogs.properties.log.user.groups",
118    "azure.platformlogs.properties.log.impersonatedUser.username",
119    "azure.platformlogs.properties.log.userAgent",
120    "azure.platformlogs.properties.log.sourceIPs",
121    "azure.platformlogs.properties.log.objectRef.resource",
122    "azure.platformlogs.properties.log.objectRef.namespace",
123    "azure.platformlogs.properties.log.requestURI",
124    "azure.platformlogs.properties.log.responseStatus.code",
125]
126
127[[rule.threat]]
128framework = "MITRE ATT&CK"
129
130[[rule.threat.technique]]
131id = "T1069"
132name = "Permission Groups Discovery"
133reference = "https://attack.mitre.org/techniques/T1069/"
134
135[[rule.threat.technique.subtechnique]]
136id = "T1069.003"
137name = "Cloud Groups"
138reference = "https://attack.mitre.org/techniques/T1069/003/"
139
140[[rule.threat.technique]]
141id = "T1613"
142name = "Container and Resource Discovery"
143reference = "https://attack.mitre.org/techniques/T1613/"
144
145[rule.threat.tactic]
146id = "TA0007"
147name = "Discovery"
148reference = "https://attack.mitre.org/tactics/TA0007/"