From an AirDrop to the cloud: the living- off- the- cloud attack that emptied millions in crypt

A sophisticated attack directed at a cryptomoneda ecosystem company has again highlighted how an intrusion that begins in a developer's personal device can end up emptying portfolios for millions of dollars in a cloud environment. According to Google Cloud's semi-annual cloud threat report, attributed with a moderate level of confidence to a group linked to North Korea (tracked under acronyms such as UNC4899 among others), the campaign combined social engineering, abuse of personal-to-corporate transfer mechanisms and pivoting techniques of the call living-off-the-cloud to scale privileges and manipulate financial logic in production ( H1 2026 Cloud Threat Horizon Report).

The point of entry was simple, but effective: the attackers impersonated as collaborators of an open source project and managed to get the developer to download an apparently legitimate compressed file. The same file went from personal phone to corporate team via AirDrop, and was opened within an IA-assisted development environment. The malicious embedded Python code was then executed and deployed a binary that imitated the Kubernetes command line tool, providing a silent back door to the corporate machine.

From that committed machine the attackers collected sessions and credentials available to move to the cloud environment. In an initial phase they made recognition of the projects and services undercut to find a more critical entry door: a base host that, after modifying attributes related to multifactor authentication, allowed them to deepen in concrete pods of the Kubernetes cluster ( What is a base host).

The way operators maintained their presence and the ease with which they pivoted within the environment illustrates why defenders talk about living from the cloud: they modified deployment configurations so that, each time a pod was created, a bash command capable of downloading and running a backdoor was automatically executed. At the same time, they introduced changes in resources linked to the CI / CD platform to record tokens of service accounts on the logs, allowing them to appropriate a high privilege token and use it to move laterally to pods with high permissions and privileged modes of execution.

With this privileged access, the attackers managed to escape the container and deploy persistence in sensitive infrastructure. They later focused their efforts on a workload that stored customer information: identifiers, security configurations and data associated with portfolios. There they extracted static credentials that were in environment variables and used them to connect to the production database using the Cloud SQL proxy, where they made account changes (password restoration and MFA seed update) to finally get control of high-value accounts and remove several million in digital assets.

The incident contains several lessons that are not new but persistent: personal-to-corporate transfers (AirDrop, Bluetooth, unmanaged removable means) continue to be dangerous input vectors; containers executed in privileged mode amplify potential damage; and the handling of secrets in clear text or in environment variables continues to facilitate climbing and exfiltration when it falls into the wrong hands. That is why the authors of the report recommend an in-depth approach that combines identity controls, data bridge restrictions and strict isolation in the cloud runtimes.

In practice, this means continuously validating identity and using phishing-resistant factors, restricting or disabling P2P exchange on corporate devices, requiring reliable container images and policies that prevent committed nodes from establishing unauthorized outgoing communications. It also forces to monitor unusual processes within containers and to migrate credentials and secrets outside environment variables to robust and auditable secret management solutions. In order to better understand how access to databases from managed environments works, the official documentation of the Cloud SQL Auth Proxy.

The cloud security community also has reference material to harden platforms and practices: Kubernetes official documentation on security and pod policies is a good starting point ( Kubernetes: safety concepts), and threat frameworks such as the MITRE catalogue help map techniques observed with known mitigation ( MITRE ATT & CK for Cloud).

It is also useful to review official recommendations on the safe use of interdevice transfer functions. Apple, for example, documents how AirDrop works and what controls exist to limit its use, something relevant if you want to reduce the risk that a malicious file will cross the line between personal and work ( Apple support: AirDrop).

This episode is an invitation to rethink the trusted architecture in the development and operations teams: the comfort of using code assistants and transferring artifacts between devices should not erase the need for basic controls. A combination of contextual access policies, robust MFA, proper secret management and runtime segmentation can drastically reduce the attack surface but it requires organizational discipline and continuous visibility about what happens within clusters and pipelines.

That state-motivated actors resort to such integrated techniques - from social engineering to the manipulation of deployments in Kubernetes - emphasizes that the current risk scenarios are hybrid and chained: a small neglect at the end of the developer can become, if the weaknesses of the cloud environment are exploited, a multimillion-dollar robbery. Prevention is to close these chains in all their links and to invest in controls that hinder lateral movement and persistence once inside.