One fake job interview, $6.34 billion out the door: a case study of the Binance breach

A software engineer gets a message on a job platform. There is a video interview with HR, then a second round with the CEO. Then a coding assignment.

The company did not exist. Weeks later, about $6.34 billion in digital assets had left Binance's wallets.

CNBC and TechCrunch describe it as the largest crypto theft on record. On November 3, Binance published its initial findings. They read less like a single mistake and more like a months-long campaign.

How it unfolded

June: the first contact. While looking for an AI coding tool, a wallet DevOps engineer downloaded a tampered Homebrew installation. Binance detected it, replaced the device and rotated related credentials. But the engineer's role and wallet-team colleagues had been exposed.

September: the bait. Another engineer was approached on a job-hunting platform by someone posing as a project director. A first-round HR video interview was followed by a second round with someone claiming to be the CEO of a fictitious company. During that round, the engineer was told to download an assignment. It contained a malicious code repository that executed during setup. Binance called the approach "more advanced and deceptive" than earlier social engineering it had seen.

October 20: the pivot. The attacker used that compromised computer and an internal AI tool as a springboard to take control of two other engineers' accounts. On the first engineer's machine was a token with permission to deploy containers. Binance has not said how the AI tool was used.

October 29: the drain. Between 17:15 and 19:56 UTC, the attacker logged into the third engineer's computer, deployed a container with stolen credentials and triggered a malicious script. That opened a path to the internal wallet signing service.

At 20:05 UTC, five hot wallets began sending 233.46 million XRP to an attacker-controlled address, finishing by 20:09. SOL, OP, BTC and ETH transfers followed. The last unauthorized transfer finalized at 23:56 UTC.

October 30: the cleanup. At 00:10 UTC, Binance cleared a malicious on-chain delegation from one of its hot wallets.

The FBI attributes the attack to North Korea, according to Binance. Binance says it found no evidence that wallet private keys leaked.

The detail that matters most

The attacker did not need to steal a private key. Binance says the attacker used the signing service to submit 50 signing transactions, exploiting Ethereum's EIP-7702 mechanism to give an attacker-controlled contract partial execution rights over a hot wallet.

Then comes the part every operations team should read twice. Suspending withdrawals did not invalidate those on-chain authorizations. And because the wallet used multi-party computation, no single private key could revoke them immediately. Binance needed a specialized procedure.

In a traditional system, a pause usually stops the system. On a blockchain, a permission you have already signed stays valid until you revoke it on-chain.

What the freezes show

Binance now puts frozen or intercepted assets at about $2.85 billion, roughly 45% of the total, subject to reconciliation and price moves. Early reports from CNBC had Tether freezing more than $1.5 billion of USDT and Circle more than $800 million of USDC.

This is the tokenization lesson in plain view. When a token has an issuer with freeze powers, someone can step in after a theft. That control helped here. It also means holders are relying on that issuer's decisions, which is worth understanding before you hold or build on such a token.

Binance says 98% of impacted token assets had been replenished as of October 31, that it set aside over 100% of the funds needed, and that users will not bear the loss. StepSecurity makes the key distinction: replenishing is not the same as recovering stolen funds. A smaller firm might not have a balance sheet that can absorb a loss like this.

What firms should take from it

Our reading: this was not only a crypto failure. It is a chain any firm with developers, wallets or automated systems should test against.

1. Treat hiring channels as an attack surface. Unfamiliar code, including a take-home test, should never run on a work machine.
2. Assume exposure survives cleanup. Replacing a laptop removes malware. It does not remove what an attacker learned about your people.
3. Audit internal AI tools like privileged users. Ask what each tool can reach, and who could act through it.
4. Keep deployment rights away from developer machines. A token sitting on a laptop should not lead toward a signing service.
5. Test your kill switch against on-chain state. Know which permissions stay live when you press stop, and how long revoking them really takes.
6. Know what you could freeze. Map holdings by whether an issuer can intervene, and how fast.

Binance detected the June incident and, it says, blocked 57 suspected North Korea-linked cases this year. The attacker needed the defenses to fail only often enough.

If you ran this scenario on your own firm, where would the chain break first?

References

• Binance: 29 October security incident, initial findings and response, November 3, 2026
• Binance: Security incident recovery update #6, November 3, 2026
• CNBC: Circle and Tether freeze funds tied to Binance incident, updated October 30, 2026
• TechCrunch: North Korean hackers blamed for record $6.3B Binance breach, October 30, 2026
• StepSecurity: Binance's $6.34 billion hack

Binance calls its report initial, and figures may change. Timeline details are Binance's own account. FinRAG.tech has no connection to these firms. The interpretation is ours. This article is commentary, not investment or security advice.