Kubernetes Service Account Token Created via TokenRequest API
Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for…
Description
Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management.
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 ProviderLinuxmacOSNetwork DevicesOffice SuiteSaaSWindows
The rule states no platform. This is derived from the ATT&CK technique it maps to.
- Log source category
- event_index
Known benign triggers
- New automation, admission webhooks, or platform agents that legitimately call the TokenRequest API under a non-standard user string may require narrow exclusions by user.name or source IP.
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 |
|---|---|
| attack.mitre.org/techniques/T1552/007/ | 12 |
| kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/ | 2 |
From the source
- At source
- Open at source
- Upstream identifier
- 4df91789-7859-4bc4-9c5a-6b56bfa81a8b
- Tagged by the source as
- Data Source: KubernetesDomain: CloudDomain: ContainersDomain: KubernetesNoise: LowPerformance: FastPlatform: KubernetesResources: Investigation GuideRule Type: Custom Query (KQL)Tactic: Credential AccessUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Oct 8, 2026
- Version
- 4