I have read a lot of exchange postmortems, and they rarely pay off in the headline number. They pay off in the sentence where the writeup admits which assumption stopped holding. For Binance that sentence is buried in the attack preparation section, and it is not about a job interview.
Binance published its initial findings on November 3, 2026, for the theft that started on October 29. The report puts approximately USD 6.34 billion in impacted digital assets, with about USD 2.85 billion frozen or intercepted. The FBI attributed the incident to TraderTraitor, a North Korea-linked unit, on October 31. Pyongyang denies it.
The story got told everywhere as “North Korean hackers used a fake job interview,” which is accurate as far as it goes. It is not where the security failure lives. The interview bought one laptop. An internal AI tool carried them from that laptop to two engineers on the wallet team, and that second hop is the part every company running an internal assistant should read twice.
🧾 The Timeline, as Binance Told It
The report gives four dated stages.
June 2026. Engineer A, on the wallet DevOps side, searched for a popular AI coding tool, clicked a search result, and installed a tampered Homebrew build of it. Binance’s security team caught the anomaly, replaced the device, and rotated credentials. The exposure survived the cleanup anyway: the report states plainly that Engineer A’s role “and his related colleagues on our wallet infrastructure team” was now known to the attacker.
September 2026. Software Engineer B, whose profile referenced his Binance experience, was approached on a job-hunting platform by someone posing as a Project Director. First round was a live video call with a purported HR representative, who shared a social media account full of personal photos to build rapport. Binance calls this “more advanced and deceptive than previously seen social engineering approaches.” Second round was on a social chat app with a person claiming to be the CEO of a fictitious company, and near the end Engineer B was told to download an “assignment” containing a code repository. It ran during setup on his work computer.
October 20. The attacker used Engineer B’s machine and the internal AI tool to take control of Engineer A’s computer and that of Engineer C, another wallet software engineer. Engineer A had a container deployment permission token sitting on his machine.
October 29, 17:15 to 19:56 UTC. The attacker logged into Engineer C’s computer, used Engineer A’s stolen credentials, deployed a container, and triggered the script that started the drain.
🍺 The First Hop Was a Search Ad
The June infection is the least exotic part of the story, and the one I keep thinking about, because the malware did nothing clever at the application layer. It swapped a binary. Binance published the script’s operations, and they read like a diff:
CREATE /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY pyenv_ → 3,414 B
DELETE .../libexec/pyenv (3,344 B) ← remove the valid pyenv
RENAME pyenv_ → pyenv (3,414 B) ← replace it with a malicious version
DELETE /opt/homebrew/bin/pyenv (3,414 B)
ln (create a new symlink) + spawn zshSeventy bytes between the real pyenv and the malicious one, inside a Homebrew Cellar path, in a file almost nobody reads. The symlink in /opt/homebrew/bin was recreated so the new binary resolved, then it spawned a shell.
The delivery detail matters more than the payload. Reuters, citing a person familiar with the incident, reported that the malicious version had been placed in an advertisement so it ranked above the real download in a search engine. Not a compromised upstream, not a typosquatted tap, not a poisoned formula. An ad, and an engineer installing a coding assistant through whatever sat at the top of the results. Binance says the code was 0-day and that endpoint security did not detect it at the time.
One gap worth naming: Fortune reported that executives described the platform as LinkedIn, while the report only says “a legitimate job-hunting platform.” A spokesperson told Fortune that non-public-facing employees are not allowed LinkedIn profiles, and would not say whether this engineer’s broke that rule.
🤖 The Interview Got a Laptop. The AI Tool Got the Team.
Here is everything the report says about October 20:
“The attacker leveraged the compromised computer of engineer B and used an internal AI tool to gain control over the Wallet DevOps Engineer A and another Wallet Software Engineer C.”
No tool name, no vendor, no access path. Nothing on whether the assistant held stored credentials, had shell reach into other developer machines, or had broad read access with a session that could be replayed.
Read the remediation list against that sentence. One action taken was: “Rebuilt the affected internal AI tool and access controls.” If the tool had been fine and only the credentials around it were bad, you would expect rotation listed alone. Rebuilding the tool and its access controls is the closest thing here to an admission that the access model was part of the path.
What I can offer as inference rather than fact: for an assistant on one engineer’s laptop to yield control of two other engineers’ machines, it needed standing credentials that crossed team boundaries, or the ability to act as those users, or an execution surface that reached their hosts. Any of the three turns one compromised laptop into a shared capability, and any of them is a design choice.
The corroboration sits outside Binance. My last post covered a Postman installer writing its own trust record into a coding agent’s config. Same mistake, larger scale: an agent that reaches other systems on behalf of whoever is at the keyboard cannot tell the engineer from someone holding the engineer’s session. It did not get them in. It widened the blast radius from one laptop to a wallet team.
⛓️ Suspending Withdrawals Did Not Stop It
The on-chain mechanics belong in front of any team running signing infrastructure, because Binance did the textbook thing and it was not enough.
Between 20:05 and 20:09 UTC on October 29, five Binance hot wallets sent 233.46 million XRP to an attacker-controlled address. Hot wallets on Solana and Optimism sent roughly 970,500 SOL and 44.2 million OP. Then 18,270 BTC went out.
Then the part that made containment hard. The attacker used the signing service to abuse Ethereum’s EIP-7702 authorization mechanism, which lets an account delegate execution rights to a smart contract without exposing the private key. They gave an attacker-controlled contract partial execution rights over a Binance hot wallet. Binance suspended withdrawals, coordinated freezes, and revoked permissions, which is how it reached USD 2.85 billion frozen.
Suspending withdrawals did not touch the delegation. The report says it directly: “the malicious EIP-7702 authorizations existed on-chain and operated independently of Binance’s normal withdrawal infrastructure.” The attacker used 50 signing transactions to manipulate the account nonce and establish the delegations, and once established they kept moving assets with the withdrawal system switched off.
Revocation took hours because the wallet used multi-party computation, so no single private key existed to revoke the delegation with. Binance had to build and run a specialized revocation procedure from scratch. The final unauthorized transfer, 2,961.9 ETH, finalized on-chain at 23:56 UTC, nearly four hours after the first theft. At 00:10 UTC on October 30, Binance executed an authorization from the Binance14 hot wallet to the zero address to clear the delegation code.
That is not a slow security team. That is a custody architecture whose revocation path had never been rehearsed. MPC removes the single key that made fast revocation possible, and EIP-7702 introduced a class of authorization the withdrawal kill switch was never designed to cover. If your playbook says “halt withdrawals” and stops there, you will find the hole at the worst moment.
🛠️ What I Would Change Monday
- Interview code never runs on a work machine. A separate device, reset after. The September entry was a repository executed during project setup, the most routine thing a developer does while job hunting.
- An internal assistant needs its own identity, not the user’s. Scoped tokens, per-target authorization, and a session that cannot be lifted onto another machine.
- Know what credential is on the laptop. Engineer A had a container deployment token in his home directory. If that token is the difference between a phished laptop and a drained signing service, it belongs behind its own authentication.
- Rehearse revocation, including the MPC path. An hour of tabletop on “delegation exists, keys are sharded, go” is cheap.
- Watch what the agent can see. Binance’s fix list is mostly tighter AI tool access controls and more AI behavioral anomaly detection, the right direction and a description of what was missing.
🧠 Final Thoughts
The expensive part is not the $6.34 billion and not the fake recruiter. It is that three trust decisions expired quietly: an ad-ranked download for a coding assistant, a deploy token contained only by sitting on a laptop, and an internal AI tool that could cross from one engineer’s session into two other machines. Each looked fine alone. Binance needed all three to fail before anyone could take a wallet.
Reports like this get read as stories about attackers. I read them as inventories of what we have stopped questioning. The AI tool was not jailbroken. It did what tools do, which is act with the authority it was given. The interview will get a training deck. The privilege graph is what gets someone else breached next quarter.
Thanks for reading.