No Private Key Was Stolen. Binance's Own Systems Signed $6.3 Billion Out the Door.

The headline writes itself. The FBI said on Saturday that North Korea took more than $6 billion from Binance. Most of it left inside about twenty minutes, and the haul runs to roughly four times the $1.5 billion stolen from Bybit in February 2025.

Then read the sentence Binance put in its own incident notice on 30 October: "We have found no evidence of any wallet private key leak."

Both statements can be true at the same time, and the second one is the part worth understanding. Nobody broke the vault. The vault was instructed to open, by the systems Binance uses to authorise withdrawals, across at least ten blockchains, in a single evening. The private keys stayed where they were. The permission to use them went somewhere it was never meant to go.

What Binance has confirmed, and what it has not

The exchange's first substantive update, on 30 October, put the estimated total impact at around $6.3 billion and said roughly $3 billion had been frozen on chain. It described an incident that may have involved "a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions," and listed four immediate actions: withdrawals suspended, the affected address authorisation revoked, law enforcement engaged, intelligence partners brought in.

That phrase is doing quiet work. You revoke an authorisation, not a key. Something existed that let withdrawals be signed on Binance's behalf, and it could be switched off. Binance still says no key leaked. Both can hold.

Co-CEO Richard Teng then made the official account less tidy rather than more. In a video update he described an attack that "was not carried out by one person," said the investigation had "uncovered additional points of breach," and said the tooling included a self-destruct mechanism that destroyed traces as it ran. On the Ethereum delegation he said it "did not pass through our normal approval controls." Binance has promised a technical post-mortem and has not published one. There is still no confirmed root cause, only a vendor's preliminary story and three analytics firms reading the same chain.

Fifty signatures, one of which had to work

The clearest reconstruction so far comes from TRM Labs, whose analysts traced every transfer out of Binance-attributed wallets across ten chains. Their central finding is not a stolen key. It is a batch of signatures.

On Ethereum, the attacker used EIP-7702, a mechanism introduced in the Pectra upgrade in May 2025 that lets an ordinary wallet hand control of its behaviour to a smart contract by signing an authorisation. Once that signature lands, every call to the wallet runs the contract's code, and the arrangement persists until the wallet signs a replacement.

At 20:20 UTC, the operator submitted one transaction containing fifty such authorisations. Each was signed by the Binance hot wallet. Each pointed the wallet at a sweeper contract that would accept instructions only from the attacker. Ethereum wallets carry a running transaction counter called a nonce, and an authorisation is valid only at the count the wallet has reached when it executes. A hot wallet processing customer withdrawals advances that counter constantly. By preparing signatures for fifty consecutive counts, the attacker did not need to be right about the moment. They needed one of fifty to still be live when the transaction landed.

One matched. That was enough.

Three minutes and twenty-four seconds later, the operator told the Binance wallet to send its entire balance to an address it controlled. That single transaction moved 167,464 ETH and 63 tokens, including 1.615 billion USDT. The delegation stayed in place afterwards, which is the detail that turns a theft into a drain: as new customer funds arrived at the wallet, the attacker swept them again at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC. The same wallet was also acting as executor for a separate Binance smart account, which gave the attacker a route to pull 823 million USDC from it. Circle froze that USDC shortly afterwards.

The twenty minutes before and after

TRM's timeline puts the preparation at least 36 hours ahead of the theft. The attacker's operator wallet received three small withdrawals from Tornado Cash starting on the morning of 28 October. Early on 29 October, code was deployed and tested against two wallets. Later that day it was rehearsed on a third, with the test funds routed back. Four hours after the rehearsal, the same code was installed on a Binance hot wallet.

The first theft came on the XRP Ledger. Between 20:05 and 20:09 UTC, five Binance wallets sent 233.46 million XRP to one attacker address, each leaving only its minimum balance. Solana and Optimism followed after 20:10. At 20:20, a Binance Bitcoin hot wallet sent 18,270 BTC, which the attacker split into 1,000 BTC and 100 BTC pieces inside the same block, a peel chain built to make money harder to follow. Two minutes later, a wallet on Tron sent 612.7 million USDT and 46.4 million TRX. A second wave at 23:05 reached Avalanche and Polygon.

Ethereum accounts for about $3.79 billion of the total, Bitcoin about $1.47 billion, Tron about $628 million, the XRP Ledger about $296 million and Solana about $96 million. Elliptic counts eleven affected chains, adding NEAR to TRM's ten.

The detail that points away from a phishing story sits on the other nine chains, where TRM found ordinary signed transfers rather than delegations. Those wallets used different chains, key types and signing schemes, and all of them produced valid signatures for the attacker inside about half an hour. TRM's assessment, stated as an assessment, is that the attacker gained the ability to make Binance's hot wallet signing system sign transactions of its choosing. Binance has not confirmed that, and until it publishes a post-mortem, nobody outside the company can.

The number does not settle

Four organisations have now put a figure on the loss, and they do not agree. Binance says around $6.3 billion, describing it as estimated total impact rather than an audited number. TRM says $6.36 billion at the time of theft, about $6.23 billion at current prices. Elliptic says $6.43 billion. Chainalysis, in its 30 October write-up, says approximately $6.4 billion.

The freeze figures diverge for legible reasons: they were counted at different times and valued at different prices. Binance said about $3 billion. TRM counted roughly $2.7 billion, including $1.77 billion from Tether, $825 million from Circle and $40.5 million from Ripple, plus about $30 million pulled out of reach by Arbitrum's security council. Elliptic verified $2.85 billion, 44 percent of the theft.

The freezes are the only part of this story that worked as designed. Tether froze the attacker's main Ethereum wallet 37 minutes after the stolen USDT arrived, locking 1.18 billion in place, then followed the funds and froze four more addresses within 17 minutes. Circle froze 823 million USDC three minutes later.

Which leaves the sentence that should be on a slide in every treasury team's incident review: covered is not recovered. Binance moved from roughly 80 percent covered to 90 percent on 31 October and about 95 percent on 1 November. None of that money came back from the attacker. It came from Binance's own balance sheet, buying replacement tokens so that customer balances were whole.

The control that worked was a balance sheet

Binance set aside more than $6.34 billion of company funds to do it. The sources were a partial deployment of the Secure Asset Fund for Users, a bitcoin reserve set up in July 2018 and held by Nest Clearing and Custody, a recognised clearing house regulated in Abu Dhabi; a portion of the Futures insurance fund above its regulatory requirement; and the corporate treasury. Co-CEO Yi He said the company used 50 percent of SAFU and committed to refilling it to about $1 billion.

Elliptic's read is that around $5 billion of the $6.34 billion was already held in the same tokens that were stolen, with the balance bought in the market and over the counter. Binance could make customers whole because it held customer assets one for one and had a reserve on top. The reserve was not a security control. It was a balance sheet line that existed before the event, and it is why this is a story about an exchange's losses rather than tens of millions of customers' losses.

The market's verdict was milder than the headlines. Binance reopened withdrawals in phases from 06:00 UTC on 1 November and had all 15 networks in the first phase live by 12:36. In the first nine and a half hours it processed $4.65 billion of withdrawals against $1.01 billion of deposits, a net outflow of $3.64 billion, which it put at 2.1 percent of its $171 billion in assets under management as of 28 October. Ari Redbord, global head of policy at TRM Labs, told Reuters the number "puts the withdrawals in the range of a precautionary reaction rather than any sort of capital flight." Changpeng Zhao, the founder, posted "98% choose to stay!"

DefiLlama put the same outflow at $5.81 billion. A Binance spokesperson said that figure did not account for deposits into the exchange's new hot wallet. With 335 million registered users, per Reuters, two percentage points of assets is a large number of people either way.

What the attacker still holds

Freezes only work on assets with an issuer who can blacklist them. The attacker now holds more than 420,000 ETH and 18,270 BTC, which TRM values at about $2.4 billion in assets beyond any issuer's reach. Bitcoin and ether have nobody to call.

The laundering runs around the clock and looks largely automated. Elliptic counted 1,113 separate TRX transfers out of the attacker's main Tron wallet between 30 October and 1 November, median gap 90 seconds, longest pause 39 minutes until the wallet ran dry. Amounts were irregular, down to six decimal places. On Ethereum, LINK was sold in 89 pieces and PEPE in 94, roughly 36 seconds apart, and each selling wallet was funded with exactly 0.5 ETH for fees.

Elliptic is careful here: automation is clear, but whether it is scripting or an agent that adapts cannot be determined from on-chain data. The failed bridge transactions look like a script retrying without fixing the cause.

The politics are less tidy than the alert. The FBI named North Korea and TraderTraitor on 31 October and published hundreds of Ethereum addresses, 19 bitcoin addresses and one Solana address to block. President Trump, the same day, was more cautious: "We don't know if it's North Korea, but if it is, we'll talk to North Korea about it." The alert gives attribution and addresses. It gives no mechanism, which is the piece every defender needs.

What this means if your company signs things

Strip out the crypto and the shape is familiar. An identity that should have limited rights held a standing permission to authorise actions. The signatures were valid. The approval path was bypassed, or never covered this kind of request in the first place, and once the delegation existed it renewed the damage every time new funds arrived.

Every organisation running Microsoft 365, Intune or Jamf has an equivalent surface, and most of them cannot list it from memory. OAuth grants issued to an app three years ago and never reviewed. Service principals with standing write access because removing it might break a sync job. Break-glass accounts that get used monthly and audited yearly. A contractor with approval rights in a finance workflow. None of these is a leaked password. All of them are an authorisation that will do exactly what it is told.

Two lessons from this incident transfer cleanly. The first is the nonce batch. If an approval flow will accept any of a set of pre-generated approvals, or will retry until one lands, then the attacker's job is to get one through, not to forge the right one. Approval designs that treat a burst of authorisation requests across a range of states as routine traffic are handing over that margin.

The second is the revocation rehearsal. TRM's guidance to exchanges is to watch for EIP-7702 delegations appearing as code at an address that should have none, and to keep a tested, pre-approved way to sign a revocation. The enterprise translation is duller and harder: know which delegations your tenant is carrying, and practise removing one before you need to. Binance could revoke the affected authorisation quickly. It still cannot tell the public what the authorisation was, because the post-mortem is not written.

Most businesses reading this are not custodians of $171 billion. They run a tenant, a fleet of laptops and a set of service accounts with more standing privilege than anyone remembers granting, and the failure mode repeats at a smaller scale: the credential stays valid, the authorisation goes where it was never meant to go, and nobody can say from memory which approvals are still live. That is an inventory problem before it is a security problem, and it is the sort of work DMC does with SMB teams across London and the Home Counties, mapping conditional access to who needs what, expiring privilege instead of accumulating it, and writing down how to revoke a delegation while the building is calm. If you want a second pair of eyes on the approvals your business is still carrying, let's talk.