Contribution
This post adds original detection content: a three-stage alert chain that joins Kubernetes audit events, workload or service-account token use, and cloud data-plane access. Unit 42, Google Cloud and Microsoft each describe parts of that path; the contribution here is the join logic defenders can run before a stolen Kubernetes identity becomes a storage, database or wallet-theft incident.
The pattern
Kubernetes compromise is starting to look less like a container story and more like a cloud identity story. The pod is often the first visible system, but the attacker value sits in the identities mounted into that pod, the API rights behind those identities, and the cloud resources those rights can reach.
Unit 42's April 2026 research on current Kubernetes threats is the clearest signal. Its telemetry says Kubernetes-related threat actor operations, including Kubernetes token theft, increased 282% over the previous year. It also reports suspicious activity related to potential service-account token theft in 22% of cloud environments in 2025. Those are not abstract percentages for a cluster hardening deck. Unit 42 describes a case where a threat actor retrieved a high-privilege management service-account token, authenticated directly to the Kubernetes API server, enumerated secrets, interacted with workloads across namespaces, and then moved into wider cloud-hosted backend systems.
Google Cloud's H1 2026 Threat Horizons report gives the same shape from another angle. GTIG tracks UNC4899, a North Korean state-sponsored group, in a campaign against a cryptocurrency organisation. The intrusion began with social engineering against a developer, then moved from the corporate workstation into Google Cloud. The actors modified Kubernetes deployment configurations so new pods would run a backdoor command at startup. They also changed Kubernetes resources tied to the victim's CI/CD platform so service-account tokens were written into logs. Once they had a high-privilege CI/CD service-account token, they moved laterally, reached a privileged infrastructure pod, broke out of the container environment without necessarily using a kernel exploit, and extracted static database credentials from pod environment variables. The payoff was not 'cluster access'. The payoff was account modification and cryptocurrency theft.
Microsoft's Storm-2949 write-up is not a Kubernetes case, but it is useful confirmation of the cloud side of the pattern. Microsoft describes an Azure intrusion where the actor used management-plane operations, storage account keys, SAS tokens, Run Command and an attempted managed-identity token request through the Azure Instance Metadata Service. The common lesson is that workload execution becomes dangerous when it can mint, reveal or reuse cloud identities.
That is the pattern worth detecting: attacker-controlled workload execution, followed by token extraction or identity abuse, followed by cloud resource access from a path the original workload did not normally take. A pod event on its own is noisy. A storage read on its own can be normal. The join is where the signal lives.
Why it matters to cloud defenders
Kubernetes sits between application runtime and cloud control plane. That makes it awkward for teams whose logs live in separate places: Kubernetes audit logs in one system, cloud IAM logs in another, storage and database access somewhere else, and CI/CD events in yet another. Attackers benefit from that split. They can move from pod execution to token use before any single dashboard sees enough context to raise its hand.
The cloud relevance is direct. The Unit 42 and Google cases both show Kubernetes identities acting as the bridge from container compromise into backend cloud services. A service account with broad RBAC can enumerate secrets and workloads. A CI/CD service account can carry deployment rights that reach beyond one namespace. A privileged pod can reach node-level services or metadata paths that expose more identity material. Static database credentials in environment variables give the actor a second route once the service-account token expires.
For AWS teams, the equivalent risk often appears as a pod or runner using a role that can call STS, read S3 objects, update infrastructure, or fetch secrets. For Azure teams, it can be a workload that can reach managed identity endpoints, Key Vault, Storage, SQL, VM extensions or Run Command. For Google Cloud teams, it can be a GKE workload, CI/CD identity or service account that can impersonate another service account, read Cloud SQL credentials, access Secret Manager, or change workload configuration.
The first defensive mistake is to treat Kubernetes service-account token theft as a cluster-only event. It is better treated as a cross-plane identity incident. Ask three questions at once: what ran in the pod, what token or credential became available, and what cloud action followed from an identity that should not have touched that resource.
The second mistake is to wait for a container escape alert. Google notes that UNC4899 mimicked the impact of a host-level escape by abusing cluster admin privileges and a privileged pod. That matters because many teams anchor detection on exploit names or kernel signals. In this pattern, the actor can get the same operational result through control-plane permission misuse. If the alert is waiting for a kernel exploit, it may miss the path that actually happened.
ATT&CK mapping
The entry point can vary. Unit 42 includes public-facing application exploitation in Kubernetes workloads, including React2Shell activity, which maps to T1190, Exploit Public-Facing Application. Google describes social engineering against a developer and a trojanized Python application, but the cloud-relevant part starts when the actor moves into Kubernetes and identity material. For this article's technique list, T1190 is included for the exposed workload entry path because that page already has a hand-authored a13e answer box. The social-engineering portion stays in prose rather than adding a technique page that would not help this article's cloud detection angle.
The middle of the chain is T1528, Steal Application Access Token. Kubernetes service-account tokens and CI/CD service-account tokens are application identity material. Unit 42's case hinges on a high-privilege management service-account token. Google's UNC4899 case writes service-account tokens into logs, then uses one to authenticate to a sensitive infrastructure pod. The detection work should treat token appearance outside the expected mount path, token use from an unusual source, and sudden API calls by an automation identity as one family of events.
T1611, Escape to Host, belongs in the chain when a privileged pod or node-level service lets the actor leave the normal container boundary. Google is careful about the detail: forensic analysis suggested UNC4899 achieved host-like impact without necessarily using a kernel exploit. That distinction is useful. The observable signal may be privileged pod access, node service probing, hostPath mounts, container runtime sockets, kubelet interaction, or deployment changes that give the actor equivalent reach. Do not require a named exploit to map the behaviour.
The payoff is T1530, Data from Cloud Storage Object, when the actor uses the stolen or abused identity to read object storage, database exports, backup locations or other cloud-hosted data stores. Microsoft's Storm-2949 report shows the Azure version clearly: the actor abused storage account keys and SAS tokens, then used a custom Python script with the Azure SDK for Storage to enumerate and download blobs. Unit 42 and Google show the Kubernetes path to the credentials and roles that make that kind of access possible.
The article deliberately does not list every adjacent technique. Kubernetes and cloud intrusions can also involve account discovery, secret discovery, valid cloud accounts, cloud instance metadata API access, persistence through deployment modification, and automated collection. Those belong in the investigation notes, but the listed techniques are the ones a defender can turn into a concise cross-plane detector without minting thin coverage.
Detection guidance
Start with a three-stage correlation. Stage one is workload execution or configuration drift in Kubernetes. Useful log sources are Kubernetes audit logs, admission-controller logs, container runtime events, CI/CD deployment logs, and cloud workload logs. Look for deployment patches that add startup commands, image changes to unexpected registries, new privileged pods, new hostPath mounts, service-account token volume changes, exec into pods that normally do not receive interactive sessions, and reads of Kubernetes secrets by identities that usually deploy rather than inspect.
Stage two is token or identity misuse. In Kubernetes audit logs, watch for create token, secret reads, broad list or watch calls across namespaces, selfsubjectaccessreviews, and sudden API activity by a service account outside its normal namespace or controller pattern. In CI/CD logs, watch for a pipeline identity being used outside a release window, a new job that prints environment variables, or a workflow step that sends token-shaped strings to logs. In cloud IAM logs, look for service-account impersonation, STS token issuance, role assumption, setIamPolicy, listKeys, GetCallerIdentity, Key Vault secret reads, Secret Manager access, or permissions checks from a source that lines up with the suspect workload.
Stage three is the data payoff. In AWS, that means S3 GetObject, ListBucket, snapshot export, Secrets Manager reads, or unusual KMS decrypts after the identity event. In Azure, watch Storage blob enumeration, SAS token use, listkeys/action, Key Vault reads, SQL export and VM Run Command sequences. In Google Cloud, watch Cloud Storage object reads, Cloud SQL access through an unexpected workload, Secret Manager reads, service-account impersonation followed by storage access, and audit-log gaps around Kubernetes deployment mutation.
The high-confidence alert is not any one of those events. It is the sequence: Kubernetes workload or deployment drift, then service-account or workload identity use from a new source, then cloud data access or secret retrieval. Time-box the join tightly at first, for example 30 to 120 minutes, then tune by deployment cadence. Add context for namespace, service account, cloud project or subscription, repository, runner, ASN, device posture and workload owner.
A practical rule for triage: if the identity has not used that cloud API in the last 30 days, or if the source workload has never touched that data store before, raise severity. If the same service account normally runs deployments every weekday and the event sits inside a signed release, lower severity but still keep the chain for review. Most false positives will be release automation, backup jobs, migration scripts and incident-response drills. Name those workflows explicitly, tag their owners, and expire exceptions.
Do not make the detector depend on a specific malware filename, CVE or tool. Unit 42 notes that threat activity in Kubernetes environments often mirrors public post-exploitation frameworks rather than relying on novel tooling. Google describes configuration changes, token leakage and cloud-native movement. Microsoft shows normal Azure management functions doing attacker work. The durable signal is permission use outside the identity's job, not the wrapper around it.
What to do now
First, inventory Kubernetes service accounts that can read secrets, list workloads across namespaces, create pods, patch deployments, mount host paths, or interact with CI/CD controllers. Pair each one with the cloud identity it can reach. If nobody can answer that mapping, the detection join above will be hard to run during an incident.
Second, reduce the blast radius before the next alert. Disable automounting service-account tokens where workloads do not need the API server. Move static credentials out of pod environment variables. Use short-lived workload identity patterns where possible. Keep CI/CD roles narrow enough that a deployment identity can update the service it owns without creating new administrator roles, reading unrelated storage, or pulling database credentials.
Third, build one correlation view across Kubernetes audit, CI/CD logs and cloud audit logs. It does not have to be elegant. A daily job that joins service account, namespace, project or subscription, repository, source IP and cloud API method is enough to expose new edges. The first useful output is a list of workload identities that touched a new secret store or data bucket after a deployment change.
Fourth, rehearse the response. If a Kubernetes service-account token is exposed, rotate the token or restart the affected pods, revoke related CI/CD credentials, review cloud role sessions, and check storage, database and secret-access logs for follow-on reads. If the service account reached cloud data, treat it as a cloud incident, not a container hygiene ticket.
The sources point in the same direction. Unit 42 shows Kubernetes token theft and exposed workloads moving into cloud-hosted systems. Google shows a Kubernetes and CI/CD path ending in cloud control-plane manipulation and financial theft. Microsoft shows workload and management-plane identity paths ending in Azure storage exfiltration. The defender move is to join those planes before the attacker does.