Binance Theft Makes On-Chain Authorization Part Of Response

Binance's November 3 initial report says attackers obtained unauthorized access to an internal wallet transaction signing service and moved approximately $6.34 billion in digital assets on October 29. The campaign combined compromised developer devices, fake job interviews, malicious code, an internal AI tool, a container-deployment token and wallet signing operations. The FBI attributes the theft to North Korea's TraderTraitor activity. Binance says it will absorb the loss, had restored 98 percent of the affected token assets by October 31 and had frozen or intercepted about $2.85 billion, but its investigation and an independent review remain open.

The incident is also a containment lesson. Binance says the attacker used valid signing operations to install malicious EIP-7702 delegations on a hot wallet. Those on-chain authorizations continued to operate after ordinary withdrawals and hot-wallet services were suspended, and the wallet's multiparty-computation design meant there was no single private key available for an immediate revocation. Exchanges and custodians should separate software deployment from signing authority, constrain every signing policy by transaction purpose, inventory persistent on-chain permissions, prebuild chain-specific revocation procedures and treat developer-device compromise as a path to production authority rather than an endpoint-only event.

Binance says the October 29 attack used unauthorized access to an internal wallet transaction signing service, outside the exchange's usual withdrawal process. Five hot wallets sent 233.46 million XRP, while wallets on Solana and Optimism sent about 970,500 SOL and 44.2 million OP. A hot wallet also sent 18,270 BTC. Binance puts the total affected assets at approximately $6.34 billion and says about $2.85 billion had been frozen or intercepted as of the update, subject to reconciliation and price movement.

The FBI separately says North Korea was responsible for the theft and identifies the activity as TraderTraitor. Its October 31 alert asks node operators, exchanges, DeFi services, blockchain-analytics firms and other virtual-asset providers to block transactions with or derived from the published addresses. That attribution is a government assessment. Binance's report cites it rather than presenting an independent public attribution method of its own.

Binance says it reserved more than enough funds to cover the loss and that 98 percent of the affected token assets had been restored by October 31, with less-liquid assets still being acquired. Restoring customer backing and recovering stolen assets are different measurements. The company says there were no further unauthorized transfers after a final pending 2,961.9 ETH transaction confirmed at 23:56 UTC, but the report does not publish a complete independent accounting or final forensic conclusion.

The reported preparation began months before the theft. Binance says a Wallets DevOps engineer downloaded a modified Homebrew installer in June while trying to install an AI programming tool found through search. Security staff detected an anomaly, replaced the device and renewed related credentials. Binance nevertheless says the attack exposed that workstation and devices used by colleagues associated with wallet infrastructure. The report does not yet explain which persistence or trust relationship survived the initial response.

In September, a second software engineer was approached on a legitimate job platform. The supposed employer conducted video interviews and then sent a technical test through a messaging app. The repository ran malicious code during setup, replaced a legitimate development component and communicated with attacker infrastructure. On October 20, Binance says the attacker used that compromised device and an internal AI tool to reach two other engineers, then found a token on one computer that could deploy containers.

On October 29, the attacker logged into another engineer's computer, used the stolen deployment credential, deployed a container and ran a malicious script against wallet signing operations. The sequence shows why replacing one laptop and rotating directly visible credentials may be insufficient. Responders need to map tokens, build systems, developer tools, automation identities, shared services and downstream workloads that trusted the compromised user or device. A clean endpoint is not a clean production control plane.

EIP-7702 lets an externally owned Ethereum account delegate execution to code. The standard is intended to support capabilities such as batching and account abstraction, but its security notes stress that delegated code can exercise broad account authority and must be carefully audited. Binance says the attacker used its signing service to create malicious delegation authorizations for a hot wallet. The protocol feature did not bypass a valid signer; compromised infrastructure supplied the signing authority the protocol requires.

Binance says the attacker sent 50 signing transactions to manipulate the account nonce and establish the delegations. Once they were recorded on-chain, the attacker-controlled contract could continue moving assets independently of the exchange's normal withdrawal system. Shutting down withdrawals and the hot-wallet service reduced other paths but did not cancel authority already committed to the ledger. At 00:10 UTC on October 30, Binance sent a new authorization to the zero address to remove the delegation code.

Multiparty computation protects against one stolen private key, but it does not make every correctly produced signature safe. Binance says there was no single private key available to revoke the malicious authorizations immediately, so the team had to develop and execute a specialized procedure. Custodians should therefore model signing policy, delegation state and revocation as separate controls. A quorum that can authorize a new capability needs a tested way to remove that capability under incident conditions.

A deployment token should not be enough to place arbitrary code beside a signing service. Separate wallet infrastructure from general developer environments, require narrowly scoped workload identities, bind releases to reviewed artifacts and make production admission verify provenance and expected behavior. High-value signing code should run from minimal, reproducible images with restricted outbound access, immutable logging and independent approval for changes to transaction policy.

Signing controls also need semantic limits. Set allowed chains, wallet roles, destination classes, asset ceilings, transaction types, nonce behavior, delegation targets and rate thresholds. An approval should cover the intended operation, not merely the fact that an authorized service asked for a signature. Detect changes in EIP-7702 delegation state as a first-class wallet event, and route them to operators who can compare the requested code, chain and account against an approved inventory.

Pre-stage response procedures for every supported chain. Record which action suspends exchange workflows, which action blocks new signatures, which on-chain transaction removes persistent authority and which quorum can approve it when normal systems are unavailable. Exercise those paths with test wallets and degraded participants. The goal is not to weaken MPC. It is to ensure that quorum safety does not become revocation delay when the signed state itself is hostile.

Preserve endpoint, identity, job-platform, messaging, source-control, package, AI-tool, container-registry, orchestration, signing-service and blockchain evidence under one timeline. Look for technical-test repositories, unexpected setup commands, replaced binaries, new symbolic links, unapproved containers, use of deployment tokens, changes to signing policy and anomalous authorization tuples. A later clean scan cannot prove that earlier credentials or sessions were unused.

Rotate or revoke credentials at the systems that issue them, then verify every consumer. Replace compromised developer devices from known media rather than trusting an in-place cleanup. Review colleagues and automation that shared the same wallet project, build path, AI service or secrets. Binance says it rebuilt the affected wallet system and internal AI tool, replaced devices and deactivated associated credentials and tokens. Those are material steps, but the report does not yet expose enough detail to assess their completeness.

Virtual-asset services should ingest the FBI's addresses with provenance and time stamps, trace derived flows and preserve decisions about blocks or holds. Ordinary Binance users should rely on verified exchange notices and account records, not messages claiming to recover funds or revalidate wallets. The public report describes corporate wallet infrastructure, not theft of customer passwords or a requirement for users to send assets to a new address.

Binance calls the report initial and says technical details are being withheld while an independent review proceeds. It does not yet publish the exact signing-service architecture, how the AI tool mediated access, why the June response did not eliminate the later path, which policies approved the 50 authorization transactions or a complete asset reconciliation. Those questions matter because each one identifies a different preventive control.

The incident should not be reduced to one malicious interview, one zero-day label or one blockchain feature. The reported loss required a chain of access that crossed endpoints, people, developer tooling, internal automation, deployment and signing. Breaking any one of those links could have reduced the result, but only the final review can establish which controls were absent, bypassed or operating as designed.

NIST's incident-response guidance treats preparation, detection, containment, recovery and improvement as continuing risk-management work. Apply that discipline here: document the authority graph before the next alert, measure revocation time, test clean rebuilds, preserve on-chain and off-chain evidence together and update the threat model when new findings arrive. The durable lesson is that a valid signature can still authorize an invalid business outcome.