Service-Account Token Theft

Executive Summary

Kubernetes service accounts provide workloads with identities that can be used to authenticate directly to the Kubernetes API. When attackers compromise a workload, the mounted service-account token can instantly become the most valuable artifact inside the container.

Recent Unit 42 research provides a documented real-world example of this exact attack pattern. After gaining access to a developer's environment, a threat actor used an active privileged cloud session to deploy a malicious pod into a production Kubernetes cluster. The pod was designed to expose its mounted service-account token. The stolen token belonged to a highly privileged management account with broad RBAC permissions. The attacker subsequently authenticated to the Kubernetes API, enumerated secrets and workloads, established persistence, and pivoted out of Kubernetes into the broader cloud environment.

Kubernetes Identity Model

The security consequence of token theft depends heavily on the RBAC permissions attached to that specific service account.

Documented Attack Sequence

The Unit 42 case followed a sophisticated multi-stage sequence. Because the token belonged to a management service account, the actor could freely enumerate secrets across namespaces and deploy a backdoor into a live production pod.

Why the Token Was Valuable

The token itself was not necessarily a vulnerability; the problem was the excessive authority permanently attached to the identity. Token + RBAC permissions = Effective authority.

A stolen low-privilege token may provide little value. A stolen management token provides untethered access to pods, secrets, namespaces, cluster resources, and cloud-integrated services. The fundamental risk is not merely credential theft—it is credential theft strictly combined with broad authorization scope.

Kubernetes → Cloud Pivot

The most important aspect of the documented case is that Kubernetes was not the attacker's final destination. The attacker specifically used Kubernetes credentials to access broader infrastructure and ultimately reach sensitive cloud-hosted systems.

Detection-Relevant Behavior

MITRE's detection guidance for stolen application/container tokens describes a precise sequence in which a service-account token is retrieved from the container filesystem and subsequently used to make unauthorized Kubernetes API requests.

The individual events may be completely legitimate. Their combined sequence is the irrefutable indicator of identity abuse.

Analyst Assessment

This threat demonstrates the massive architectural gap between traditional host compromise and cloud-native compromise.

The workload's identity intrinsically becomes part of the attack surface. This is why Kubernetes runtime security cannot be reduced to process monitoring alone.

Opsonance Point of View

The Opsonance perspective is strictly centered on the transition between runtime behavior and identity use. A workload legitimately reading /var/run/secrets/kubernetes.io/serviceaccount/... is uninteresting. But an unexpected process reading that token, triggering Kubernetes API authentication, and moving externally to the cloud is a critical chain.

The deeper principle is: A workload's identity must be evaluated continuously against the runtime behavior that is actively using it.

Key Finding

References

• Palo Alto Networks Unit 42 — Understanding Current Threats to Kubernetes Environments
• MITRE ATT&CK — Detection Strategy for Application Access Token Theft