Hackers are using Kubernetes misconfigurations to move from containers into cloud accounts

A Kubernetes breach can turn into a much bigger cloud compromise if the cluster is set up poorly. New research from Unit 42 says attackers now abuse weak Kubernetes identities, mounted service account tokens, and overly broad permissions to move from a compromised container into cloud services, backend systems, and other sensitive infrastructure.

The short answer is yes, this is a serious risk. Unit 42 says Kubernetes-related threat activity, including service account token theft, increased by 282% over the last year. The company also says suspicious activity tied to possible service account token theft appeared in 22% of cloud environments in 2025, with the IT sector accounting for more than 78% of observed activity.

What makes these attacks dangerous is how little attackers may need at the start. Once they gain code execution inside a pod through an app flaw, stolen developer access, or another entry point, they can inspect the runtime, extract the pod’s credentials, and check what the Kubernetes API will allow them to do.

How the attack works

Kubernetes uses service accounts to give workloads an identity. The official documentation says a service account provides an identity for processes that run in a pod, and those credentials let workloads authenticate to the Kubernetes API server. That is normal behavior, but it becomes dangerous when a compromised pod has access to a powerful token.

According to Unit 42, attackers often follow a repeatable pattern. They get execution inside a container, harvest the mounted service account token, query the Kubernetes API to test permissions, and then pivot toward more valuable systems. In some cases, they also collect cloud credentials exposed through environment variables or cloud metadata services.

That means the breach does not need to stop at one container. A weakly scoped token can let an attacker enumerate secrets, inspect workloads across namespaces, and move toward the cloud account or backend services behind the cluster.

Real-world cases show the risk

Unit 42 says one of the clearest examples involved a cryptocurrency exchange tied to activity from Slow Pisces, a North Korean threat group also tracked as Lazarus and TraderTraitor. In that case, attackers reportedly gained access through a developer’s privileged cloud session, deployed a malicious pod into production, exposed the mounted service account token, and used that identity to move deeper into internal systems.

The researchers say the intrusion then moved beyond the cluster itself. The attackers reached backend systems and financial infrastructure, showing how Kubernetes identity abuse can become a broader cloud compromise instead of a limited container incident.

A second case involved React2Shell, tracked as CVE-2025-55182. Unit 42 says exploitation targeting cloud services started within two days of public disclosure. After gaining code execution inside application containers, attackers harvested service account tokens, queried Kubernetes APIs, and pivoted into cloud accounts to install backdoors, steal credentials, and deploy cryptominers.

Key findings at a glance

Finding	Why it matters
Kubernetes threat activity rose 282%	Attackers are targeting clusters far more aggressively
22% of cloud environments showed suspected token theft activity in 2025	Service account abuse is now a mainstream cloud risk
Attackers steal mounted service account tokens	A compromised pod can become a launch point for wider access
Cloud credentials may also be exposed in runtime environments	The intrusion can spread from Kubernetes into the cloud account
React2Shell exploitation began within two days of disclosure	Public app flaws can quickly turn into Kubernetes compromises

Why service account tokens matter so much

The core issue is trust. Kubernetes treats the token mounted into a pod as a valid identity, and the API server will honor that identity within its granted permissions. If teams assign broad RBAC rights or leave sensitive credentials too exposed, attackers can abuse legitimate access instead of relying on noisier exploits.

Kubernetes documentation also shows that teams can use projected service account tokens, which support more controlled token use. That matters because long-lived or overly permissive credentials increase the value of any token stolen from a compromised container.

In simple terms, one vulnerable app can become the first step in a much larger breach. Attackers no longer need to “break out” in the traditional sense if the cluster already gives them enough trusted access to move forward.

What defenders should do now

Security teams should review service account permissions first. Least privilege RBAC remains the most important control because it limits what an attacker can do after stealing a token. Unit 42 recommends avoiding wildcard permissions and tightening access across service account roles.

Teams should also replace long-lived static tokens with short-lived projected tokens where possible. Kubernetes documentation supports projected service account tokens as a more controlled approach, which reduces the impact if an attacker manages to extract one from a pod.

Logging and runtime visibility also matter. Unit 42 says Kubernetes audit logs can expose early signs of API misuse, token access, and lateral movement across namespaces. The researchers also recommend runtime monitoring for suspicious process execution, unexpected outbound traffic, and access to sensitive paths inside containers.

Immediate hardening steps

• Review all service account permissions and remove broad RBAC grants.
• Replace long-lived static tokens with short-lived projected tokens.
• Check which pods can access secrets, metadata services, and cloud credentials.
• Enable and review Kubernetes audit logs regularly.
• Watch containers for unusual shell execution, downloads, and outbound network activity.
• Patch public-facing applications quickly, especially remote code execution flaws that can lead straight into pods.

FAQ