Binance's $6.34bn hack started with a job interview

Binance put out its first report on the 29 October hack this afternoon. I expected the usual: a big number, a "sophisticated actor", an apology, nothing you can actually use.

The number is big. About $6.34 billion in assets were hit, roughly four times the Bybit hack in February 2025, which everyone called the biggest ever at the time. But the report is more specific than these normally are. It started with a fake job interview, and one of the steps was a swapped-out pyenv sitting in a Homebrew folder.

I'm job hunting right now and I have Homebrew on this Mac, so I read it twice.

Everything below comes from Binance's post unless I say otherwise. The investigation is still going and they've held some details back on purpose, so think of it as a first draft.

The short version

Users don't lose anything. Binance is covering the loss itself, and by 31 October it had put back 98% of the affected tokens, which you can check on its Proof of Reserves page. About $2.85 billion of the stolen assets has been frozen or intercepted so far. The FBI says North Korea did it.

So nobody's balance is going down. The interesting part is how they got in, because none of it needed a bug in Binance's wallet code.

How they got in

This took months, not one evening.

• June. An engineer on the Wallet DevOps team (the report calls them Engineer A) searched for a popular AI coding tool, landed on a tampered Homebrew install, and ran it. Binance's security team spotted it, replaced the laptop and rotated the credentials. Fine so far, except the attacker now knew who A was and who A worked with.
• September. A different engineer, B, was approached on a real job-hunting site by someone posing as a project director at a company that doesn't exist. B's profile mentioned Binance. The first round was a live video call with "HR", who shared a social media account full of personal photos and videos to seem like a real person. The second round was with the "CEO" over a chat app. Near the end, B was asked to download a take-home assignment, a code repo, onto the work laptop. The repo ran malicious code during setup.
• On B's laptop. The malware replaced Homebrew's pyenv with its own version, cleaned up after itself, and talked to the attacker's server. Binance calls it 0-day malware, and the endpoint security didn't flag it.
• 20 October. From B's laptop, the attacker used an internal AI tool to get control over A and a third wallet engineer, C. On A's machine they found a token that could deploy containers.
• 29 October, 17:15 to 19:56 UTC. The attacker was on C's computer, used A's credentials to deploy a container, and ran a script against the internal wallet signing service.

From there, the signing service was signing whatever the attacker asked it to.

Four hours of transfers

Between 20:05 and 20:09 UTC, five hot wallets sent 233.46 million XRP to the attacker. Then about 970,500 SOL and 44.2 million OP left from wallets on Solana and Optimism. Only after that, going by the order in the report, did an internal alert fire about large transfers. Then 18,270 BTC went too.

I'd love to know what that alert was watching for. Four minutes of XRP and two more chains before the first alarm is a long time for a system that's watching its own hot wallets. The report doesn't say, and I'd guess it's one of the details they're keeping quiet.

Binance suspended withdrawals and started asking partners to freeze tokens. The last stolen transfer, 2,961.9 ETH, landed at 23:56 UTC. That's almost four hours after the first one, with withdrawals switched off for most of that time. The reason is EIP-7702.

Why turning withdrawals off didn't stop it

EIP-7702 went live on Ethereum with the Pectra upgrade in May 2025. It lets a normal wallet, the kind controlled by a private key rather than a contract, sign an authorisation that says "when someone calls me, run this contract's code". It's meant for nice things, like batching transactions or letting someone else pay your gas, without moving your funds to a new smart-contract wallet.

The catch is that the authorisation lives on the chain. Once it's in, it stays there until the same wallet signs a new one to replace it. No server is in that loop, yours included.

So the attacker, still driving the signing service, had a Binance hot wallet sign 50 transactions to move the account nonce where it needed to be (an authorisation is only valid for one specific nonce), and then a delegation to their own contract. From then on that contract had partial control over the wallet. Binance turning off its withdrawal system made no difference, because the withdrawal system wasn't on that path any more.

To undo it, Binance had to sign a fresh authorisation pointing at the zero address, which clears the delegation. That sounds like one transaction. But the hot wallet used MPC, multi-party computation, where the key is split between several parties and never exists in one place. Normally that's exactly what you want. Here it meant nobody had a single key to quickly sign the revoke with, and the team had to work out a procedure on the night. The revoke went through at 00:10 UTC on 30 October.

For me this is the most useful bit of the whole report. Every incident runbook I've seen treats "stop the service" as the off switch. With something like EIP-7702, the dangerous permission is sitting on a public ledger, and the only thing that can take it back is the same signer the attacker was abusing. Shut the signer down and you stop new damage, but you've also stopped your own fix.

The part that's about all of us

Take the crypto out and this is a story about developer laptops.

Two of the steps are things normal developers do every week: install a tool from something you found on a search engine, and run a stranger's repo because they asked nicely. Binance says it caught 57 North Korea-linked attempts this year, using fake interviews, fake copies of developer tools, poisoned packages and browser extensions, and fake video-call apps. None of that is new. Security researchers have been writing about fake take-home tests aimed at developers, under names like "Contagious Interview", since 2023. What's different here is how convincing the fake recruiter was and how far it got.

The pyenv detail is worth slowing down for. The script didn't drop some odd-looking binary. It created a file next to pyenv in /opt/homebrew/Cellar, deleted the real one, renamed its own file into place, and redid the link in /opt/homebrew/bin. The real file was 3,344 bytes and the fake one 3,414, so it was probably the original with a few lines added. pyenv is a shell script that a lot of people run every time they open a terminal, it lives in a folder nobody looks in, and it's not the kind of file anyone thinks to scan.

Then there's the AI tool. The report says the attacker "used an internal AI tool" from B's laptop to gain control over A and C. It doesn't say how, and I don't want to guess. But an internal assistant that can reach other people's machines, or act for them, is a new kind of path through a company, and I'd bet it shows up in a lot more of these reports. Binance says it has rebuilt the tool and its access controls.

What I'm changing

None of this is clever. It's mostly things I already knew and wasn't doing.

• Take-home tests go somewhere disposable. A dev container or a cheap cloud VM, not my laptop with my SSH keys and tokens on it. And I read the package.json scripts and any setup files before I run an install. If a recruiter is in a rush for me to run something, that tells me what I need to know.
• Tools come from the official install page. For Homebrew that's brew.sh, typed in, not the first search result. Search ads for popular dev tools are a known trap, and that's exactly how Engineer A got caught in June.
• No long-lived deploy tokens on a laptop. A's container token is what turned "someone is on a laptop" into "someone is in the wallets". A short-lived credential from SSO would have been worth a lot less to steal.
• If a tool starts acting oddly, reinstall it. brew reinstall pyenv costs ten seconds. Trusting a file that might have been swapped costs more.

If you're on the other side of this and you build signing services, the questions are the ones Binance says it's now asking itself. What does your signing policy actually let through? Does it understand delegation-type transactions as well as plain transfers? And if the signer is the thing that's been compromised, how do you sign the undo?

Binance says it will share more once the independent review is done. If something here turns out to be wrong, I'll update the post.

First published on my blog. Cover photo: Cory Doctorow, CC BY-SA 4.0, via Wikimedia Commons (source).