IL-0069 Unnamed cryptocurrency exchange · 2026-04-06 (published)kubernetessecurity
Unit 42, the threat research team of Palo Alto Networks, published a survey of current attacks on Kubernetes with two case studies. This case covers the first and most concrete one: an intrusion at a cryptocurrency exchange in mid-2025, which Unit 42 connects to a campaign by the North Korean state-sponsored group Slow Pisces, also known as Lazarus and TraderTraitor. The second case study, about attacks using the React2Shell vulnerability (CVE-2025-55182), describes activity across many environments rather than one incident.
The attacker spearphished a developer and gained persistence on the developer's workstation. Using the developer's live, privileged cloud session, the attacker deployed a pod to the production cluster that exposed the service account token mounted into it. That token belonged to a highly privileged management service account with broad RBAC permissions, used by a common CI/CD automation and cluster orchestration system.
With the token, the attacker authenticated directly to the Kubernetes API server, listed secrets, worked with workloads across namespaces and put a backdoor into a production pod to keep access. The same privileges let the attacker move out of Kubernetes into the wider cloud platform, reach the exchange's cloud-hosted backend systems, collect sensitive credentials and finally reach its financial infrastructure. Millions in cryptocurrency were stolen. Unit 42 found no sign of a specific offensive toolkit, but the steps match techniques described in Kubernetes security research and modelled by penetration testing tools such as Peirates.
Inside the cluster the attacker left these traces: a new pod appeared in the production Kubernetes cluster that was built to expose its mounted service account token; requests authenticated as a broad management service account listed secrets and touched workloads in many namespaces; and a backdoor was placed in a running production pod.
Unit 42 lists the traces that this kind of attack leaves in general, not specifically at this exchange. In Kubernetes audit logs: attempts to change ClusterRoleBindings, service account tokens used from unusual IP addresses, and pods appearing in sensitive namespaces. At runtime: unexpected shells or utilities in a workload, sustained high CPU from cryptomining, outbound connections to unfamiliar destinations, and curl or wget reading /var/run/secrets/kubernetes.io/serviceaccount/token.
Root cause ? Credential exposure
–
–
–
Unit 42 concludes that a single over-privileged identity turned one malicious pod into cluster-wide and then cloud-wide access. Its recommendations are least-privilege RBAC with the Restricted Pod Security Standard, short-lived projected service account tokens bound to the pod's lifetime, runtime monitoring of what containers actually do, and Kubernetes audit logging so that identity-driven changes can be seen and reconstructed.
–