Azure AKS Service Account Token Created via TokenRequest API
Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/23"
3integration = ["azure"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API
11(serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account
12tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster.
13Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token
14for another service account is not excluded.
15"""
16false_positives = [
17 """
18 Controllers, CI/CD systems, and platform components legitimately request service account tokens. Baseline the
19 requesting identities and exclude verified automation after review.
20 """,
21]
22from = "now-9m"
23index = ["logs-azure.platformlogs-*"]
24language = "kuery"
25license = "Elastic License v2"
26name = "Azure AKS Service Account Token Created via TokenRequest API"
27note = """## Triage and analysis
28
29### Investigating Azure AKS Service Account Token Created via TokenRequest API
30
31AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
32operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. The TokenRequest API
33(`serviceaccounts/token`) mints a bound service account token. The kubelet (`system:node:*`) and the
34kube-controller-manager (`aksService`) mint these tokens continuously for normal pod operation and are excluded; the
35signal is a non-platform identity minting one. An attacker with rights over a service account can request a token to act
36as that workload identity, reaching resources the compromised principal cannot.
37
38### Possible investigation steps
39
40- Identify the requesting identity in `azure.platformlogs.properties.log.user.username` (and its groups in
41 `azure.platformlogs.properties.log.user.groups`) and whether it should mint tokens. A workload service account
42 (`system:serviceaccount:<ns>:<sa>`) minting a token, or `masterclient` (the local cluster-admin cert), is the
43 higher-concern case.
44- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive/expected tooling (`kubectl create
45 token`) from custom clients (for example `curl`), which is a stronger indicator of scripted abuse.
46- Identify the target service account in `azure.platformlogs.properties.log.objectRef.name` /
47 `azure.platformlogs.properties.log.objectRef.namespace` and what RBAC that account holds; minting a token for a
48 higher-privileged service account is privilege escalation.
49- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for follow-on API calls made with
50 the minted token, and correlate with recent RBAC changes, secret reads, or exec sessions from the same identity.
51
52### False positive analysis
53
54- Controllers, CI/CD systems, and platform components legitimately request service account tokens (for example the
55 kube-controller-manager as `aksService`, which is excluded). Additional automation such as GitOps operators or CI
56 running `kubectl create token` may surface; baseline those identities and exclude the specific validated account
57 rather than re-broadening to all `system:*`, which would blind the rule to compromised workload service accounts.
58
59### Response and remediation
60
61- If unauthorized, revoke the minted token and the requesting identity's credentials, and review the RBAC that permitted
62 token creation.
63- Audit actions performed with the target service account's identity after the request.
64- Collect kube-audit and identity artifacts per incident response procedures.
65"""
66references = [
67 "https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/",
68 "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
69 "https://github.com/inguardians/peirates",
70]
71risk_score = 47
72rule_id = "95db6791-8e88-47d0-81c9-531ff79c0e60"
73setup = """
74The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs`
75data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft
76recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). TokenRequest is a
77mutating create recorded in both categories with the same `auditID`, so clusters that enable both categories may
78generate two alerts per request.
79"""
80severity = "medium"
81tags = [
82 "Domain: Cloud",
83 "Domain: Kubernetes",
84 "Data Source: Azure",
85 "Data Source: Azure Platform Logs",
86 "Data Source: Kubernetes",
87 "Use Case: Threat Detection",
88 "Tactic: Credential Access",
89 "Resources: Investigation Guide",
90 "Noise: High",
91 "Performance: Fast",
92 "Profile: Aggressive",
93 "Rule Type: Custom Query (KQL)",
94 "Platform: Azure",
95 "Platform: Kubernetes",
96 "Domain: Containers",
97]
98timestamp_override = "event.ingested"
99type = "query"
100
101query = '''
102data_stream.dataset:azure.platformlogs and
103 event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
104 azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
105 azure.platformlogs.properties.log.stage:"ResponseComplete" and
106 azure.platformlogs.properties.log.objectRef.resource:"serviceaccounts" and
107 azure.platformlogs.properties.log.objectRef.subresource:"token" and
108 azure.platformlogs.properties.log.verb:"create" and
109 azure.platformlogs.properties.log.responseStatus.code:("200" or "201") and
110 not azure.platformlogs.properties.log.user.username:(
111 system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or
112 system\:serviceaccount\:kube-system\:*
113 )
114'''
115
116[rule.investigation_fields]
117field_names = [
118 "@timestamp",
119 "event.action",
120 "azure.platformlogs.category",
121 "azure.platformlogs.properties.log.verb",
122 "azure.platformlogs.properties.log.user.username",
123 "azure.platformlogs.properties.log.user.groups",
124 "azure.platformlogs.properties.log.userAgent",
125 "azure.platformlogs.properties.log.sourceIPs",
126 "azure.platformlogs.properties.log.objectRef.namespace",
127 "azure.platformlogs.properties.log.objectRef.name",
128 "azure.platformlogs.properties.log.objectRef.subresource",
129 "azure.platformlogs.properties.log.requestURI",
130 "azure.platformlogs.properties.log.responseStatus.code",
131]
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[[rule.threat.technique]]
137id = "T1528"
138name = "Steal Application Access Token"
139reference = "https://attack.mitre.org/techniques/T1528/"
140
141[rule.threat.tactic]
142id = "TA0006"
143name = "Credential Access"
144reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Azure AKS Service Account Token Created via TokenRequest API
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. The TokenRequest API
(serviceaccounts/token) mints a bound service account token. The kubelet (system:node:*) and the
kube-controller-manager (aksService) mint these tokens continuously for normal pod operation and are excluded; the
signal is a non-platform identity minting one. An attacker with rights over a service account can request a token to act
as that workload identity, reaching resources the compromised principal cannot.
Possible investigation steps
- Identify the requesting identity in
azure.platformlogs.properties.log.user.username(and its groups inazure.platformlogs.properties.log.user.groups) and whether it should mint tokens. A workload service account (system:serviceaccount:<ns>:<sa>) minting a token, ormasterclient(the local cluster-admin cert), is the higher-concern case. - Inspect
azure.platformlogs.properties.log.userAgentto distinguish interactive/expected tooling (kubectl create token) from custom clients (for examplecurl), which is a stronger indicator of scripted abuse. - Identify the target service account in
azure.platformlogs.properties.log.objectRef.name/azure.platformlogs.properties.log.objectRef.namespaceand what RBAC that account holds; minting a token for a higher-privileged service account is privilege escalation. - Evaluate the source in
azure.platformlogs.properties.log.sourceIPsand pivot on it for follow-on API calls made with the minted token, and correlate with recent RBAC changes, secret reads, or exec sessions from the same identity.
False positive analysis
- Controllers, CI/CD systems, and platform components legitimately request service account tokens (for example the
kube-controller-manager as
aksService, which is excluded). Additional automation such as GitOps operators or CI runningkubectl create tokenmay surface; baseline those identities and exclude the specific validated account rather than re-broadening to allsystem:*, which would blind the rule to compromised workload service accounts.
Response and remediation
- If unauthorized, revoke the minted token and the requesting identity's credentials, and review the RBAC that permitted token creation.
- Audit actions performed with the target service account's identity after the request.
- Collect kube-audit and identity artifacts per incident response procedures.
References
Related rules
- Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity
- Azure AKS Certificate Signing Request Created or Approved
- Azure AKS CoreDNS or Kube-DNS Configuration Modified
- Azure AKS Secret get or list with Suspicious User Agent
- Azure AKS API Server Proxying Request to Kubelet