Binance’s own account of the Binance heist reads less like a break-in and more like a siege conducted in slow motion. According to the exchange’s investigation report to date, the people behind the October 29 heist began no later than June, worked their way onto engineers’ laptops through a tampered software download and a fake job interview, and then used the exchange’s own internal tooling to reach the systems that move its money. Binance put it bluntly: “It was not a single isolated breach or a simple phishing incident.”
The sums in the report are stated with a precision that deserves care. The heist initially targeted $6.34 billion in cryptocurrency from Binance wallets, Binance said, and the exchange has since frozen or intercepted $2.85 billion of that sum. “Initially targeted” is not the same as finally lost, and the report is explicitly an investigation to date, not a final verdict. Binance said it set aside funds required to cover the loss. Those qualifications matter, because the mechanism is what makes the number so hard to pin down.
The long fuse: June to September
The campaign’s first foothold, as Binance describes it, came in June, when an engineer downloaded a tampered version of Homebrew, the popular software installer. Binance linked that incident to one reported in May, describing the link as likely rather than certain — a hedge worth preserving, because the whole reconstruction rests on connecting events months apart. The exchange’s security team detected the compromised laptop, but only after the malware operators had obtained information about the roles of that engineer and related colleagues on the wallet infrastructure team. In other words, the intruders did not merely land on a machine. They learned the org chart.
The second foothold came in September. A separate engineer, using a legitimate job-hunting platform, was contacted by an individual posing as a project director looking to hire. Fake first- and second-round interviews led the engineer to download an “assignment” that linked to a code repository containing malicious code, which executed on the engineer’s device during the setup process.
Binance said the malware employed sophisticated obfuscation and evasion techniques, including replacing a legitimate development tool component with a malicious version. The exchange described it as 0-day malware that endpoint security protection tools did not detect at the time. None of this required defeating Binance’s cryptography. It required patience, and a convincing job interview.
The pivot: October 20
On October 20, the campaign changed gear. Binance said the attackers used the compromised engineer’s computer and an internal AI tool to take control of two other engineer devices, including the one previously targeted with the trojanized Homebrew installer. One of those engineers’ access included a token granting access to a container deployment. The report does not explain in detail how the internal AI tool was used, and that gap is one of the story’s most important open questions: in this account the tool became a bridge between one compromised laptop and the wallet team itself.
Nine days later, on October 29, the threat actor logged in to the third engineer’s device, used the stolen credential, deployed a container, and activated a script to initiate the transfer. Binance said the attackers extended unauthorized access to an internal wallet signing service to complete transactions outside the normal withdrawal process. The timeline Binance gives for that day runs between 17:15 and 19:56 UTC. From there, the theft moved fast: Binance hot wallets on Solana and Optimism sent approximately 970,500 SOL and 44.2 million OP to attacker-controlled addresses, and a Binance hot wallet sent 18,270 BTC to an attacker-controlled address. Blockchain intelligence firm TRM, tracking the transfers on-chain, tallied approximately $6.36 billion moved across ten blockchains. The two totals carry different source labels, and the supplied evidence does not reconcile them.
The Binance heist getaway that ignored the off switch
What set this incident apart from a conventional hot-wallet drain was the mechanism the attackers used to keep moving funds after Binance responded. The attackers used the wallet signing service to exploit Ethereum’s EIP-7702 authorization mechanism, which allows an account to delegate certain execution rights to a smart contract. In this case, the attacker gave an attacker-controlled smart contract partial execution rights over a Binance hot wallet, submitting 50 signing transactions to manipulate the account nonce and establish the malicious delegation authorizations.
The consequence was structural. Binance suspended withdrawals to restrict further outflows and took steps to revoke unauthorized permissions. Those efforts froze or intercepted $2.85 billion. But suspending withdrawals and shutting down hot wallet services did not automatically invalidate the existing on-chain authorizations, because those authorizations existed on-chain and operated independently of Binance’s normal withdrawal infrastructure. Revocation was technically complex for a further reason: the hot wallet used Multi-Party Computation, so there was no single private key that could immediately revoke the malicious authorizations. Revocation required a specialized procedure, which took additional time.
This is the heart of the affair. The exchange’s off switch worked on the exchange’s own systems. It did not work on permissions that had already been written to a public ledger, where they continued to function whether Binance approved or not. TRM said the attackers laundered transferred assets through the TRON and Ethereum networks, including through a self-minted token and liquidity pool, a lending receipt token passed between wallets, and cross-chain swaps chained through two bridges.
What was stopped, and what is still open
There is a genuine counterargument to any telling of this story as pure failure, and Binance’s own report supplies it. Throughout 2026, the exchange’s security team detected and prevented 57 suspected North Korea-linked cyber threat cases. This campaign succeeded. Secondary coverage reports that about 98 percent of the affected assets had been replenished as of October 31. Both things can be true: the defenses caught dozens of attempts, and the one that mattered most still reached the signing service.
Attribution is where the account splits. The FBI and TRM attributed the heist to North Korean actors, with TRM tracking the group as TraderTraitor and attributing with high confidence. The FBI and TRM are the sources of that attribution, not Binance, and secondary coverage notes that North Korea has denied involvement. The distinction matters: what Binance has documented is the how, in its own interim reconstruction. The who comes from investigators outside the exchange, and an independent security review Binance said it would bring in may clarify outstanding questions.
Several questions remain open, and they are the ones the next chapter of this story will turn on. What is the final net loss, as distinct from the sum initially targeted and the sum frozen? Is the June incident definitively part of this campaign, or only likely linked? How exactly was the internal AI tool abused, and what was the specialized revocation procedure? And what changes will Binance make to signing-service access and delegation controls now that it knows its own machinery can be turned into the getaway route? Until those answers land, the honest summary is the one Binance itself offered at the start: a sophisticated, multi-stage campaign, still under investigation — one that succeeded not by breaking the vault door, but by borrowing the keys, the tools, and the permissions of the people who worked inside.
