[DEEP RESEARCH] The Container Was Not the Prize. The Token Was.

The core judgment is simple: Kubernetes service-account tokens are becoming a repeatable post-exploitation pivot because they turn code execution inside a pod into authenticated authority. The token is not automatically a cluster-admin or cloud-admin key. Its value comes from what Kubernetes RBAC, workload federation, cloud IAM, reachable credentials, and network paths allow it to do next.

That distinction matters for defenders. A container alert often lands as an application or runtime problem while the decisive evidence is already moving through identity systems. The practical payoff is a cleaner investigation model: trace execution → token access → permission testing → Kubernetes expansion → cloud activity.

The container gets the headline. Authority determines the blast radius.

TL;DR

• A mounted service-account token is an attack-graph edge, not a universal master key.
• Unit 42 reported a 282% year-over-year increase in Kubernetes-related threat-actor operations, including token theft, and suspicious activity related to potential service-account-token theft in 22% of cloud environments. Those figures describe alerts and suspicious paths, not confirmed compromise in 22% of tenants.
• Short-lived projected tokens reduce replay and persistence, but they do not stop an attacker controlling a live pod from using the pod’s valid identity.
• The dangerous permissions are broader than cluster-admin: Secret access, workload creation, token requests, RBAC mutation, impersonation, nodes/proxy, and permissive cloud federation can all extend authority.
• Defenders get leverage by removing unnecessary tokens, narrowing effective permissions, and correlating runtime, Kubernetes audit, and cloud identity telemetry.

The key judgment

Kubernetes service-account tokens are increasingly useful to attackers because the post-RCE workflow is predictable and automatable. A compromised process can inspect known credential paths, call the Kubernetes API as the workload, test its permissions, and decide quickly whether the identity is worth expanding.

Observed: Unit 42 reported token-theft-related Kubernetes alert volume rising from 122,465 in 2024 to 467,658 in 2025. It also reported suspicious activity related to potential service-account-token theft in 22% of cloud environments during 2025.

Observed: in a cryptocurrency-exchange intrusion described by Unit 42, an attacker used a malicious pod carrying a high-privilege management ServiceAccount to authenticate to Kubernetes, enumerate Secrets, interact across namespaces, backdoor a production workload, and reach cloud-hosted backends and financial systems.

Assessed: workload identity is becoming a standard decision point after pod compromise, especially where public-facing applications, automation identities, and cloud federation meet.

Unknown: how often suspicious token-access alerts progress beyond permission testing into verified cluster or cloud impact.

Confidence: high that the path is operationally repeatable; moderate that its prevalence across ordinary enterprise environments matches the strongest alert-growth signals.

Why the token matters more than container escape

The common trap is to frame every pod compromise as a race toward container escape. Escape remains serious, but an attacker may not need a kernel exploit when the workload already carries legitimate authority.

The chain is usually less cinematic:

1. Application exploitation provides execution inside the pod.
2. The attacker finds a projected token, kubeconfig, Secret mount, cloud credential file, or metadata path.
3. The identity tests Kubernetes permissions through discovery, authorization reviews, denied calls, or broad listing.
4. Useful access opens Secrets, workloads, other ServiceAccounts, RBAC objects, or persistence paths.
5. Federation, static credentials, metadata access, or backend connectivity extends the compromise into cloud services.

A projected token is a short-lived badge. Rotation limits how long it can be replayed. It does not stop someone already inside the building from using it while it remains valid.

Practical gut-check: after a webshell alert in a pod, can your team name the ServiceAccount, its effective RBAC, its cloud identity, and every API action it performed?

The permissions that turn identity into reach

Reviewing only cluster-admin misses the practical escalation surface.

• get, list, or watch on Secrets can expose credential material. Secret listing is credential access in practice.
• Creating Pods, Jobs, Deployments, or other workloads can let an identity mount accessible Secrets or run under another ServiceAccount in the namespace.
• create on serviceaccounts/token can mint credentials for an existing ServiceAccount.
• bind, escalate, and impersonate directly expand authority.
• RoleBinding and ClusterRoleBinding changes can convert a constrained token into a broader identity.
• Admission-webhook control can inspect or alter workloads at scale.
• nodes/proxy can expose kubelet APIs and bypass controls defenders may assume are in the path.
• Cross-namespace rights turn one compromised application into a lateral-movement position.

The cloud pivot is conditional. A Kubernetes token normally authenticates to the Kubernetes API; it does not automatically administer AWS, Azure, or Google Cloud. The path continues only when federation, cloud IAM, metadata services, static credentials, Secrets, or reachable backends make the authority transitive.

Below the tear line: the attack sequence, the telemetry needed to reconstruct it, provider-specific cloud pivots, and a 30-day plan for breaking the RCE-to-identity path.

We also include the technical deep dive this newsletter was based on.

Which Kubernetes identity in your environment would create the most uncomfortable answer if its pod were compromised today?

Detect the sequence, not one token read

A token-file read alone is noisy. Kubernetes-aware applications and workload-identity libraries may legitimately read projected tokens. The stronger analytic joins behavior across layers.