Binance $5.8 Billion Stunning Heist: Full Recap of the Attack Flow

Original | Odaily (@OdailyChina)

Author | Azuma (@azuma_eth)

In the early hours of this morning, Binance's hot wallets suffered the largest security breach in the history of cryptocurrency. In less than an hour, Binance hot wallets across Ethereum, Bitcoin, Tron, as well as Arbitrum, Avalanche, Optimism, Base, and other networks were simultaneously compromised, with cumulative outflows reaching approximately $5.8 billion (unofficial figures).

There has already been extensive real-time tracking of where the stolen funds flowed, the industry's efforts to trace and block them (especially by Tether and Circle), and the on-chain protocols indirectly implicated (such as Aave). This article strips away the complicated fund accounting to focus directly on the most essential question: How exactly was Binance's seemingly impregnable hot wallet breached?

Based on reverse-engineering by the security firm Blockaid and multiple on-chain security researchers, this was not a simple on-chain smart contract vulnerability, but rather a precise infiltration of the exchange's underlying signing infrastructure (HSM/MPC signing machines), combined with the Ethereum EIP-7702 mechanism to achieve a "single-block, ultra-fast sweep" — a textbook-grade attack.

Root Cause: The Underlying Signing Machines Were Compromised, Giving the Hacker "Sign-on-Demand" Capability

After the incident, because the core compromised wallet, Binance 14, was drained instantly via the EIP-7702 mechanism introduced by Ethereum's Pectra upgrade, there was briefly a misreading in the community that "EIP-7702 has a vulnerability."

But from the standpoint of cryptographic common sense, the premise of EIP-7702 allowing an ordinary wallet (EOA) to temporarily attach smart contract code is that a valid signature must be completed by that wallet's own private key. Therefore, EIP-7702 was merely the "tool of the crime" the hacker used to accelerate the withdrawal, not the vulnerability itself.

Following the core clue of "who completed the signing," the cause of the incident can only point to two possibilities — either the bare private key was directly leaked, or the signing system (infrastructure) was manipulated. Based on the current on-chain characteristics, the latter — the signing system being manipulated — is almost the only reasonable explanation. The reason is that for an exchange of Binance's caliber, a hot wallet would never use a single-point plaintext "bare private key"; its underlying standard architecture must be HSM (Hardware Security Module) + MPC (Multi-Party Computation) + Policy Engine — private key shares are locked inside hardware black boxes, and no one (including internal operations staff) can obtain the full plaintext. Only the front-end business system, after validating risk control rules through the "Policy Engine," can request signatures from the signing machines.

There are two pieces of ironclad on-chain evidence that directly point to "the signing system being manipulated":

• Ironclad Evidence 1 (50 consecutive Nonce blind shots): When attacking Binance 14, the attacker submitted 50 valid EIP-7702 signatures covering consecutive Nonces in one go. If the attacker had directly stolen the plaintext private key, he could have precisely controlled the transactions locally and would not have needed to guess Nonces in this "hit-or-miss" manner at all. This shows that the attacker did not obtain the private key itself, but instead breached the policy engine or signing interface, gaining the ability to make Binance's signing system "spit out valid signatures on demand (Sign on demand)."
• Ironclad Evidence 2 (simultaneous compromise of heterogeneous multi-chain wallets): Just 24 seconds after Binance 14 was emptied, the independent hot wallet Binance 16 signed out 28,000 ETH with its own key; within the same minute, hot wallets on Bitcoin (18,270.2 BTC) and Tron (612 million USDT) with different signing algorithms simultaneously initiated transfers. Only by breaking through the top-level unified scheduling/policy engine could multiple chains' HSM/MPC signing machines be commanded to withdraw simultaneously.

On-Chain Timeline Reconstruction: 37 Hours of Lurking and a $7 Million "Live-Fire Rehearsal"

On-chain data shows that after taking control of the signing pipeline, the attacker did not tip his hand, but instead carried out a day and a half of meticulous deployment and live-fire drills before making a move.

• October 28, 07:39 (UTC), preparing ammunition: The attacker's main address (0x7c86...5ca0) withdrew initial Gas funds in three batches from Tornado Cash's 0.1 ETH mixing pool (first tranche received: 0.0983 ETH), a full 37 hours before the "final assault."
• October 29, 02:28 – 14:19 (UTC), rehearsal in advance: The attacker first deployed the first-generation sweeper contract Sweeper A (0x19bee2...) on Ethereum; then at 13:51 created 2 test wallets, even splashing $7 million in stablecoins into them for EIP-7702 delegation drills, and half an hour later successfully tested sweeping them to the receiving address (0x24a4ae...) with a single click.
• October 29, 15:59 – 18:20 (UTC), final version finalized: The attacker deployed the final version of the malicious sweeper contract Sweeper B (0x63e8...6fae), then immediately created a 3rd test wallet and injected 1.01 ETH, and at 16:30 completed a sweep test on 2.54 USDT; at 18:20, all test funds were consolidated back into the funding pool, and all pre-battle drills were complete.

The Fatal Blow: 50 Consecutive Nonce "Blind Shots" and One-Click Emptying via EIP-7702

At 04:19 Beijing time in the early hours of today (20:19 UTC), the hacker officially sounded the general offensive.

• 20:19:57 (UTC): The Tron hacker receiving address was created;
• 20:20:06 (UTC): The Bitcoin hot wallet (bc1qm34...) was the first to move, with 18,270.2 BTC transferred out in a single transaction;
• 20:20:59 (UTC): The Ethereum mainnet saw the most core technical operation of the entire attack — 50 consecutive Nonce blind shots.

Why did the hacker use EIP-7702 on the Ethereum mainnet?

A primary hot wallet like Binance 14 internally holds dozens of ERC-20 tokens. If the hacker had initiated ordinary transfers one by one as on Bitcoin, it would not only require requesting dozens of signatures from the signing system, but would also trigger the exchange's abnormal flow monitoring and automatic circuit-breaker mechanisms within seconds of the first large anomalous movement.

By using EIP-7702 to upgrade Binance 14 in place into the malicious contract Sweeper B (0x63e8...6fae), the hacker only needed to call a single built-in function of the contract (hardcoded to allow only the hacker address 0x7c86...5ca0 to call), and could, in a single transaction and within the same block, package and drain all tokens and ETH (leaving only 1 ETH for subsequent Gas), completely eliminating the reaction time window of the risk control system.

Why stuff in 50 consecutive signatures?

EIP-7702 authorization has an extremely strict limitation — the Nonce contained in the authorization signature must exactly match the wallet's real-time Nonce at the moment the transaction is included on-chain.

Since the hacker most likely only manipulated the backend signing system interface, Binance 14 at this point was still processing normal withdrawals for global users at high frequency, with the Nonce ticking every second. Between the hacker obtaining the signature from the signing machine and broadcasting it to the chain to be packaged, there were several seconds of network and queue delay, making it impossible to predict which number the Nonce would stop at at the moment of inclusion.

To overcome this blind spot, the hacker used the compromised signing system to force the signing machine to produce, in one go, 50 consecutive incrementing EIP-7702 authorization signatures (Nonce from 18,914,775 to 18,914,824) targeting the Nonce range at the time, and stuffed them all into the same Type-4 transaction to be broadcast on-chain.

The Ethereum base layer automatically discarded the 49 invalid signatures during execution, and only the 1 Nonce that hit the real-time window precisely took effect.

An Overwhelming Chain of Sweeps and Permission Penetration

• 20:22:45 (UTC): The Tron hot wallet transferred out 612.7 million USDT in a single transaction;
• 20:24:23 (UTC): The hacker triggered the sweep function of Binance 14, and a single transaction instantly drained 167,464.25 ETH, 1.615 billion USDT, and another 62 tokens, sending them to the hacker's receiving address 0x5227...2f8c (marked as Exploiter 2 by Etherscan);
• 20:24:47 (UTC): Just 24 seconds after Binance 14 was compromised, another independent Binance hot wallet, Binance 16, without using EIP-7702, directly signed an ordinary transfer with its own private key, sending 28,005.6 ETH to the same hacker receiving address (0x5227...2f8c); 15 minutes later (20:39 UTC), the hacker packaged and transferred away a total of 195,470 ETH that had flowed out of these two wallets;
• 20:32 – 20:33 (UTC): 3 hot wallets on Arbitrum (first transaction: 3,478.4 ETH) and 4 hot wallets on Avalanche (first transaction: 432,846 AVAX) were successively looted;
• 20:41 (UTC): Another smart contract wallet, Binance 34, holding 780 million USDC, was compromised (subsequently another 43 million USDC flowed out at 20:59). Because Binance 14 happened to be the administrator (Owner) of Binance 34, after parasitically controlling Binance 14 via EIP-7702, the hacker directly used the administrator identity to conveniently drain the associated vault.

More fatally, once an EIP-7702 delegation takes effect, it persists. Until Binance completely cut off the signing machines and re-sent a zero-address authorization to override it, any subsequent funds deposited into Binance 14 would continue to be drained (as of 21:04 UTC, sporadic balances were still being continuously swept).

At present, the specific intrusion path of this security incident, as well as the follow-up tracking and freezing progress of on-chain funds, are still developing. Odaily will continue to monitor the situation and bring the latest reports as soon as possible.