Binance hot wallet drain: the signing service signed outside the withdrawal path

Attackers took about $6.34 billion from Binance on Oct. 29, 2026, by reaching an internal wallet signing service and having it sign on at least ten chains, "outside the normal withdrawal process" in the words of Binance's initial report. Multi-party computation (MPC) protected the key and had no say in what got signed, so the control to test is what your signer will refuse.

On Ethereum, one signed EIP-7702 authorization turned a hot wallet, Binance 14, into a standing sweeper that kept running after withdrawals paused, because clearing it took a signature Binance had no ready way to produce. The test applies to any company that holds digital assets or runs a service that signs or releases money on request.

The entry chain below rests on Binance's account, in a report it calls initial, with an independent review pending. Every Ethereum step can be checked on chain, and the live page keeps the minute-by-minute record.

At a glance

Timeline: attacker moves and defender moves, in UTC

The drain ran for nearly four hours, and the Ethereum delegation outlived the withdrawal pause post by 1 hour 48 minutes. Non-Ethereum times come from Binance and TRM Labs; times to the second are Ethereum chain data from Blockscout and token contract logs, apart from Yi He's 22:22:03 post.

How the attackers got in

Binance describes a campaign against its wallet team that ran from June to Oct. 29 and touched three engineers, through a tampered install, a fake job interview and then an internal AI tool that carried the attacker to two more machines.

June. Engineer A searched for a popular AI coding tool and downloaded a tampered Homebrew installation (T1204.002). Binance caught it, replaced the device and rotated related credentials. That response reads as by the book, and the attacker still learned A's role and who A's colleagues were (T1591.004). StepSecurity notes that the report does not establish uninterrupted access from June to October, so the target list is what June demonstrably gave the attacker.

September. Someone posing as a project director contacted Engineer B on a legitimate job platform and arranged two interview rounds (T1566.003). The second ended with an "assignment" repository on B's work computer, with malicious code that ran during setup (T1204.002). The malware swapped a legitimate development tool component for its own version (T1554) and endpoint tools did not flag it. Binance calls it 0-day malware; StepSecurity observes that the report identifies no software zero-day. Plan for endpoint tools to miss this class either way. The FBI's statement on DMM Bitcoin describes nearly the same lure in 2024: a fake LinkedIn recruiter and a malicious script presented as a pre-employment test. The FBI attributed that theft, and the $1.5B Bybit theft of February 2025, to TraderTraitor.

Oct. 20. From B's computer, the attacker used an internal AI tool to gain control over A and another wallet engineer, C. Binance does not say how. A's computer held a container deployment permission token (T1552), four months after the June rotation.

Oct. 29. The attacker logged on to C's computer, used A's stolen credentials (T1078), deployed a container (T1610) and triggered a script (T1059). Co-CEO Richard Teng said a self-destruct mechanism destroyed tooling and traces along the way (T1070), so logs that stay on the host may not survive. Binance's report gives the decisive step one line, unauthorized access to the signing service.

How the attack spread across chains

The signing service produced valid signatures on at least ten chains, starting with XRP at 20:05 UTC, 15 minutes before the EIP-7702 delegation landed on Binance 14. On most chains the output was a plain signed transfer (T1657, Financial Theft).

TRM Labs reads nine chains other than Ethereum as ordinary signed transfers, from wallets with different key types and signing schemes that all complied within about half an hour. Binance says only that the attacker used the signing service.

Ordinary signed transfers account for about $2.74B: $2.57B on the nine other chains plus $174M from Binance 16. Delegated moves account for about $3.6B. Controls aimed only at EIP-7702 leave about 43% of this loss in place, and signer ceilings and allow-lists alone leave the other 57% or so.

How one EIP-7702 authorization became a standing sweeper

EIP-7702, live on Ethereum since May 7, 2025, lets an ordinary account point its code at a contract through one signed authorization carrying the chain, a contract address and a nonce. The account then runs that contract's code when called, under whatever rules the contract sets, with the account's balance and rights.

Transaction 0xad99…298b came from attacker address 0x7C86…5CA0 at 20:20:59, in block 26,300,753, and carried 50 authorizations for the Ethereum hot wallet Binance 14, delegating to contract 0x63e8…6fae and covering nonces 18,914,775 to 18,914,824. Our recovery of the signatures ties all 50 to Binance 14's own key. Under the EIP-7702 specification an authorization applies only if its nonce equals the account's current nonce. One matched, nonce 18,914,809, and the other 49 failed.

The spread answers a practical problem. Binance 14 sent 232 transactions between 20:00 and 20:21, so the attacker could not know its nonce at the moment of landing. Elliptic reads the spread the same way. Binance's report describes 50 signing transactions used to manipulate the nonce. The chain shows one transaction, 50 signed authorizations and a nonce that moved by one. Binance's wording may mean 50 signing requests to the service.

That one authorization was enough. The first sweep came 3 minutes 24 seconds later. Six more value-moving calls followed at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56, and none needed a new Binance signature. Delegation also inherited what the wallet controlled: per TRM, Binance 14 was executor of a separate smart account, Hot Wallet 34, which is how 823M USDC left.

Why pausing withdrawals did not stop it

A withdrawal pause acts on the withdrawal system, and the delegation lived on chain. Binance said on Oct. 30 that outflows ceased at the pause. Its Nov. 3 report says suspending withdrawals could not stop everything and that shutting down hot wallet services did not automatically invalidate the authorization either. Sweeps landed at 22:39:35 and 23:56:47, after the 22:22:03 pause post. Binance says the last transfer had been broadcast earlier and stayed pending, and gives no broadcast time. The 2,961.99 ETH behind it reached the wallet at 23:55:47, one minute before it landed.

The delegation stood for 3 hours 49 minutes 36 seconds, and the 50 authorizations were not the reason. Thirty-four were already behind the nonce on arrival. Binance 14's ordinary traffic spent the 15 ahead of it by 20:24:23, 3 hours 46 minutes before the clear, after which none could ever apply. An unspent authorization for a later nonce could in principle reinstall a delegation after a clear, so a responder should check for them, but here none remained.

Clearing a delegation takes a signature from the same account. Binance's stated reason for the delay is that MPC offered no single key to revoke with, so its team had to develop a procedure. In our view the obstacle was tooling and policy more than cryptography. Halborn points out that the attacker got fifty signatures from that wallet, and from 22:55 Binance 14 was sending ordinary token transfers to an address tagged Binance, which fits Elliptic's reading of moves after the pause as Binance's own.

Binance's own wallets fed the sweeper in the meantime. At 21:42:59 a wallet tagged Binance 124 sent 200M USDT into Binance 14, 41 minutes after the receiving address was blacklisted, and it was swept 72 seconds later. The 2,961.99 ETH behind the final sweep came from an address tagged Binance Deposit. The likely reason is automated rebalancing, which Binance has not addressed.

What was frozen, and why ETH and BTC could not be

Binance and Elliptic both put the frozen total at $2.85B, which is 44% on Elliptic's total. Freezing is a property of the token. Native ETH, BTC, XRP, SOL and NEAR have no issuer, as Elliptic notes, and Ripple can freeze RLUSD but not XRP. Layer 2 governance did act: Arbitrum's Security Council forced funds out, and Elliptic says everything stolen on Arbitrum and Optimism has been secured.

Outside parties set the pace of the race. Tether blacklisted the receiving address 37 minutes 12 seconds after the first sweep and about 56 minutes after the first outflow. Circle followed 23 minutes 36 seconds after the first USDC arrived.

In that window 700M USDT left. TRM reports about 325M sold for about 122,300 ETH at a steep discount, and Chainalysis values what the attacker received at $285M. Another 175M was frozen downstream. The other 200M went through hop wallets and Uniswap, and 30M of that was frozen.

A blacklist leaves inflows open. Another 204.32M USDT landed in 0x5227…2f8c after the freeze, until the attacker changed destination by 22:39:35. The address held 1.175B USDT and 823M USDC on Nov. 6, unchanged since Oct. 31.

The unfrozen holdings mostly sit still. On Nov. 6 the FBI-listed Ethereum addresses held 551,612 ETH, more than the 200,630 ETH stolen because stablecoins and other assets were converted, with the seven largest at nonce 0. The 19 FBI-listed Bitcoin addresses held 18,270.20 BTC with no spends. Elliptic's laundering tracker shows XRP moving, with about $50M swapped and about $226M left.

Root cause and contributing factors

The decisive failure sat between the caller and the signer: a newly deployed container, using an engineer's credentials, got signatures for requests the withdrawal layer never saw. Binance has not said why the signer complied. MPC and the absence of a key leak, as Binance reported, are both consistent with this, and Halborn makes the same point about MPC. Teng said the delegation bypassed normal approval controls. In our view, as in Halborn's, the attacker went around whatever policy the withdrawal layer held.

Contributing factors, each visible in the record:

• A deployment token on an engineer's computer, and a new container that could reach the signer.
• Outside code run on a work computer, and an internal AI tool that gave that machine control of two others.
• A caught incident that still leaked the team's roles to the attacker.
• An alert that fired before Bitcoin, Tron and the delegation landed, and did not stop them.
• No ready path to clear a delegation. Binance developed its procedure during the incident; TRM recommends keeping a tested, pre-approved one.
• Refills to a wallet already under attack.

Binance says it has since rebuilt the affected wallet system and AI tool, replaced devices, decommissioned affected tokens and strengthened wallet-service risk controls.

The signer lesson transfers beyond crypto, and EIP-7702 does not. A payments firm with an HSM behind its wire-release API has the same shape: the HSM guards the key, and the question is what the release service checks when a new internal caller asks it to sign a payment file. The standing grant has equivalents too. A new direct-debit mandate or a long-lived API key keeps working after someone pauses the front end, so list those and rehearse revoking them.

What would have stopped it

No single control covers this chain. Signer policy stops the ordinary transfers and the authorization, and once a delegation exists only monitoring outside the signer and a tested clear path help.

Refusing authorizations has a condition. An authorization is a separate signed message, so a policy that reads only transactions may never see it, and raw-digest signing defeats any policy. The delegation transaction also carried zero value, and as Metrika says, value caps alone would not have stopped it.

What to check in your environment

Start with the signer test (check 1), then the block-speed alert (check 7), because they decide the outcome in the first minutes.

Detection a defender can run

• Code check at block speed. Read the code of every treasury account each block and page on any value starting 0xef0100. Binance 14 had no code at block 26,300,752 and carried the prefix at 26,300,753. The window to act was 3 minutes 24 seconds.
• Alert on the authorization list, not the sender. A type-4 (set-code) alert keyed on a treasury sender would have missed this, because the sender was the attacker's calling address, 0x7C86…5CA0. Alert on any type-4 transaction, from anyone, whose authorization list recovers to one of your addresses. TRM adds that a request for many authorizations across a range of nonces is itself an indicator of compromise.
• Nonce gap. Binance 14's nonce went from 18,914,808 to 18,914,810 at 20:20:59 with no transaction of its own at 18,914,809. A nonce manager can flag that.
• Signer logs. Alert on any request that is not a transaction your application built, and on any new caller identity.
• Outbound monitoring outside the signer. Correlate outflows across chains and tie the alert to an automatic signing cut. XRP, Solana, Optimism and Bitcoin all moved within about 15 minutes. Whether a cut would have caught the delegation depends on when the 50 were signed, which is not public.
• Deployment logs. Alert on a new container in any segment that can reach the signer when the deployment token comes from an engineer's computer.
• Host indicator. Binance published one: on macOS, the pyenv file at /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv changed from 3,344 to 3,414 bytes. Hunt for it, and compare developer tool binaries against clean copies of the same version.
• Screening. As of Nov. 6 the FBI lists 608 Ethereum, 19 Bitcoin and one Solana address. Its list omits the receiving address 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c, calling address 0x7C8601d4645b93cea45F71e118A729332e6B5CA0, delegate 0x63e842B054Bd624a465454D533C33F573e9c6fAe and 0xA97bF7836F8A08F9Ed91D41453D371493FAE8d10, so add them. American Banker found none of the FBI's 628 addresses on OFAC's list as of Nov. 4, so an OFAC-only screen misses all of them.

A ten-point check to run this week

What we still don't know

Binance says some details stay confidential, and an independent review with no published date may settle others.

• How the signing service authenticated the container. This is the open root cause, and it decides whether caller checks alone would have held.
• Whether the signer accepted raw digests, as Halborn asks. If it did, transaction-level policy could not have helped.
• When the 50 authorizations were signed, and whether more exist unpublished. None was used through nonce 18,915,338.
• How many signers exist per chain, and how Avalanche and Polygon were signed at about 23:05, after the pause post. That second wave suggests signing access outlived the pause.
• When the alert fired, when signing access was cut, and when the pause took effect. The 22:22:03 time is that of Yi He's post.
• Whether anyone tried to clear the delegation before 00:10:35.
• How the internal AI tool gave control of A and C, and which product it was.
• How a deployment token sat on A's computer after the June rotation, whether it survived or was reissued.
• Whether the June and September compromises share access. Binance links them only through role exposure.