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/07/23"
  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]
 91timestamp_override = "event.ingested"
 92type = "query"
 93
 94query = '''
 95data_stream.dataset:azure.platformlogs and
 96    event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
 97    azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
 98    azure.platformlogs.properties.log.stage:"ResponseComplete" and
 99    azure.platformlogs.properties.log.objectRef.resource:"serviceaccounts" and
100    azure.platformlogs.properties.log.objectRef.subresource:"token" and
101    azure.platformlogs.properties.log.verb:"create" and
102    azure.platformlogs.properties.log.responseStatus.code:("200" or "201") and
103    not azure.platformlogs.properties.log.user.username:(
104        system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or
105        system\:serviceaccount\:kube-system\:*
106    )
107'''
108
109[rule.investigation_fields]
110field_names = [
111    "@timestamp",
112    "event.action",
113    "azure.platformlogs.category",
114    "azure.platformlogs.properties.log.verb",
115    "azure.platformlogs.properties.log.user.username",
116    "azure.platformlogs.properties.log.user.groups",
117    "azure.platformlogs.properties.log.userAgent",
118    "azure.platformlogs.properties.log.sourceIPs",
119    "azure.platformlogs.properties.log.objectRef.namespace",
120    "azure.platformlogs.properties.log.objectRef.name",
121    "azure.platformlogs.properties.log.objectRef.subresource",
122    "azure.platformlogs.properties.log.requestURI",
123    "azure.platformlogs.properties.log.responseStatus.code",
124]
125
126[[rule.threat]]
127framework = "MITRE ATT&CK"
128
129[[rule.threat.technique]]
130id = "T1528"
131name = "Steal Application Access Token"
132reference = "https://attack.mitre.org/techniques/T1528/"
133
134[rule.threat.tactic]
135id = "TA0006"
136name = "Credential Access"
137reference = "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 in azure.platformlogs.properties.log.user.groups) and whether it should mint tokens. A workload service account (system:serviceaccount:<ns>:<sa>) minting a token, or masterclient (the local cluster-admin cert), is the higher-concern case.
  • Inspect azure.platformlogs.properties.log.userAgent to distinguish interactive/expected tooling (kubectl create token) from custom clients (for example curl), 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.namespace and 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.sourceIPs and 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 running kubectl create token may surface; baseline those identities and exclude the specific validated account rather than re-broadening to all system:*, 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

to-top