← All intelligence

Security engineering · Reported incident

Binance hack explained: how $6.3 billion left in twenty minutes

The 29 October 2026 Binance hack, step by step: the laptop foothold, the EIP-7702 sweeper, the twenty minute drain, the freezes and the controls defenders should check.

By Collin Ambani Anjeo ·

Based on Binance statements and the TRM Labs and Elliptic analyses available on 31 October 2026, 05:00 UTC. Figures are preliminary, the sources differ slightly, and Binance has not yet published a root cause.

Storyboard of the Binance hack in seven illustrated steps: staging, the laptop foothold, the exchange signing for the attacker, the drain, fifty pre-signed authorisations, the freezes and the defences
AI-generated editorial storyboard; visual metaphors for each reported step, not photographs of the event.

What happened in the Binance hack?

On the evening of 29 October 2026, UTC, Binance hot wallets on about ten blockchains sent funds to attacker addresses. Binance puts the affected client assets at about $6.3 billion. TRM Labs counts about $6.36 billion and Elliptic about $6.43 billion, valued at the time of each transfer. Either way it is roughly four times the $1.5 billion Bybit theft of February 2025, previously the largest on record.

Binance paused withdrawals, says client funds are safe and has committed to cover all losses from its SAFU fund and company funds. What follows reconstructs the attack from the published on chain analysis and Binance’s own statements. Where those sources hedge, we hedge too.

Step 1: staging the attack

The preparation started at least a day and a half before the theft. From 28 October a fresh operator wallet received three small withdrawals of 0.1 ETH from the Tornado Cash mixer. On 29 October the attacker deployed a purpose built "sweeper" contract, tested it on practice wallets and rehearsed the final version about four hours before turning it on Binance.

Small mixer withdrawals funding an operator wallet, and staging well ahead of the theft, are patterns both TRM Labs and Elliptic have seen in earlier thefts attributed to the same group.

Step 2: the foothold on an engineer’s laptop

Binance’s preliminary account is that the incident may involve a compromised DevOps engineer’s laptop, which gave the attacker access to a service container able to submit withdrawal transactions.

Binance has since said its investigation found further points of breach, and co-CEO Richard Teng described a more complex process than the misuse of a single engineer’s permissions. How the laptop was compromised has not been disclosed, so any account of phishing or malware at this stage is speculation.

Step 3: getting Binance’s own systems to sign

Binance says it has found no evidence that any wallet private key leaked. Both analytics firms reach a compatible conclusion from the on chain evidence: the attacker appears to have been able to make Binance’s hot wallet signing system sign transactions of the attacker’s choosing.

That matters because the affected wallets used different chains, key types and signing schemes, yet all of them produced valid signatures for the attacker within about half an hour. TRM Labs reads the batch of authorisations described below as a sign that the access was limited in time or had to pass through a request system. Elliptic also reports a self destruct mechanism that removed the attacker’s tooling as it ran.

Step 4: the twenty minute drain across ten chains

At 20:05 UTC five Binance wallets on the XRP Ledger sent 233 million XRP to one attacker address. Over the next half hour wallets on Solana, Optimism, Base, Arbitrum, Avalanche, Tron, Bitcoin and Ethereum followed, through ordinary, validly signed transfers. At 20:20 the Bitcoin hot wallet alone sent 18,270 BTC, worth about $1.47 billion, and the Tron wallet sent 612.7 million USDT within two minutes of it.

Most of the value left in about twenty minutes. A second, smaller wave hit Avalanche and Polygon shortly after 23:00 UTC.

Step 5: how the EIP-7702 delegation worked

EIP-7702, introduced with Ethereum’s Pectra upgrade in May 2025, lets an ordinary wallet delegate its behaviour to a smart contract by signing an authorisation. Each authorisation is tied to the wallet’s transaction count, its nonce, so it only works if that count matches when it lands.

At 20:20 UTC the attacker submitted one transaction carrying 50 authorisations, all validly signed by the Binance hot wallet and each prepared for a different nonce, so that one would be valid whatever the wallet’s count was by then. One matched. Control of the wallet passed to the sweeper contract, which accepts instructions only from the attacker. About three and a half minutes later it emptied the wallet of 167,464 ETH and 63 tokens, including about 1.6 billion USDT.

The delegation stayed in place, so no new signatures were needed. The attacker swept fresh deposits into the wallet several more times until 23:56 UTC and used the wallet’s rights over a separate Binance account to pull 823 million USDC. Teng has said this delegation did not pass through Binance’s normal approval controls.

Step 6: freezes against laundering

Stablecoin issuers moved quickly. Tether froze the main receiving wallet 37 minutes after the stolen USDT arrived, and Circle froze 823 million USDC minutes later, in coordination with law enforcement. Ripple, World Liberty Financial and others froze their tokens, and the Arbitrum Security Council moved stolen ETH and ARB out of attacker wallets. Elliptic has verified about $2.85 billion frozen or seized, roughly 44 per cent of the theft, and Binance puts the figure near $3 billion.

The attacker raced to convert stablecoins before the freezes landed. Elliptic traced 434 million USDT swapped for ETH through Uniswap, 1inch and market makers at a loss of 12 to 26 per cent, a USDT deposit into Aave used to borrow ETH, and 234 million USDT on Tron swapped for TRX. The 18,270 BTC was split through a short peel chain into round amounts. Nothing on Bitcoin, the XRP Ledger or Solana has been frozen, because those assets have no issuer who can freeze them.

Who was behind the Binance hack?

TRM Labs attributes the theft with high confidence to TraderTraitor, the North Korean group the FBI named for the Bybit theft. Elliptic considers TraderTraitor likely, citing links to earlier thefts, and Chainalysis has said the activity appears to be the group’s work.

No government or law enforcement agency has confirmed the attribution. The FBI has said it is aware of the incident and coordinating with partners, and Binance has not attributed responsibility to anyone.

Will Binance customers lose money?

Binance has said it will cover all losses from its SAFU fund and company funds, and that it has reserved more than $6.34 billion for the purpose. It has promised a full proof of reserves report and a detailed technical post mortem once its investigation is complete. Withdrawals were paused while it rebuilds its withdrawal service, with resumption expected within days.

Lessons for exchanges, custodians and treasury teams

Pentriarch analysis. The specifics are still emerging, but the shape of the attack already points to controls any organisation that moves money can check this week.

Treat engineer endpoints as part of the perimeter. Access gained from one laptop should never be enough, on its own, to move funds. Give every path to a signature the same approval controls. A delegation, an administrative action or a service account that skips the normal approval path is the vulnerability, however rarely it is used. Alert on unexpected EIP-7702 delegations on treasury wallets, and make signing policies reject authorisations nobody expected. A request for many authorisations across a range of nonces should be treated as an indicator of compromise. Separate signing infrastructure and approval paths by chain and wallet tier, so that one foothold cannot produce valid signatures everywhere at once. Keep a tested, pre-approved way to revoke a delegation, and rehearse it before you need it.

Where Pentriarch fits

Pentriarch does not audit wallet custody or blockchain signing infrastructure, and nothing here should be read as a claim that a particular tool would have stopped this attack.

What we test is the question underneath it: what can an attacker make your systems do on their behalf? For web applications, APIs, AI agents and MCP servers, that means checking which privileged actions an internal service or agent can reach, whether every such action passes through the same authorisation, and proving each finding with evidence your engineers can replay and a retest that states what is fixed.

Sources

Binance hack explained: how $6.3 billion left in twenty minutes | Pentriarch