Binance attack: how DPRK targets developer laptops

Introduction

On October 29, 2026, roughly $6.4 billion in cryptocurrency was stolen from the world's largest cryptocurrency exchange, Binance. The on-chain reconstruction comes from two blockchain intelligence firms that traced the attack in real time, Chainalysis and TRM Labs.

The analysis from the firms highlight:

• The attack is likely the work of the North Korean cybercrime group, TraderTraitor
• The attack happened in about 20 minutes
• Funds began leaving hot wallets (cryptocurrency wallets connected to the internet) across 10 blockchains.

As of this writing, the full details of the attack have not been publicly disclosed. Binance said on X, "Our initial investigation suggested that the security incident may have involved a compromised laptop, however our subsequent investigation has uncovered additional points of breach."

Binance says it found no evidence of a wallet private key leak, and the mechanics support that the attackers did not need the keys. On Ethereum, they used EIP-7702 –– a 2025 feature that lets a wallet delegate its behavior to a smart contract –– to turn a Binance hot wallet into a sweeper only the attackers could operate. On the other nine chains, the wallets simply sent funds through ordinary, validly signed transactions. TRM's read is that the attacker gained the ability to make Binance's hot wallet signing system sign whatever it was asked to sign.

Stablecoin issuers, law enforcement and blockchain analytics firms started freezing stolen funds inside the first hour, locking down roughly $3 billion before the attacker could convert it into assets nobody can freeze. Binance paused withdrawals and pledged to cover customer losses in full. None of that undoes the scale of the theft, but the coordinated response was faster than most people would have predicted a year ago.

Developer systems are critical

Binance stated that the incident “may involve a compromised DevOps engineer’s laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions.” The company added that it found no evidence of a wallet private key leak. Following that, co-CEO Richard Teng made a post on X stating that “the attacker did not simply use one engineer’s permissions, and this was not a single ‘one-click’ action. It involved a more complex attack process.”

It has not been revealed how the attacker got onto the system in the first place. But the DPRK has a well-documented set of tricks for gaining access to a target developer’s machine. Often this starts by finding someone on a platform like LinkedIn, offering them a job, and then asking them to complete a coding challenge that carries malware. Alternatively, they stand up fake job assessment portals aimed at developers. The DPRK is also known to run fake Zoom interviews. These interviews include a deepfaked panel that claim the candidate’s mic has audio issues, then asks them to install a plugin to fix it. The plugin is malware. They have also targeted developers with malicious GitHub repositories and with malicious packages published to open-source registries.

Over the past few years, much of the malware being developed has been geared specifically toward developers and power users. These users often hold the keys to the kingdom. But as Teng pointed out, gaining access to a single developer system does not usually lead to a full compromise. It is just the first step. Malware is now often designed to immediately sweep a developer’s system for every credential and access token it can find. Knowing how to abuse those secrets inside a company environment is far more complicated, and that is the tradecraft that the DPRK has built.

It’s not just a crypto industry problem

Crypto exchanges hold enormous sums in assets that can be moved instantly, and that makes them an unusually rich target. But the structural fact that made this breach possible is not unique to crypto at all.

In almost every vertical, developers and DevOps engineers hold privileged, often programmatic access to the systems that define the business, like payments platforms, patient records systems, manufacturing control planes, customer data warehouses or CI/CD pipelines that can ship code to production. These engineers need broad access to do their jobs, their tooling is designed around trusting external code, and their machines are frequently the most exception-ridden endpoints in the fleet: local admin for build tooling, security agents relaxed for performance, personal hardware for prototyping. Often the machines and users with the most exceptions are the ones closest to production, which makes them natural targets at any company.

What we have seen from DPRK techniques

The attacker reportedly spent at least 36 hours staging before funds moved. Before that, someone had to land on a laptop, stay there, harvest credentials and work out the path from a developer’s machine to a container with signing access. Each step leaves marks if you’re watching the right places.
The analysis from Chainalysis and TRM Labs both identify the DPRK as perpetrators of the attack. Jamf Threat Labs has tracked DPRK activity for several years, and a few patterns hold up across campaigns:

• The lure is almost always a job. A recruiter message, a take-home coding exercise, an assessment portal, a video interview that needs a “plugin” to fix your audio. The malware is wrapped in something a developer would reasonably run.
• Delivery leans on tools developers already trust. Payloads arrive through GitHub repos, npm and PyPI packages, and run under interpreters like Node and Python.
• The first action on the box is a credential sweep. Browser sessions, SSH keys, cloud tokens, keychain items.
• They reuse code. Despite the AI-driven speed of malware iteration, we’ve seen the same scripts and binaries show up at unrelated organizations. Behavioral detection catches technique; signatures still catch laziness.

Those patterns show up consistently in the telemetry:

• Odd AppleScript invocations
• Curl commands and syntax that matches known DPRK staging
• Files with naming conventions this group keeps coming back to

Take action to secure your organization

Make a list of who in your org has programmatic access to production, CI/CD pipelines or money, and treat those machines as what they are: high-value targets. Get their telemetry somewhere a human or a SIEM can see it. Find out which of them have standing exceptions (local admin, relaxed agents, personal hardware) and ask whether each one still makes sense.

Then tell your developers about the job-offer playbook. This attacker relies on social engineering for their attacks, and user training is the cheapest way to protect your company.