Abuse of Kubernetes TokenRequest API for Credential Access

The Kubernetes TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on. Threat actors who have gained initial access to a cluster are abusing this API to mint tokens for highly privileged service accounts. This technique is particularly dangerous because, unlike traditional mounted service account tokens that rely on file access, TokenRequest tokens leave no filesystem footprint and are exclusively visible within Kubernetes audit logs via a create verb on the serviceaccounts/token subresource. Attackers leverage these tokens to pivot to cloud provider resources via IAM Roles for Service Accounts (IRSA) or other workload identity mechanisms, or to maintain persistence that survives pod termination. This behavior was documented as an emerging threat vector in Kubernetes environments, including managed services like EKS, AKS, and GKE.

Attack Chain

1. Attacker gains initial access to a containerized application within the Kubernetes cluster.
2. Attacker probes the cluster for RBAC permissions, specifically looking for 'create' authority on serviceaccounts/token.
3. Attacker identifies a high-privileged service account within the target or privileged namespaces.
4. Attacker invokes the TokenRequest API, targeting the chosen service account to mint a new token.
5. The API server validates the request and issues the short-lived bearer token directly to the attacker.
6. Attacker exfiltrates the generated token or uses it immediately to authenticate against the K8s API or external cloud provider APIs.
7. Attacker performs secondary actions, such as resource exfiltration, lateral movement, or persistence, using the minted identity.

Impact

Successful abuse of the TokenRequest API results in unauthorized privilege escalation, potential access to cloud provider resources linked to Kubernetes service accounts, and long-term persistence in the cluster. This threat impacts multi-tenant and cloud-hosted Kubernetes environments, allowing an attacker to operate with the permissions of a compromised service account without triggering file-integrity monitoring systems that typically guard against credential theft.

Recommendation

Detection engineering teams should prioritize the implementation of audit-based monitoring for API requests.

• Deploy the provided Sigma rule to monitor for suspicious TokenRequest API activity in Kubernetes audit logs.
• Review RBAC ClusterRoleBindings to identify identities possessing excessive permissions to the 'create' subresource on service accounts.
• Establish alerting for unauthorized user-agents or source IPs interacting with the TokenRequest API.
• Ensure that Kubernetes audit logs are being ingested into a centralized SIEM for timely detection of create verbs on serviceaccounts/token.