Introduction
I have read a lot of breach post-mortems over the years, and most of them follow the same tired script: someone clicked a phishing link, a password got reused, a server went unpatched. Binance's post-mortem, published on Tuesday, November 3, 2026, is not that script. About $6.3 billion left the world's largest crypto exchange on October 29 — the biggest crypto theft ever recorded, roughly four times the $1.5 billion Bybit hack of February 2025 — and according to Binance, no private key ever leaked.
The vault did not break. Nobody cracked the cryptography. The attackers got in through a job offer in June, worked their way onto a DevOps engineer's laptop, used an internal AI tool to hop between machines, and then got Binance's own signing system to approve the theft for them. If you run a website, a server, or any infrastructure at all, this story is about you, even if you have never owned a single satoshi. Strip away the crypto, and it is a story about laptops that can reach production and a kill switch that controlled the wrong thing.
What Actually Happened on October 29
On October 29, 2026, attackers drained about $6.3 billion from Binance's hot wallets — the internet-connected wallets an exchange keeps online to process withdrawals — across ten blockchains. Analytics firm TRM Labs puts the total at $6.36 billion, with most of it moving within about 20 minutes starting at 20:05 UTC.
At 20:05 UTC, five Binance hot wallets on the XRP Ledger sent 233.46 million XRP to the attackers. Solana, Optimism, Bitcoin, and Ethereum followed. At 20:20 UTC, a single transaction carried 50 authorizations — permissions signed by Binance's own hot wallet, each one pointing at a contract that took orders only from the attacker. Three minutes and 24 seconds later, that hot wallet was told to send out everything it held: 167,464 ETH, 63 other tokens, and 1.615 billion USDT.
Binance suspended withdrawals that night. It did not matter. The money kept leaving anyway, because the permissions the attackers had obtained lived on the blockchain itself, outside anything Binance's withdrawal switch could touch. The delegation was only cleared at 00:10 UTC on October 30, when Binance signed a new authorization pointing it at the zero address — just over four hours after the first coins moved. TRM Labs also found the attackers had rehearsed: three small withdrawals from the Tornado Cash mixer funded an operator wallet on October 28, and the attack code was tested on three wallets hours before the main event.
It Started in June — With a Job Offer
Here is the part of the post-mortem that should make every developer and team lead uncomfortable: the intrusion began in June, with a job offer.
Binance's post-mortem traces the story back to a fake job offer — the classic opening move of North Korea's TraderTraitor unit, which the FBI formally blamed for the theft on October 31. The same unit was behind the Bybit hack. A recruiter reaches out, the conversation moves to a coding test or an interview document, and somewhere in that process a machine gets compromised. It is social engineering aimed squarely at engineers, and it works because engineers expect to be sent code.
The laptop that got compromised belonged to a DevOps engineer. That detail matters more than almost anything else in this story, because a DevOps engineer's laptop is not a normal laptop: it holds credentials, tokens, and sessions that reach into production systems. From that one machine, the attackers worked their way deeper. In October, according to the post-mortem, they used the compromised machine and an internal AI tool to gain control of two more engineers' computers — identified in the report only as Engineer A and Engineer C.
Then, on October 29, between 17:15 and 19:56 UTC, the attacker logged onto Engineer C's computer, used Engineer A's stolen credentials, deployed a container, and ran a malicious script. That gave them Binance's internal wallet-signing service — the system that authorizes transactions. Two hours and 41 minutes of quiet preparation, and then, at 20:05 UTC, the floodgates opened.
The EIP-7702 Trick, in Plain English
The technical heart of this hack is a feature called EIP-7702, and it is worth understanding properly, because it is the reason Binance's kill switch failed.
EIP-7702 is an Ethereum upgrade that lets an ordinary wallet temporarily delegate its powers to a piece of code — a smart contract. Think of it like giving someone a signed, temporary power of attorney over your bank account. The attackers used Binance's own signing service to approve 50 of these authorizations, all pointing at a contract the attackers controlled. One of them worked. From that moment, the attacker-controlled contract could tell Binance's hot wallet to send its funds anywhere — and because the authorization was recorded on the blockchain, Binance could not simply switch it off from inside its own systems.
There is a cruel irony here. Binance's hot wallet used multi-party computation, or MPC — a setup that splits signing power across several parties so that no single stolen key can move funds. MPC is genuinely good security, and it is exactly what an exchange should be doing. But MPC protects the key. It does not protect the approval. The attackers never needed a key, because they got the signing service itself to approve the authorizations. The vault's lock was fine. Somebody had convinced the guard to open the door. Revoking the delegation even required the wallet to sign — and the wallet's normal signing path was the thing that had been compromised.
What Got Frozen, What Didn't, and Who Pays
About $2.8 to $3 billion of the stolen funds were frozen or intercepted, with help from Tether, Circle, Ripple, World Liberty Financial, and the Arbitrum Security Council. Stablecoins like USDT and USDC can be frozen by their issuers, and that capability did real work here — roughly half the haul was stopped. But Bitcoin and Ether cannot be frozen by anyone. One address still holds 195,460 ETH that no issuer can touch, worth over $440 million. That money is, for practical purposes, gone.
Binance set aside $6.34 billion and began reopening withdrawals in phases on November 1, starting at 06:00 UTC, with 15 networks in the first phase. The exchange says about 95% of the impacted amount has been covered from its SAFU emergency fund and company resources, and that users will not bear any losses.
In the first nine and a half hours after withdrawals reopened, Binance processed $4.649 billion in withdrawals against $1.01 billion in deposits — a $3.64 billion net outflow, but only about 2.1% of its $171 billion in assets. Customers were rattled, but they did not stampede. Binance could absorb a $6.3 billion loss because it is Binance. Almost no other exchange on earth could say the same.
Why "No Private Key Leaked" Is the Scary Part
I have seen a few people respond to this story with relief — no keys leaked, so the cryptography held, so everything is fine. That is exactly backwards. If a private key leaks, you know what went wrong and how to fix it: rotate the key, change the process, move on. What happened at Binance is worse, because the failure was in the approval layer — the point where a transaction gets signed off. The system did exactly what it was designed to do. It approved transactions that looked legitimate, because the approvals came through the legitimate signing service, using legitimate credentials, from a legitimate engineer's session. Every check passed. The checks were the problem.
Binance calls its post-mortem an initial report and says it has not published a full root cause yet. But the remediation list already tells the story: the exchange has rebuilt the affected wallet system in a new environment, rebuilt the internal AI tool and its access controls, replaced devices, decommissioned the affected engineers' credentials and tokens, scanned every employee device, and tightened wallet-service risk controls.
What This Means for Anyone Running Infrastructure
You do not run a crypto exchange, and neither do I. But the pattern in this attack shows up in ordinary web work every single day. First, a laptop is production access. If your developers' laptops hold SSH keys, deployment tokens, or admin sessions for your WordPress sites or hosting panels, then a compromised laptop is a compromised server. Keep credentials in a vault, not in a notes file, and make sure a stolen session alone cannot deploy, delete, or drain anything.
Second, service tokens need the same discipline as user credentials. The Binance attack moved through service tokens and signing-service access, not through a login page. Tokens should be scoped to the minimum they need, short-lived, and rotated — and they must never be reachable from a human laptop session without a second approval step.
Third, high-value actions need a second approval, a destination allowlist, and a rate limit. Fifty authorizations in one transaction, and then a wallet emptying itself in minutes, should not be something any single approval can do. The same logic applies to your world: bulk deletions, mass exports, and large transfers should need a second person, a pre-approved destination, and a cap on how much can move at once. Speed is the attacker's friend. Friction is yours.
Fourth, audit your AI tools' access. If your team uses AI coding assistants, internal chatbots, or automation tools that can read code, run commands, or touch production, check what they can actually reach — and what happens if an attacker reaches them instead. And finally, have a kill switch that actually kills the thing: Binance's withdrawal switch could not stop an on-chain delegation that lived outside the system it controlled.
What I Would Do This Week
First, list every laptop, token, and integration with deployment or admin access. If the list surprises you, that is the finding. Second, turn on a second approval for the dangerous actions: deployments, bulk deletions, DNS changes, and anything that moves money. One click should never be enough for something you cannot undo. Third, rotate your service tokens and API keys, and scope them down while you are at it. And fourth, check your recovery plan: if your admin system were compromised tomorrow, could you revoke access without depending on the compromised system itself? If not, write that procedure this week.
Conclusion
The Binance hack is the largest crypto theft ever recorded, and it will be remembered for the number: $6.3 billion, gone in about 20 minutes. But the number is not the lesson. The lesson is that the attackers never broke the cryptography, never stole a private key, and never attacked the blockchain. They compromised a person, then a laptop, then a signing service — and the system, doing exactly what it was built to do, approved the theft.
Binance survived because it could absorb a $6.3 billion loss and because stablecoin issuers froze half the haul. Almost nobody else in this industry has either advantage. The rest of us have to learn the cheaper lesson instead: guard the approval layer, limit what any single laptop or token can do, and make sure your kill switch controls the thing you actually need to kill.
FAQ
How much was stolen in the Binance hack?
About $6.3 billion — TRM Labs puts the figure at $6.36 billion — drained from Binance's hot wallets on October 29, 2026, across ten blockchains, most of it within about 20 minutes. It is the largest crypto theft on record, roughly four times the $1.5 billion Bybit hack of February 2025.
Did the hackers steal Binance's private keys?
No. Binance says it found no evidence that a private key leaked. The attackers compromised a DevOps engineer's laptop, reached the internal wallet-signing service, and got that service to approve 50 EIP-7702 authorizations that handed control of a hot wallet to an attacker-controlled contract.
Who was behind the attack?
On October 31, 2026, the FBI attributed the theft to North Korea's TraderTraitor unit, the same group behind the Bybit hack. The intrusion reportedly began in June 2026 with a fake job offer.
What is EIP-7702, and why did it matter?
EIP-7702 is an Ethereum feature that lets a wallet temporarily delegate its powers to a smart contract. The attackers used it to give their own contract execution rights over a Binance hot wallet — and because the delegation lived on-chain, Binance's withdrawal freeze could not stop the money leaving.
How much of the money was recovered?
About $2.8 to $3 billion was frozen or intercepted with help from stablecoin issuers and other partners. One address still holds 195,460 ETH — over $440 million — that cannot be frozen, because Bitcoin and Ether have no issuer who can freeze them.
Will Binance users lose money?
Binance says no. It set aside $6.34 billion, says about 95% of the impacted amount has been covered from its SAFU emergency fund and company resources, and reopened withdrawals in phases from November 1, 2026.
