Google Details Suspected UNC4899 Cloud Compromise That Stole Millions from Crypto Firm
Summary
Google’s H1 2026 report describes a suspected UNC4899 2025 compromise: a developer AirDropped a trojanized archive to a work device, enabling cloud access and Kubernetes/DevOps abuse before attackers altered accounts and withdrew millions in crypto.
Key points
- Google attributed the 2025 activity to UNC4899 with moderate confidence; the actor is also tracked as Jade Sleet, PUKCHONG, Slow Pisces, and TraderTraitor.
- The attack reportedly began with social engineering that led a developer to transfer an archive from a personal device to a work device using AirDrop.
- After the developer executed embedded malicious Python code, a binary disguised as the Kubernetes command-line tool acted as a backdoor.
- The attackers reportedly abused DevOps workflows and Kubernetes deployments to expose service-account tokens, escalate privileges, and maintain access.
- They obtained database credentials stored in pod environment variables and used Cloud SQL Auth Proxy to modify high-value accounts, including passwords and MFA seeds.
- The compromise reportedly culminated in the withdrawal of several million dollars in digital assets.
- Google recommended restricting peer-to-peer file transfers, enforcing phishing-resistant MFA, using trusted images and robust secrets management, and monitoring unexpected container processes.
Article Details
- Attack Vectors
- Social engineering led a developer to download an archive presented as part of an open-source project collaboration and transfer it from a personal device to a work device using AirDrop.
- The developer executed embedded malicious Python code, which launched a binary disguised as the Kubernetes command-line tool; the binary contacted an attacker-controlled domain and provided a backdoor.
- The attackers used authenticated sessions and available credentials to pivot into Google Cloud, then altered a bastion host's MFA policy attribute.
- They modified Kubernetes resources and deployments to expose service-account tokens in logs, run commands in newly created pods, and deploy backdoors; a stolen privileged service-account token was used to escape a container.
- The attackers extracted database credentials stored in pod environment variables, accessed the production database through Cloud SQL Auth Proxy, and changed account passwords and MFA seeds before withdrawing digital assets.
- Defensive Notes
- Use context-aware access and phishing-resistant MFA.
- Restrict peer-to-peer file sharing, including AirDrop and Bluetooth, and the mounting of unmanaged external media on corporate devices.
- Deploy only trusted images and enforce strict isolation in cloud runtime environments.
- Isolate compromised nodes from external connectivity and monitor for unexpected container processes.
- Use robust secrets management and avoid insecurely storing credentials in pod environment variables.
MITRE ATT&CK
T1059.004 · Unix ShellA bash command was configured to execute automatically when new Kubernetes pods were created.T1059.006 · PythonEmbedded malicious Python code was executed on the developer's work device.T1078.004 · Cloud AccountsThe attackers likely pivoted into Google Cloud using authenticated sessions and available credentials, and later used a stolen service-account token to access infrastructure.T1098 · Account ManipulationThe attackers modified high-value customer accounts by resetting passwords and updating MFA seeds.T1204.002 · Malicious FileThe developer executed the archive's embedded malicious code, which launched a binary disguised as the Kubernetes command-line tool.T1526 · Cloud Service DiscoveryThe attackers conducted reconnaissance to gather information about cloud services and projects.T1552.001 · Credentials In FilesThe attackers extracted static database credentials that were insecurely stored in a pod's environment variables.T1556.006 · Multi-Factor AuthenticationThe attackers modified a bastion host's MFA policy attribute to gain access.T1565.001 · Stored Data ManipulationThe attackers used SQL commands through Cloud SQL Auth Proxy to alter production database account records.T1609 · Container Administration CommandThe attackers modified Kubernetes resources associated with the victim's CI/CD platform to inject commands that exposed service-account tokens in logs.T1610 · Deploy ContainerThe attackers altered Kubernetes deployment configurations and deployed backdoors in pods for persistence.T1611 · Escape to HostThe attackers used a stolen privileged service-account token to access a privileged infrastructure pod, escape its container, and deploy a backdoor.T1613 · Container and Resource DiscoveryThe attackers navigated Kubernetes pods during reconnaissance and targeted specific workload pods.
Threat Actors
Vendors
Products
AirDropThe attack began with social engineering and an archive file transferred from a developer’s personal device via AirDrop.Cloud SQLto compromise a developer, then pivoted to the cloud—abusing DevOps workflows, Kubernetes, and Cloud SQL to harvest credentials, tamper with accounts, and withdraw funds.Google CloudThe attack chain, Google Cloud said, represents a progression of what started with the compromise of a developer’s personal device to their corporate workstation, before jumping to the cloud to make unauthorizedKubernetesP2P transfers to compromise a developer, then pivoted to the cloud—abusing DevOps workflows, Kubernetes, and Cloud SQL to harvest credentials, tamper with accounts, and withdraw funds.