Binance published its first account of the October 29 theft on November 3, and the path to the wallet signing service ran through a container deployment token sitting on an engineer's laptop. The attackers moved about $6.34 billion in a few hours. The FBI has attributed it to TraderTraitor, the North Korean unit also tracked as Lazarus. The company's own write-up is posted on X, and it is more candid than most breach reports I have read.
Four months of work ended at one token.
June to September: two laptops, two misses
In June a Wallet DevOps engineer, whom the report calls Engineer A, went looking for an AI coding tool through a search engine and downloaded a trojanized Homebrew installer. Binance's security team caught the anomaly. They replaced the laptop and rotated every credential tied to it. By the standard most of us use, that is a closed ticket.
It was not closed. The attackers had already read enough from the machine to learn what Engineer A did and who else worked on wallet infrastructure. Binance's report says information about his role and his colleagues on the wallet team "was exposed to the hacker." You can rotate a key. You cannot rotate an org chart.
I have spent 25 years around incidents like the June one, and the pattern is always the same. The endpoint gets cleaned, the ticket gets closed, and nobody asks what left the box before anyone noticed. Binance's endpoint tooling did not flag the installer at install time. That is the detail I would have wanted in the postmortem, and it is the detail the attackers built the next four months on.
Three months later a second engineer, Engineer B, got a message on a job platform from someone posing as a project director. Fortune reports the platform was LinkedIn. There was a first round with an HR person who shared a personal social media account full of photos and videos to look real. There was a second round, on a chat app, with the "CEO" of a company that does not exist.
At the end of the second interview the CEO asked Engineer B to download a technical assignment. It was a code repository. He opened it on his work laptop. The setup script swapped a component of a legitimate development tool for a poisoned copy, phoned home to an attacker server, and deleted its own forensic traces. Binance says its endpoint tools did not detect this one either.
The technique is old. Chainalysis's Tom McLouth told The Hacker News the firm has seen "dozens of other job interview compromises that have led to wallet compromises." North Korea has run this play against crypto engineers since at least 2022. The size of what sat downstream of one developer's laptop is what changed.
October 20: the internal AI tool
With Engineer B's machine under control, the attackers waited a month. On October 20 they used an internal Binance AI tool to reach two more people: Engineer A, the same person from June, now on a fresh laptop, and a wallet software engineer the report calls Engineer C. Binance has not said what the tool does or what permissions it held. The report's phrasing is that the attacker "abused" it to "gain control" of the other two machines.
Read that with an operator's eye. An internal AI assistant had enough reach that a session on one engineer's laptop became a foothold on two others. Whether that was a shared credential or an agent with remote execution rights, Binance has not said. The remediation list includes "rebuilt the internal AI tool and access controls," which tells me the tool itself was inside the blast radius.
On Engineer A's rebuilt machine, the attackers found a container deployment permission token. A long lived credential, on disk, that let its holder deploy containers into the wallet environment. Four months after the first compromise, after a device swap and a credential rotation, the person who ran wallet DevOps still had a deploy token on a laptop. I say it because I have seen the same thing on most teams I have worked near, and so have you.
October 29: the container and the signing service
Binance's timeline puts the final move between 17:15 and 19:56 on October 29. The attacker logged onto Engineer C's computer using the credentials lifted from Engineer A, deployed a container, and ran a script. That container gave them access to the internal wallet signing service. From there they started transactions outside the normal withdrawal flow. The last unauthorized transfer, 2,961.9 ETH, settled at 23:56 UTC. Binance cleared the malicious authorization at 00:10 UTC on October 30.
Per Security Affairs' breakdown of the report, five hot wallets sent 233.46 million XRP to one attacker address. Other transfers moved roughly 970,500 SOL, 44.2 million OP, and 18,270 BTC. Elliptic counted about 12,000 wallets across 11 blockchains and more than 40,000 transactions in the first four days, according to CNBC.
The Ethereum side used EIP-7702, the change from the 2025 Pectra upgrade that lets an ordinary account delegate execution to a contract. The attackers used it to give a contract they controlled partial execution rights over a Binance hot wallet without ever holding the private key. Binance paused withdrawals and the drain continued, because the authorization was already on chain and the pause only governs Binance's own withdrawal path. The wallets use multi party computation, so no single key could revoke the delegation. Binance had to write a revocation procedure while the money left.
Four controls that would have broken the chain
Binance's remediation list is the standard one, and it is correct. Wallet system rebuilt in a new environment. AI tool and its access controls rebuilt. Devices replaced, tokens revoked, scans run across every employee machine, device controls tightened. Independent firms are reviewing. The company says it has replenished 98% of affected assets from its own reserves, and about $2.85 billion has been frozen or seized with help from Tether, Circle and others. No customer lost funds.
None of that stopped the attack, because nothing did. These four would have, listed from cheapest to most expensive.
- Short lived deploy credentials. A container deployment token that expires in an hour and is minted per job is useless to an attacker who finds it on a laptop in October. Workload identity or a plain vault lease would have done it.
- Code assignments run in a throwaway VM, never on a work machine. This is policy, and it costs nothing. Engineer B ran a stranger's repo on the laptop that touched wallet code.
- An internal AI tool scoped like any other service account. Whatever that tool could reach, it could reach from any compromised session. Give it the permissions of the user who invoked it, nothing inherited, nothing shared.
- A signing service that wants more than a container in the right network. A deployed container reaching the signer with no second approval over a threshold and no rate limit is the finding that cost the money.
The June incident is the part I would push on if I were reviewing this. Binance did the right things and called it closed. The attackers used the next four months to turn what they had learned into a recruitment campaign aimed at the one team that mattered. A compromise of a wallet DevOps machine should have triggered a review of what that role could reach, including a hunt for every long lived token the role had ever been issued. It didn't, or it missed one.
Binance's own line on this was "This should not have happened." Agreed. It will happen again at a smaller exchange within a year, through the same kind of interview, ending at the same kind of deploy token on the same kind of laptop.
