Binance Traces $6.34 Billion Crypto Theft to Compromised Developer Devices

A compromise that unfolded over months

Binance’s account of the Oct. 29 theft points to a long-running compromise of its wallet engineering staff, rather than a single break-in. The exchange says attackers moved about $6.34 billion in digital assets after gaining access through a tampered developer tool in June and a malware-laced job exercise in September. The account describes a sequence of intrusions that eventually reached systems involved in deploying wallet infrastructure and authorizing transactions.

That timeline matters: Binance says it detected the first compromise and replaced the affected engineer’s computer, but the attackers had already reached colleagues working on wallet infrastructure. The initial report, published Oct. 29, describes how those footholds eventually exposed deployment credentials and an internal signing service. Replacing a device and resetting credentials can address the access paths an organization has identified; this account suggests the attackers’ presence extended beyond the first engineer’s machine.

The four-month span also complicates the usual picture of a theft as a sudden technical event. Here, the transfer day appears to have been the final stage of a chain involving people, software and internal access. Binance’s description is its own account of the incident, so the public explanation depends on what the exchange has disclosed.

The access chain

In June, a wallet DevOps engineer looking for an AI coding tool downloaded a modified Homebrew installation, Binance said. The exchange responded by issuing a new machine and resetting the engineer’s credentials. Even so, it says the engineer and other members of the wallet infrastructure team had already been exposed. The episode shows how a seemingly ordinary development task can become an entry point when software used by engineers has been tampered with.

A second approach came in September through a job-hunting platform. An attacker posing as a project director arranged a live video interview with someone presented as an HR representative, followed by a chat-app interview with a supposed executive at a fictitious company. The candidate was then asked to download an “assignment” to his work computer. Binance says the repository contained zero-day malware that its endpoint tools did not detect at the time.

The staged interviews matter because they made the file request part of a plausible hiring process. That doesn’t establish how the candidate assessed the opportunity, but it does show that the attack relied on social engineering alongside malicious code. Security tools can inspect devices and files; they can’t, by themselves, determine whether a convincing professional interaction is genuine.

On Oct. 20, the attacker used the second engineer’s computer and an internal AI tool to reach the first engineer and a third colleague, according to Binance. The intruder found a container deployment token on the first engineer’s device. Nine days later, stolen credentials were used to access the third engineer’s computer, deploy a container and run a malicious script.

That progression suggests the attackers used access across the team to move toward systems with greater operational reach. A deployment token can be consequential because it may allow changes to be made in an environment where software runs; Binance’s account says the token was found and later used as part of the chain. Here’s the thing: the issue described isn’t confined to one compromised endpoint. The relationships among devices, credentials and internal services helped determine what the attackers could reach.

Wallet transfers and recovery delay

Binance says five hot wallets sent 233.46 million XRP to an attacker-controlled address between 20:05 and 20:09 UTC on Oct. 29. Hot wallets on Solana and Optimism lost roughly 970,500 SOL and 44.2 million OP; another hot wallet transferred 18,270 BTC. The reported activity across multiple assets and wallets makes clear that the incident affected more than one transaction path.

The attacker also used the internal signing service to take advantage of EIP-7702, which lets a wallet delegate some transaction authority to a contract. Binance says the attacker gave a controlled contract partial rights over a hot wallet through 50 signing transactions. Because the wallet used multi-party computation, no single private key could revoke those delegations. The exchange had to develop a specialized procedure to clear them, extending the response.

This is more significant than it looks: limiting authority to part of a wallet’s activity can still create a difficult recovery problem when that authority has been delegated through a mechanism the organization must then unwind. The account doesn’t provide enough detail to assess the specific procedure, but it does connect the delay to the wallet’s setup and the need to remove the delegations safely.

The final unauthorized transfer, 2,961.9 ETH, was completed at 23:56 UTC. Binance says it removed the delegation at 00:10 UTC on Oct. 30. The short gap between those two reported times marks the end of the transfer sequence and the beginning of the exchange’s stated containment measure.

Remediation and asset figures

The exchange says it rebuilt the affected wallet system and internal AI tool, replaced devices and retired credentials linked to the engineers involved. It plans an independent third-party review and a security research fund, while keeping some technical details confidential. Those steps address several parts of the account: the software and devices involved, the credentials used, and outside scrutiny of the incident.

Rebuilding systems can remove known footholds, while replacing credentials can cut off access tied to those credentials. Neither statement, on its own, explains what the third-party review will examine or what findings will be made public. If you’re working in this space, the account is a reminder to look closely at the handoffs between developer machines, deployment systems and transaction signing. The connection between those layers is where this incident became consequential.

Binance reported that 98% of impacted token assets had been replenished as of Oct. 31. Its recovery updates stated 90% on Oct. 31 and about 95% on Nov. 2; the earlier Oct. 31 update gave the 90% figure. Those reports leave a discrepancy in the exchange’s published recovery numbers. The difference isn’t resolved by the information in the updates cited here, so readers can’t tell from those figures alone how the totals were calculated or revised.

What the incident leaves open

Binance’s account offers a detailed sequence, but some questions remain. It says endpoint tools didn’t detect the malware at the time and that the attackers reached colleagues after the first device was replaced. The disclosed timeline therefore points to a challenge familiar to organizations with interconnected development and operations systems: containment depends on finding every route an intruder may have used, not just responding to the first known device.

And yet. The exchange says it rebuilt systems, retired credentials and plans an independent review, while some technical details remain confidential. That leaves outside readers with a useful outline of how the attack progressed, but limited ability to judge the review’s scope or the specific changes made to prevent a similar chain.

The figures and mechanics deserve scrutiny, especially the difference between the reported replenishment totals and the role of delegated transaction authority. (And this is the part most people overlook.) A security incident can be contained at the wallet level while questions about the earlier access path and the public accounting of recovery remain unanswered. For now, the exchange’s own timeline is the clearest available basis for understanding what happened.

Still, the account makes one point plain: a wallet’s security depends on more than the controls around its keys. The tools engineers install, the credentials they handle and the services connected to their work can all shape the route to a transaction. The weak link may sit several steps away from the wallet itself.

Related Listen: Why a Nation State Will Always Beat the Security of a DeFi Team