The FBI pins Binance’s $6.43 billion theft on TraderTraitor, and the private keys were never the problem
the largest theft of anything, ever, by Elliptic’s math, and the cryptography held up perfectly. North Korea’s TraderTraitor did not crack a key. it got Binance’s own systems to sign for it, including 50 perfectly valid EIP-7702 authorizations that handed a hot wallet to a sweeper contract. the FBI made the attribution official on October 31, and withdrawals started reopening on November 1.
the numbers
- $6.43 billion stolen per Elliptic. Binance’s own estimate is around $6.3 billion. TRM Labs put it at about $6.36 billion on ten chains, most of it in roughly 20 minutes starting 20:05 UTC.
- $3.80 billion taken on Ethereum alone across 186 tokens, including 1.9 billion USDT and 823 million USDC. plus 18,270 BTC, worth $1.48 billion, and 612.7 million USDT on Tron.
- $2.85 billion frozen or seized, 44 percent of the theft, almost all USDT and USDC. Tether, Circle, Ripple, World Liberty Financial, Paxos and First Digital froze stablecoins. Arbitrum’s Security Council and Optimism governance moved assets out of the attacker’s reach on their chains.
- about $3.25 billion still in attacker hands that no issuer can freeze, spread across more than 800 addresses, including around 584,000 ETH, 18,327 BTC and 233 million XRP, per Elliptic as of November 1.
Elliptic’s line on the regime’s tally is the one that should end up in policy decks: this single incident “almost doubles the total cryptoassets stolen by the regime.”
how it happened, as far as anyone has said
Binance’s first statement said 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,” and that it had found no evidence of a private key leak. a later update said the investigation had “uncovered additional points of breach.” co-CEO Richard Teng: “the attacker did not simply use one engineer’s permissions, and this was not a single ‘one-click’ action.” per Elliptic, Teng also said the attacker used a self-destruct mechanism that destroyed tooling and traces as it ran, and that the EIP-7702 delegation “did not pass through our normal approval controls.”
the on-chain story, from Elliptic:
- prep. a fresh attacker wallet funded with three 0.1 ETH withdrawals from Tornado Cash. a sweeper contract deployed at 15:59 UTC on October 29, rehearsed on another wallet about four hours before the real thing.
- the 7702 move. at 20:20 UTC the attacker submitted a single transaction carrying 50 authorizations, all validly signed with the key of the hot wallet known as Binance 14, each for a different nonce so one would match whatever the wallet’s count was when it landed. that delegated Binance 14 to the sweeper. three and a half minutes later the sweeper emptied it of 167,464 ETH and 63 tokens, including 1.6 billion USDT.
- persistence, the on-chain kind. the delegation stayed in place, so no new signatures were needed. the attacker used Binance 14’s owner rights over another Binance wallet to pull 823 million USDC, and swept new deposits into Binance 14 four more times.
- everything else. on the other ten chains, funds left in ordinary signed transactions, and another Ethereum hot wallet, Binance 16, sent $174 million directly to the attacker. Elliptic reads that as the attacker being able to instruct Binance’s signing infrastructure directly.
that is the whole lesson in one sentence: the keys were safe, and the thing that uses the keys was not. it is the Bybit pattern again, where a compromised developer machine at Safe{Wallet} manipulated what signers approved.
checking the delegation yourself
EIP-7702 delegation is visible on chain. a delegated externally owned account returns code that starts with the designator 0xef0100 followed by the 20-byte target address. revoke it and the code goes back to empty. we asked a public Ethereum RPC endpoint about Binance 14, read only, no keys, and it is now a plain EOA again, consistent with public reporting that Binance revoked the delegation by delegating to the zero address.

if your organization runs hot wallets, or treasury operations on any EVM chain since the Pectra upgrade, add this to monitoring: alert the instant an address you control returns non-empty code starting with 0xef0100. it costs one RPC call per address per block, and it would have been a very loud alarm here.
what the attribution is based on, and what it is not
Elliptic’s pre-attribution assessment rested on laundering overlap with the September 2026 Bitget exploit, common service usage with earlier TraderTraitor thefts from BigONE, WOO X and AFX, the long preparation and staff targeting, and sheer scale: very few actors coordinate a theft across 11 chains in about three hours. Chainalysis and TRM Labs reached the same conclusion. the FBI published the addresses involved and asked exchanges and DeFi services to block them. Elliptic has published a free blocklist with more than 8,000 addresses.
some coverage of TraderTraitor this week has rehashed the group’s known tradecraft, like trojanized developer tooling and malicious infrastructure-as-code. that is background on the group, documented by several vendors over the past few years, not a disclosed root cause for Binance. Binance has not said what the “additional points of breach” were. anyone telling you exactly how the laptop got popped is guessing.
the laundering is automated
Elliptic’s analysis of the main Tron laundering wallet found 1,113 separate transfers between October 30 and November 1, a median gap of 90 seconds, randomized amounts to six decimal places, and activity straight through both nights in Pyongyang. new token-selling wallets were each funded with exactly 0.5 ETH and started trading within minutes. it reads like scripts, not people. Elliptic also notes it cannot tell from chain data whether any of it is AI agents rather than conventional scripts, which is the honest answer.
what normal companies should take from this
you probably do not hold $6 billion in hot wallets. you probably do have a few engineers whose laptops can reach a container that can do something irreversible: push to production, approve a payment run, change DNS, sign a release. the questions are the same at any size:
- can a single compromised workstation reach the thing that signs, pays or deploys? if yes, that is your Binance 14.
- do high-value actions require approval from a second, independent device and person, every time, including for “internal” paths like 7702 delegations that someone forgot to put through the approval flow?
- would you notice irreversible actions within minutes, not after the fact? Tether froze the main USDT wallet 37 minutes after funds landed. most companies would still be figuring out who owns the alert.
- do your logs survive an attacker whose tooling deletes itself? ship them off-host, immutably, before you need them.
the sloth take
the world’s largest exchange lost the world’s largest pile of stolen anything, and not one cryptographic primitive broke. a laptop, a container and a signing path that skipped approvals did the work. if your security program is mostly about protecting keys, ask who can ask the keys to do things. that is where North Korea is looking.
for the retail end of crypto crime, where the victims do not have a SAFU fund, see task gig job crypto scams.
if a single engineer laptop can reach the thing that signs, pays or deploys in your shop, that is worth a conversation. Book a slot with Dark Edge Consulting.
sources
- Elliptic: The largest theft in history, North Korea behind the $6.4 billion Binance hack (updated Nov 1, 2026)
- BleepingComputer: Binance links $6.3 billion crypto theft to compromised DevOps laptop
- Maborak: Binance 14’s EIP-7702 revocation, checked on-chain
- CoinDesk: how one Ethereum permission let an attacker drain $2.5 billion from Binance
