{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/tokenrequest/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","credential-access","tokenrequest","cloud"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies the creation of Kubernetes service account tokens through the TokenRequest API by non-system identities. The TokenRequest API enables programmatic generation of short-lived tokens for service accounts, circumventing filesystem access or mounted projected tokens. Attackers gaining initial cluster access can exploit this API to mint tokens for highly privileged service accounts, enabling lateral movement to cloud provider resources (IRSA/workload identity) or creating persistent tokens. Unlike mounted service account tokens detectable via filesystem monitoring, tokens created via TokenRequest API lack a filesystem footprint, appearing solely in Kubernetes audit logs as a \u0026lsquo;create\u0026rsquo; verb on the \u0026lsquo;serviceaccounts/token\u0026rsquo; subresource. The rule excludes legitimate system components (kubelet, kube-controller-manager, cloud provider managed identities such as EKS, AKS, and GKE) that create tokens for pod lifecycle management.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target service account with elevated privileges or access to cloud resources via IRSA.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the Kubernetes TokenRequest API to request a new token for the target service account. The request specifies the service account\u0026rsquo;s namespace and name.\u003c/li\u003e\n\u003cli\u003eKubernetes API server validates the request and confirms the attacker\u0026rsquo;s identity has permissions to create tokens for the target service account.\u003c/li\u003e\n\u003cli\u003eIf authorized, the API server generates a new service account token. The creation event is logged in the Kubernetes audit logs with the \u003ccode\u003ecreate\u003c/code\u003e verb on the \u003ccode\u003eserviceaccounts/token\u003c/code\u003e subresource.\u003c/li\u003e\n\u003cli\u003eThe attacker receives the generated token, which has a limited lifespan.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly acquired service account token to authenticate to the Kubernetes API server, cloud provider APIs, or other services, impersonating the target service account.\u003c/li\u003e\n\u003cli\u003eThe attacker performs privileged actions or accesses sensitive data, leveraging the permissions associated with the target service account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to escalate privileges within the Kubernetes cluster and potentially pivot to cloud provider resources. By minting tokens for service accounts linked to IAM roles (IRSA in AWS, workload identity in Azure and GCP), attackers can gain unauthorized access to cloud services, potentially leading to data breaches, resource hijacking, and service disruption. This can affect any organization using Kubernetes, especially those relying on cloud-managed Kubernetes services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes TokenRequest API Token Creation by Non-System Account\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview RBAC permissions to restrict \u003ccode\u003ecreate\u003c/code\u003e access to \u003ccode\u003eserviceaccounts/token\u003c/code\u003e subresource only to legitimate system components.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for \u003ccode\u003ecreate\u003c/code\u003e operations on \u003ccode\u003eserviceaccounts/token\u003c/code\u003e resources, focusing on unusual source IPs or user agents as highlighted by the Sigma rule above.\u003c/li\u003e\n\u003cli\u003eInvestigate and rotate affected service account credentials if unauthorized token creation is detected, especially for IRSA-linked service accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-12T08:17:19Z","date_published":"2026-05-12T08:17:19Z","id":"https://feed.craftedsignal.io/briefs/2026-05-kubernetes-tokenrequest/","summary":"The rule detects the creation of Kubernetes service account tokens through the TokenRequest API by non-system identities, which can be abused to escalate privileges, pivot to cloud resources, or generate persistent tokens, bypassing file system-based detection.","title":"Kubernetes Service Account Token Created via TokenRequest API by Non-System Identity","url":"https://feed.craftedsignal.io/briefs/2026-05-kubernetes-tokenrequest/"}],"language":"en","title":"CraftedSignal Threat Feed — Tokenrequest","version":"https://jsonfeed.org/version/1.1"}