How Hackers Took $6.3 Billion from Binance Without Stealing a Key
The largest crypto theft in history did not begin with a stolen key. It began with one laptop, and ended with Binance's own systems signing the attacker's withdrawals.
Today, Binance, the largest cryptocurrency exchange in the world, said that about $6.3 billion in assets was taken in a single security incident. Two blockchain intelligence firms, TRM Labs and Chainalysis, have tied the theft to North Korea with high confidence. It is, by a wide margin, the largest crypto heist ever recorded. The next largest, the $1.5 billion Bybit theft in February 2025, was blamed on the same group.
The numbers are still moving, and the investigation is early, so treat every figure here as a first estimate. But the shape of the attack is already clear, and for anyone who builds or defends systems, it is the most useful part. This was not a smash and grab. It was patient, quiet, and it turned the victim’s own machinery against itself.
They did not steal the keys
Start with the thing most reports gloss over, because it is the whole lesson.
When people imagine a crypto exchange being robbed, they picture a stolen private key, the secret that controls a wallet. That is not what happened here. Binance has said there is no evidence that its private keys leaked. The analysis firm Elliptic reached the same read: the attacker most likely got Binance’s own systems to sign the transactions, rather than stealing the secret that signs them.
That difference matters. A stolen key is a stolen key. But a system that can be convinced to sign on command is worse, because from the outside every signature looks legitimate. The money left through the front door, with the exchange’s own signature on the paperwork.
From a laptop to the vault
Binance’s first finding was that the incident “may involve a compromised DevOps engineer’s laptop.” A DevOps engineer is one of the people who keeps the plumbing of the system running. According to Binance, the attacker used that laptop to reach an internal service, a “service container,” and from there submit withdrawals that the system treated as authorized.
Binance’s co-CEO, Richard Teng, was careful to add that the attacker “did not simply use one engineer’s permissions,” and that the investigation found “additional points of breach” beyond the laptop. In plain terms: the laptop was a way in, not the whole story. But it is where the chain appears to start, and that is worth sitting with. A $6.3 billion loss traces back, at least in part, to one endpoint in one person’s hands.
This is the pattern I keep coming back to. Systems rarely fail because one wall was weak. They fail at the seam, where one trusted part hands off to another: the laptop that a container trusts, the container that the signing system trusts, the signature that the blockchain trusts. Each link behaved exactly as designed. The attacker simply walked the chain.
How did they get in? The likely paths
Binance confirmed two things about the entry. A DevOps engineer’s laptop was involved, and there were “additional points of breach” beyond it. It has not laid out the full chain. But this crew has a well-documented playbook, so here are the realistic paths. What follows is pattern, not confirmed Binance detail, and the likely truth is not any single one of these. It is several, stitched together.
Scenario one: the fake job offer. North Korea’s crypto crews rarely attack the firewall. They attack the person. An engineer is approached by a convincing recruiter about a senior role, and somewhere in the interview is asked to run something: a take-home coding project, a trading or video call app, a package pulled in as a dependency. It looks ordinary. It carries malware. The moment it runs on the work laptop, the attacker has a foothold. This is the method behind the Bybit theft earlier in 2025, and it works on engineers for a cruel reason: their job is to clone repositories, install packages, and run unfamiliar code all day. A finance clerk would hesitate at a coding challenge from a stranger. A DevOps engineer runs three before lunch.
Scenario two: the poisoned dependency. The engineer does not even need to be singled out. A malicious package, published to a public registry under a name close to a real one, or slipped into a project’s dependencies, runs its code the moment it is installed. One npm install or pip install on the right machine, and the attacker is inside, no interview required. The developer did nothing careless. The install did what installs do.
Scenario three: the stolen session. Not every break-in installs malware. Phishing a login, or stealing a live session token, can hand an attacker the engineer’s access to the cloud console directly, multi-factor and all, because a stolen session is already past the login. From there they do not need the laptop. They are the engineer, as far as the systems can tell.
Then the pivot. However they got the first foothold, the laptop was a doorway, not the destination, and “additional points of breach” is the tell. From the endpoint, the attacker used what it could reach, stored credentials, SSH keys, cloud tokens, access to the internal service container, to move toward the one thing that mattered: the system that signs withdrawals. Each step used access that was supposed to be there. That is the whole lesson of this hack in one line. The break-in was not one hole. It was a chain of trusted handoffs, walked end to end.
The patience is the scary part
Here is the detail that should bother every defender. According to TRM Labs, the attacker did not rush. About 36 hours before the theft, they took control of one of Binance’s hot wallets and quietly prepared fifty pre-signed authorizations, each one pointing that wallet at a contract the attacker controlled. Then they waited.
At 20:20 UTC, a single transaction set those authorizations loose. Three minutes and twenty-four seconds later, the wallet’s entire balance was gone, including 167,464 ETH, sixty-three other tokens, and over 1.6 billion in the dollar-pegged token USDT. Across several blockchains, the whole operation took about twenty minutes.
Thirty-six hours of pre-positioning, then a twenty-minute drain. By the time any human could have noticed the first withdrawal, the rest were already written and waiting. Detection that works in hours is useless against an attacker who set everything up a day and a half in advance and then emptied the account faster than a coffee break.
What got saved, and what did not
The one piece of good news is that crypto, for all its talk of being unstoppable, is not as final as people think when the issuers cooperate.
Within hours, roughly $3 billion was frozen. The companies behind the two largest dollar-pegged tokens acted fast: Tether froze more than 1.567 billion USDT, and Circle froze 800 million USDC. Others, including Ripple and a group called World Liberty Financial, froze more. A blockchain’s security council froze about $30 million more.
The catch is that this only works on assets whose issuer has a freeze button. The attacker still controls the assets that no one can freeze: over 420,000 ETH and more than 18,000 Bitcoin, together worth around $2.4 billion. Elliptic estimates about $3.3 billion sits in roughly forty-three wallets that no issuer can touch. That money is being laundered right now.
Who, and how they are so sure
TRM Labs and Chainalysis both attribute the attack to North Korea, and specifically to a group tracked as TraderTraitor, the same group blamed for the Bybit theft last year and a $351 million theft from the exchange Bitget earlier this year.
Their confidence does not come from a confession. It comes from the plumbing. Some of the stolen Binance funds mixed with funds from that earlier Bitget theft. The two firms point to a shared Ethereum address and to a familiar set of moves: small withdrawals through a mixing service, pre-signed transactions fired in one burst, a laundering playbook they have watched this group run before. Elliptic has urged some caution, noting the laundering this time looks a little different and that Binance has not yet published a root cause. That caution is the right instinct, and I will update my own view as the facts firm up.
The lesson, if you run anything that signs
Most readers do not run a crypto exchange. It does not matter. The weaknesses here live in ordinary systems too.
- The machine that approves is the real vault. Guarding the secret key is not enough if the system around it can be talked into signing. Protect the signing path, who can trigger it, from where, and with whose approval, as fiercely as you protect the key itself.
- A privileged laptop is a privileged system. The engineers who keep the plumbing running hold more power than almost anyone, and their laptops are a soft target. Treat a DevOps endpoint like the production system it can reach, not like an office computer.
- Watch for pre-positioning, not just the theft. The fifty authorizations sat in place for a day and a half. The time to catch this was then, not during the twenty-minute drain. Alarms should fire when something is armed, not only when it goes off.
- Assume one account is already owned. Binance’s own takeaway was that it was not one engineer. Design so that one compromised person, or one compromised machine, cannot move everything. Require a second, independent approval for the actions that empty the vault.
None of these are new. They are the same ideas I argued for in The Hidden Risks of Offshoring Cybersecurity: the danger is rarely one weak wall, it is too much trust handed from one part of a system to the next, and too few checks at the handoff.
The largest theft in history did not need a genius exploit or a stolen secret. It needed a way in, patience, and a system willing to sign. The question every team should ask after reading this is the one that would have caught it: before our systems approve something that cannot be undone, what, exactly, did we check?