Kubernetes Service Account Token Theft and API Abuse

Adversaries are actively targeting Kubernetes environments by exploiting interactive container sessions to harvest sensitive service account credentials. Attackers gain initial access to a pod (e.g., via kubectl exec) and proceed to read the service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and the CA certificate (ca.crt). These artifacts provide the necessary credentials to authenticate to the Kubernetes API server as the pod's service account. Once authenticated, the attacker performs unauthorized API requests to conduct cluster reconnaissance, exfiltrate secrets, or attempt lateral movement by escalating privileges or pivoting to other nodes. This activity is notable because it leverages native, legitimate application paths to bypass traditional perimeter security, making correlation between container-level file access and cluster-level audit logs essential for detection.

Attack Chain

1. An attacker gains initial interactive access to a container, often through a compromised application or misconfigured pod (kubectl exec).
2. The attacker performs a file read operation on the service account token located at /var/run/secrets/kubernetes.io/serviceaccount/token.
3. The attacker reads the associated CA certificate at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt to facilitate TLS communication.
4. Using the harvested token, the attacker interacts with the Kubernetes API server, typically via curl, kubectl, or custom scripts.
5. The API server processes the request, authenticating the attacker as the pod's service account.
6. The attacker performs reconnaissance, such as listing pods, secrets, or nodes within the cluster.
7. If the service account possesses excessive RBAC permissions, the attacker pivots to other namespaces, modifies RoleBindings, or creates privileged pods to compromise the wider cluster.

Impact

Successful exploitation allows an adversary to impersonate a service account, potentially leading to full cluster compromise. Depending on the service account's RBAC scope, this can result in the exfiltration of sensitive configuration secrets, unauthorized deployment of malicious containers, or total administrative takeover of the Kubernetes environment.

Recommendation

1. Deploy the provided detection logic to correlate container file access events with Kubernetes audit logs.
2. Implement a policy of least privilege by scoping service account RBAC bindings strictly to the resources required by the application.
3. Disable automountServiceAccountToken on all pods that do not require interaction with the Kubernetes API.
4. Enforce Pod Security Admission policies to restrict or eliminate the use of interactive shells (exec/attach) within production containers.
5. Monitor Kubernetes audit logs specifically for anomalous verbs or user-agents associated with service accounts, especially those requesting secrets or creating pods in foreign namespaces.