The investigation is ongoing, this briefing comes from Binance’s initial report. Binance has held back some technical details deliberately.
Our recommendations come at the end, in their own section.
Binance has published a post-mortem
This entered through a developer who ran code from a fake job interview on a work laptop. Endpoint security didn’t catch it. That was one step in a months-long campaign across multiple engineers. No single person caused this.
Based on what has been shared, the attack succeeded because infrastructure could be reached through a chain of compromised engineering identities, and existing controls couldn’t revoke access quickly enough once it was established.
The attack ran across five months:
- June: An engineer downloaded a tampered Homebrew package while installing an AI coding tool. Binance detected it and rotated credentials, but the attacker had already identified who was working on wallet infrastructure.
- September: A second engineer was targeted through a fake job interview. Near the end, they were asked to download a malicious code repository. This contained malware, not detected by endpoint security.
- 20 October: The attacker used the compromised engineer’s machine and an internal AI tool to pivot to the wallet infrastructure team, the bridge between the social engineering campaign and the signing service. An engineer on that team had a container deployment permission token on their machine.
- 29 October: Using that token, they deployed a container and launched the attack.
Once inside the signing service, the attacker exploited EIP-7702 to delegate execution rights over a hot wallet to an attacker-controlled smart contract. About USD 6.34 billion in digital assets were impacted. About USD 2.85 billion has been frozen or intercepted.
Binance says it will absorb the loss, not its users.
The FBI, as Binance cites it, attributes responsibility to North Korea.
What we recommend
These recommendations are ours. They draw on what Binance reported.
- Keep unfamiliar code off corporate devices. Interview exercises, personal projects, and their dependencies can execute more than they appear to. Make the boundary explicit. Give people a straightforward, blame-free way to ask for help.
For coding challenges, use sandboxed or online environments with no route to corporate systems. Name who owns that rule this week. - Assume a developer laptop is already owned, and test what it can reach. Source code, cloud credentials, active sessions, internal AI tools and deploy tokens are the routes that mattered here. Engineer A’s container deployment token was the whole attack. Standing secrets on a laptop are findings in their own right. Test whether a stolen token still works from a different machine.
An approved testing environment should have no corporate credentials, production access or shared host folders. A separate browser profile is not isolation. - Exercise the full kill chain, not the EDR alert. Start from a compromised developer endpoint. Hunt standing secrets, move laterally, escalate, and stop only when you can touch the impact: signing, deploy rights, data, payments or whatever your crown jewels are. Then measure how fast you can revoke.
Binance alerted on large transfers but could not stop on-chain delegations for hours. If that revocation runbook has never been rehearsed under pressure, that is a finding. - Treat a suspicious interview download as device and credential compromise from the start. Contain fast. Security leads. Don’t wait for malware confirmation. After a detected compromise, re-test the same team and the people around them. Rotation and device replacement are not the same as closing the path.
Where this stands
Binance’s report is an initial picture. The investigation continues, and its findings are subject to independent review.
Source for attack facts: Binance’s initial incident report, posted on X: x.com/binance/status
