Kubernetes is the industry standard for cloud-native workloads. Its ubiquity invites cyberattackers to exploit its vulnerabilities. The orchestration layer behind the modern cloud is facing not only a massive increase in the number of attacks but also increasingly sophisticated cyber threats.
The number of Kubernetes-based attack attempts has increased by 282 percent in just one year. Palo Alto Networks’ Unit 42 reports that the IT sector is by far the hardest hit in this area. 78 percent of all malicious activity targets this sector. The targets are selective, such as crypto exchanges. While the well-known Bybit was compromised via AWS tokens in early 2025, Unit 42 discovered a breach of another crypto exchange via Kubernetes credentials.
Why Kubernetes?
Before we dive deeper into the case studies, it’s important to emphasize that this development is only logical. Kubernetes is a globally used standard for orchestrating large-scale applications in the cloud. Despite this adoption, now almost a given regardless of the cloud provider, security has never been inherently built into the technology. Instead, it relies on solutions that secure credentials and ensure isolation.
Attackers are increasingly targeting the identities running within Kubernetes clusters. These are the so-called service account tokens. These tokens grant pods access to the Kubernetes API. Anyone who obtains such a token may have direct access to the entire cluster infrastructure. In 22 percent of cloud environments in 2025, suspicious activity indicative of token theft was detected, according to Unit 42.
Crypto exchange compromised via malicious Kubernetes pod
We return to the previously mentioned breach of the crypto exchange in mid-2025, observed by security researchers at Palo Alto Networks. The attack is linked to Slow Pisces, also known as Lazarus or TraderTraitor. It is a North Korean state-sponsored group with financial motives. Because crypto coins can be stolen as entire wallets, platforms like Bybit and the exchange affected later are extremely attractive targets.
Through spearphishing, the attacker gained access to a developer’s workstation. He then exploited that employee’s active, privileged cloud session to deploy a malicious pod in the production Kubernetes cluster.
That pod was specifically designed to expose the mounted service account token. The token turned out to belong to an administrative account with extensive privileges, used by a CI/CD system via role-based access control. Using that identity, the attacker authenticated directly with the Kubernetes API server, intercepted secrets, was able to tamper with workloads across multiple namespaces, and planted a backdoor in a production pod. The attacker then moved through the network toward the exchange’s financial infrastructure, stealing millions in cryptocurrency.
Slow Pisces had previously been linked to the aforementioned Bybit hack from February of last year. At that time, approximately $1.5 billion worth of Ethereum was stolen. As of this writing, it is the largest digital theft in history. In May 2025, an attack followed on the Taiwanese crypto exchange BitoPro, again via social engineering and stolen AWS tokens.
React2Shell: attacks within two days of disclosure
A second case cited by Unit 42 concerns CVE-2025-55182, also known as React2Shell. This vulnerability in React Server Components was disclosed on December 3. Targeted attacks on cloud services followed soon after, specifically between December 5 and 7. Due to insecure deserialization in the RSC Flight protocol, attackers could execute arbitrary code in application containers behind ingress controllers and cloud load balancers.
Once inside the pod, all doors were open. In other words, access could be gained to the file system, environment variables, network information, and mounted identities. Attackers used that access to steal service account tokens, extract cloud credentials from environment variables, and move on to the underlying cloud account.
In multiple cases, cryptominers were installed, backdoors were placed, and database credentials were stolen. It is not unusual for attacks to follow a disclosure so quickly: research by Wiz shows that AKS clusters are attacked on average within 18 minutes of creation, and EKS clusters within 28 minutes.
Familiar tools, recognizable pattern
In these compromises, attackers “neatly” follow the MITRE ATT&CK framework. First, initial access via a vulnerability (T1190) or social engineering, followed by token theft (T1528). Using the stolen service account token, attackers maneuver within the cluster and escalate privileges. So the attacks aren’t that unique, but the enormous scope of Kubernetes makes a compromise via this infrastructure extremely widespread.
Frameworks such as Peirates, originally built for red teams, significantly aid the attackers. Peirates can create and query service accounts, secrets, and cloud metadata. Unit 42 points to multiple groups that, among other things, build special plugins into their malware to retrieve large amounts of sensitive data with minimal activity.
Kubernetes has several critical vulnerabilities that attackers exploit, with misconfigurations in RBAC and pod security settings being the most common entry points. Although these issues have been known for years, they remain the most common methods attackers use to succeed.
Three measures to disrupt the attack path
Unit 42 outlines three concrete steps for defenders. First: strict RBAC policies based on least privilege. Wildcard permissions allow attackers to access critical cluster resources through a single compromised pod. That one overly permissive account is often the deciding factor in large-scale attacks.
Second, Unit 42 recommends giving service account tokens a short lifespan. These tokens are typically valid indefinitely (!), which is ideal for attackers who take their time and go to great lengths to remain undetected. Gradually, they gather enough information to gain deep access without being noticed. By properly tying tokens to the lifespan of a pod, a stolen token quickly loses its value.
Third, it is important to run continuous runtime monitoring via an XDR platform. These solutions detect abnormal process behavior, unexpected network connections, and access to sensitive paths such as `/var/run/secrets/kubernetes.io/serviceaccount/token`. Audit logging is also often neglected, allowing attackers to remain undetected and leaving post-incident investigations lacking crucial information.
Unit 42 is highlighting this sore spot in Kubernetes this time, but it has recently identified many other cyber threats. Previously, the team published research on bypassing AI guardrails and mapped the impact of Iranian cyberattacks.