Binance Hack Report: The Signing Service Answered, Four Days On

On November 3 Binance published its initial findings on the October 29 theft, and the one sentence that matters reads: the attacker "exploited unauthorized access to an internal wallet signing service to initiate transactions outside the normal withdrawal process." Four days ago I argued from the chain that nobody stole a key and that the compromise sat upstream of every signer. Binance has now said so itself. This piece covers only what the report adds. The mechanics of the EIP-7702 delegation, the freezes and the asset-class argument are in the original and I will not repeat them here.

First, the signing service, not the withdrawal service. The attacker did not forge withdrawal orders and push them through the normal pipeline. They reached the component that produces signatures and asked it directly, which means that whatever policy Binance applied to withdrawals lived in the layer the attacker walked around. That is the difference between a bypassed control and a broken one, and it is the finding every custody architect should take from this report.

Second, the fifty signatures. Binance writes that the attackers "submitted 50 signing transactions to manipulate the account nonce and establish malicious delegation authorizations." In plain terms, the delegation that turned Binance 14 into the attacker's sweeper was not phished from a human and not produced from a stolen key. It was requested fifty times from the same signing service that signed the transfers on the other nine chains, and the service signed fifty authorization messages that are not transactions. The reading I offered on October 30, a signer that signs what it is given without parsing it, is now the simplest explanation of Binance's own words, although Binance has not said whether the signer saw digests or typed requests.

Third, the wallet is MPC, and that is why the revocation took four hours. Binance says that because Binance 14 uses multi-party computation there was no single private key with which to sign a revocation, and the team "developed and executed a specialized procedure" to produce the authorization to the zero address. It also says, in as many words, that suspending withdrawals and shutting down the hot wallet services did not touch the delegation, which lived on-chain and ran independently of the withdrawal infrastructure. The attacker obtained fifty 7702 signatures from that wallet in minutes. The owner needed close to four hours to obtain one, because its tooling had never been built to sign anything but withdrawals. If you run an MPC hot wallet on any EVM chain, that paragraph is addressed to you, and I come back to it below, because half of it is true and half of it is an excuse.

The first statement on October 30 spoke of a compromised DevOps engineer's laptop. The report replaces that with a four-month chain through three engineers, and the DevOps engineer is not where it starts.

June. Engineer A, on the Wallet DevOps team, searched for a popular AI coding tool, found a tampered Homebrew installation and ran it. Binance's security team caught the anomaly, replaced the device and rotated every related credential. That is the correct response and it did not end the campaign: the attacker left with Engineer A's role and the names of his colleagues on the wallet infrastructure team. Binance says it detected and prevented 57 suspected North Korea-linked cases during 2026. The report does not say whether the June incident is one of them. Either way, it was caught and still produced the target list.

September. Engineer B, whose profile on a legitimate job platform mentioned Binance, was approached by a supposed project director. A first-round video interview with an HR representative who shared a personal social media account, photos and videos included, to build trust. A second round in a chat app with the CEO of a company that does not exist. At the end, an "assignment": a code repository to download onto his work computer. The setup script replaced the pyenv shim under Homebrew with a malicious file of almost the same size, which the report lists as 3,414 bytes against the original 3,344, deleted the binary link, created a new one and spawned a shell that phoned home. Every later invocation of pyenv ran attacker code. The endpoint protection did not detect it, and the malware removed its own traces. The FBI documented the same lure in the DMM Bitcoin case in 2024, via a vendor employee. It still works.

October 20. From Engineer B's machine, the attacker used an internal AI tool to gain control over Engineer A and over a third wallet engineer, C. Binance does not say what the tool was or how it granted that reach, only that it has since been rebuilt with new access controls. On Engineer A's computer the attacker found a container deployment permission token. One compromised laptop had become three, and one of the three held a credential that could deploy workloads.

October 29, 17:15 to 19:56 UTC. The attacker logged onto Engineer C's computer, used Engineer A's token to deploy a container, and triggered a script from inside it. The script talked to the internal wallet signing service, and the signing service answered. The first XRP left at 20:05. Binance says an internal alert on large-volume transfers fired after the Solana and Optimism outflows and that the investigation began at once; on-chain data shows the Bitcoin transaction and the Ethereum delegation came minutes later anyway.

Intrusion chain · June to October 29, 1 mechanism unexplained

Every box comes from Binance's report or from the chain. The dashed one is where the root cause lives, and the report does not open it.

The report answers how the attacker got in and what they reached. It does not answer why the signing service did what it was asked, and that is the root cause. Binance calls the document initial, says some technical details will stay confidential, and has engaged independent security firms for a further review. These are the questions that review has to answer, in the order I would ask them.

Who may call the signing service, and how does it know? A container deployed with an engineer's platform token became a valid client of the component that moves billions. Whether the service authenticated the caller at all, whether it trusted anything inside its network segment, or whether the stolen token itself carried that right, is not stated. This single answer decides whether the fix is a network policy, an identity design or a rebuilt service.

What did the signer check before signing? Fifty authorization messages that are not transactions went through. Either the service signs raw 32-byte digests, in which case no policy on destination, amount or message type could ever run, or it understood what it was signing and had no rule against it. Binance's remark that it is reviewing "signing policy coverage" suggests the first. The request log settles it in an afternoon.

Why did the second wave land after the pause? On-chain data shows Avalanche and Polygon were hit at 23:05, after withdrawals were suspended. The report says the last Ethereum transfer, 2,961.9 ETH at 23:56, had been broadcast earlier and sat pending, which supports the idea that late movements were signed and held. It says nothing about Avalanche and Polygon, and it does not say when signing access was actually cut.

Why did Binance's own pipeline keep feeding the compromised wallet? On-chain data shows two hundred million USDT moved into Binance 14 at 21:43, eighty minutes after the drain, and the attacker's code took it a minute later. The report does not mention replenishment.

What was the internal AI tool, and what could it do? The report says it was used to gain control over two engineers from a third one's machine, and that it has been rebuilt. Nothing else. For every bank that is rolling out internal assistants and agents right now, this is the most important unanswered question in the document.

What supports the statement that no key material was accessed? The report repeats that no private key leaked and notes that the wallet is MPC, so no single key exists. It does not say what was checked. Absence of evidence is not the same claim as evidence of absence, and the independent review should say which one it is.

"There was no single private key to revoke with" is half truth and half excuse, and the excuse is the half worth examining. Revoking a 7702 delegation does not require a key. It requires one valid signature from the account over a new authorization tuple: the chain ID, the zero address and the account's current nonce. An MPC quorum signs that the way it signs anything else. If Binance's quorum could not, the real reason is one of three.

Either the MPC platform or its policy engine does not support signing a type-4 authorization, the hash with the 0x05 prefix, or allows it only through a raw-signing mode that was disabled. And if raw signing was disabled, the question writes itself: how was the malicious authorization signed? Or the approval quorum is human and slow, approvers, co-signers and time windows, and it lost the race against a sweeper that drains in the same block it is called. Or the compromised component was itself part of the quorum, in which case the problem was never MPC. It was governance.

The conceptual failure is worse than the delay. The standard break glass of an MPC platform, freeze the workspace, take down the co-signers, stop all signing, is designed for one scenario: no more signatures leave. A 7702 delegation is a different scenario: the account now has code. Once the delegation is installed the attacker does not need another signature from anyone. One authorization has turned the account into a persistent proxy whose execution always resolves to the attacker's logic, and it fires every time anyone calls the address, the owner's own deposit sweepers included. Freezing the MPC at that moment removes the one thing that could still save you, the ability to sign the revocation. Binance says as much when it notes that suspending withdrawals and shutting down the hot wallet services did not touch the delegation.

And the race is harder than it looks. The revocation's nonce has to match the account's nonce at execution, and delegated code can bump that nonce with a CREATE and invalidate a revocation that is already in flight. If the malicious authorization was signed with chain ID 0 it is valid on every network, and since the nonce differs per chain, revocation becomes one operation per chain. Qi, Wang, Li, Zhu and Chen describe that chain-agnostic mode, and the lasting control a single authorization grants, in their December 2025 paper on 7702 phishing: the technique was documented against retail wallets a year before it was used against an exchange. In Binance's case, on-chain data shows all fifty tuples carried chain ID 1, so the delegation was confined to Ethereum by the attacker's choice, not by luck.

What should exist in an MPC hot wallet on any EVM chain after Pectra:

1. A policy that denies by default any 7702 authorization and any raw signing. Unless a documented use case exists, such as batching or gas sponsorship, a custody hot wallet has no reason to delegate code. That gap is the root cause on Ethereum, not the absence of a single key.
2. One pre-approved exception: an authorization to the zero address or to an allowlisted rescue delegate of your own, signable under a reduced quorum or by an automated incident signer in an HSM or a TEE that does not wait for humans.
3. Better than revoking to zero: a single type-4 transaction that re-delegates the account to your rescue contract and, in the same transaction, calls the sweep to cold. Authorizations are processed before execution, so you revoke and rescue in one transaction, submitted through a private channel so the attacker cannot front-run it. If the account itself sends that transaction, its authorization nonce must be the account's current nonce plus one, because the sender nonce increments before the authorization list is processed.
4. Monitoring of eth_getCode on every hot address on every chain: the prefix 0xef0100 is a P0 alert and an automatic trigger of the runbook.
5. A runbook that has been rehearsed, which is the item nobody does.

On the question I have been asked all week, how a top exchange can run hot wallets on MPC: MPC in the hot tier is standard and it is fine. The mistake is treating MPC as the control. MPC splits the key; it does not decide what gets signed. The control is the policy, and on October 29 the policy let something be signed that should never have been signable.

The nine controls in the original piece stand. This report adds five, and each one comes from a sentence Binance wrote rather than from a hypothesis of mine.

The signer must authenticate its callers, not just its requests. A policy engine inside the signer is necessary and, on this evidence, not sufficient: a freshly deployed container must not be a valid client of the signing service by virtue of running inside the environment. Workload identity, mutual authentication, an allowlist of callers and a separate approval for adding one. The check is a red team exercise: deploy a workload with a valid platform token and show that it cannot obtain a signature of any kind.

Internal AI tools belong in the threat model, today. Binance's attacker turned one compromised laptop into three through an internal AI tool. An assistant or agent that can read engineers' environments, run commands or hold credentials on their behalf has the combined privileges of everyone who uses it, and an injection into it is a compromise of everyone it can act for. Give each such tool its own identity and least privilege, deny it standing access to credentials and to anything that signs, log every action it takes on a human's behalf, and test that one compromised user cannot reach another through it. This is one of the first publicly documented large thefts where an AI tool is a named step in the kill chain, and it will not be the last.

An alert is not a control at machine speed. Binance says its internal alert fired after the Solana and Optimism outflows and the investigation began at once. On-chain data shows Bitcoin, the Ethereum delegation and Tron followed within fifteen minutes. A human reading an alert cannot beat a script that has already rehearsed. The first anomalous outflow across chains should cut signing automatically, with a human needed to restore it rather than to stop it. The check: a simulated drain on one chain halts signing on every chain before the second transaction confirms.

Device replacement is not containment, and the developer toolchain is the entry point. The June incident was handled by the book, and the attacker still walked away with an org chart. Treat any engineer-endpoint compromise as exposure of that engineer's team, and follow it with targeted lure awareness for the people around him. Then close the toolchain: Homebrew taps, language version managers and AI coding tools pinned and verified from an internal mirror, never from a search result; nothing from a recruiter ever runs on a work machine; and no long-lived deployment token rests on a laptop. Binance says it prevented 57 suspected North Korea-linked cases this year. The control has to hold against the one that gets through, and endpoint protection did not.

If the signer is MPC, the revocation is a policy exception you design in advance, not a procedure you invent at 22:00. The section above spells out what that exception looks like, why the standard break glass of an MPC platform works against you once an account has code, and why the same logic applies, with its own mechanics, to any chain where authority can persist on-chain independently of the signing infrastructure.

The numbers have settled and the attribution is official. What has not moved is the frozen money, which stays frozen until an issuer burns and reissues it under a legal process nobody has put a date on.

Two questions to add to the twelve I suggested for your custody provider.

1. How does the signing service authenticate its callers, and can a newly deployed workload with a valid platform token obtain a signature? Show me the test that proves it cannot.
2. Which internal AI tools or agents can reach engineer environments, credentials or signing paths, under whose identity do they act, and what stops one compromised user from reaching another through them?

I will write once more when the independent review is published. Until then, the chain Binance describes is reported, the on-chain record is observed, and the reason a signing service answered a stranger is still inferred.