The approach to wallet infrastructure
According to Binance, the first known episode came in June, when a Wallet DevOps engineer downloaded a tampered copy of Homebrew while installing an AI coding tool. Security staff spotted the anomaly, replaced the device and rotated associated credentials. The exchange says the attacker had nevertheless learned the engineer's role and the identities of colleagues working on wallet infrastructure.
In September, another engineer was contacted through a legitimate job-search platform. Two rounds of a fake interview led to an instruction to download a coding assignment to a work computer. Malicious code ran during project setup and replaced a component of pyenv. Binance says its endpoint protection did not identify the threat at the time. The chronology links the access points the company has identified, but does not mean every later step was inevitable.
From an endpoint to transaction signing
Binance says that on October 20 the attacker used the second engineer's compromised machine and an internal AI tool to reach two more employees' devices. One device held a token with container deployment rights. On October 29, the attacker used stolen credentials to deploy a container and run code against the transaction-signing infrastructure.
The exchange describes unauthorized access to an internal signing service that enabled transactions outside its normal customer withdrawal flow. It says it found no evidence that hot-wallet private keys leaked. That distinction matters: control over an authorized signing service can enable asset transfers without exposing the underlying key itself.
Why a withdrawal pause was not enough
The Ethereum portion of Binance's report identifies EIP-7702 delegation as a separate containment problem. With access to the signing service, the attacker authorized a smart contract to exercise some execution rights over a hot wallet. The authorization existed onchain, outside the exchange's ordinary withdrawal infrastructure. Pausing user withdrawals and shutting down hot-wallet services therefore did not automatically invalidate permissions already recorded on the network.
Binance had to submit separate transactions to revoke the delegation. Because the wallet used multi-party computation, one private key could not immediately sign a revocation. The final unauthorized transfer, involving 2,961.9 ETH, was confirmed after it had previously been broadcast. The exchange then recorded an authorization to the zero address to remove the delegation code. This sequence explains why containment took longer than a simple withdrawal shutdown might suggest.
Recovery figures and unanswered questions
Binance puts the affected assets at approximately $6.34 billion. As of November 3, it said about $2.85 billion had been frozen or intercepted and 98% of affected token assets had been replenished through reserves and purchases. Replenishing balances is not the same as recovering stolen assets from the attacker; the frozen figure may also change with reconciliation and prices. The company says customers will not bear the financial loss.
The exchange says it rebuilt the affected wallet systems and internal AI tool, replaced devices and disabled the related credentials. It plans an external security review while keeping some technical details private. Its report is explicitly preliminary, not an independent finding on the attack's cause. For infrastructure teams, the account highlights the need to scrutinize each handoff among developer workstations, development tools, internal assistants and signing services.
