The Binance Heist: How $6.43 Billion Disappeared Through a Fake Job Interview

Image courtesy of The Hacker News.

On November 3, Binance finally told everyone how it lost $6.43 billion. That's the biggest theft ever from a crypto exchange — several times bigger than the old record ($1.5 billion from Bybit, back in February 2025). I've gone through Binance's own writeup, DKCISSP's earlier coverage of the breach, and the FBI's statement blaming North Korea's TraderTraitor group. Here's why I think this one is worth sitting with, not just skimming past.

There's no CVE here. No patch Binance forgot to install. The attackers didn't break through Binance's defenses — they walked around them, through two people.

The attack, start to finish

It started small, back in June. A Binance engineer tried to install a popular AI coding tool using Homebrew — the everyday tool nearly every Mac-using developer trusts without thinking twice. That install had been tampered with. Binance caught it and swapped out the machine. They probably thought the problem was solved.

It wasn't. Before that laptop was cleaned up, the attacker had already grabbed information about who this engineer was and who they worked with on the wallet team. In Binance's own words, "Engineer A's role and his related colleagues" were exposed. That's the part that sticks with me: the attacker didn't need to stay on that machine. They just needed one look at the org chart.

Three months went by. Then, in September, a second engineer — Binance calls them "Engineer B" — got a message on a real job-hunting site. Someone claiming to be a Project Director wanted to talk. Not a phishing email, not a weird link — a normal-looking recruiting conversation, the kind almost no security training warns you about. After a second interview, the "recruiter" asked the engineer to download a take-home coding test. It was malware, built to slip past detection, and it worked. Binance says its own security tools missed it.

From there, in October, the attacker rode that compromised laptop — plus a compromised AI tool running inside Binance — to reach two more engineers' machines. One of them had access to systems involved in wallet signing. Binance's best guess is that the attacker ended up able to make the wallet system approve transactions of its own choosing, across multiple blockchains. By November 1, word of the theft was starting to spread publicly.

A blockchain analytics firm called Elliptic put the final number at $6.43 billion. Even they've said to be a little careful pinning this on North Korea — the way the stolen money moved doesn't quite match that group's usual playbook. The FBI made the call anyway.

Binance says there's no sign any private key was actually leaked. This wasn't a stolen password — it was a forged authorization, like a fake signature that the system accepted as real. Binance has frozen close to $3 billion on-chain with help from Tether, Circle and others, rebuilt every system the attacker touched, and promised to cover every customer's loss itself.

Attack chain: technical breakdown

This wasn't a one-off week for crypto

Two other incidents hit in that same stretch of days. I don't think that's a coincidence — I think it shows where attackers are currently finding the easy openings.

Image courtesy of The Hacker News.

BTCPay Server had a critical flaw that let attackers steal .macaroon files — basically password files that Lightning Network nodes use to log themselves in. Anyone running version 2.4.1 or older had Bitcoin and Litecoin drained straight out of their wallets. The fix is in 2.4.2, and BTCPay says nobody on the current version has reported a theft. If you run this yourself, go check your version today. Don't wait for next sprint.

Image courtesy of The Hacker News.

And Polymarket had to pause trading after about $2.65 million disappeared from trader accounts through a hijacked script that belonged to DebugBear, a third-party vendor they used. Same pattern as the others: it wasn't Polymarket's own code that failed. It was something they trusted that sat right next to it.

Three incidents, three different technical causes — a tampered installer, an old unpatched server, a hacked vendor script. But the same story underneath all of them: the way in came from outside each company's own code.

Why this scares me more than the number does

$6.43 billion alone would be enough to make this the story of the year. But that's not actually the part that worries me most.

It's that an internal AI tool got used to break in further. Companies are plugging AI assistants into more and more of their internal systems — code, deployment pipelines, infrastructure — often giving them wide access because it's convenient. This breach shows exactly what happens when one of those tools gets compromised: it stops being a helpful shortcut and becomes a skeleton key. I'd start treating any AI tool with real system access the same way you'd treat an admin account — tightly scoped, watched closely, with a plan for what to do if it's ever compromised — because attackers are clearly already thinking this way.

And the social engineering beat every technical defense Binance had, because it wasn't aimed at technology at all — it was aimed at a person. Most security training says "don't click suspicious links." Almost none of it says "be careful during a real job interview." That's a real gap now, proven against a company with some of the best security money can buy. If it worked on Binance, it'll work on a smaller team that's thought about this even less.

What actually caused this

Strip away the details and it comes down to five things — all of them fixable:

1. Nobody checked if the software was real. The tampered Homebrew install just worked. No checksum, no signature, nothing caught it.
2. Engineer laptops were too close to the money. A normal developer machine ended up just a few steps away from systems that could move funds.
3. Nobody trained for a fake job interview. Security training covers email phishing. It almost never covers "a recruiter spends weeks talking to you, then asks you to run some code."
4. The AI tool had too much access. Whatever got compromised had enough reach to jump to other machines — which means it was never properly locked down to begin with.
5. Nobody noticed for five months. June to November is a long time for monitoring to catch nothing at all.

What I'd actually do about it

To stop the Homebrew-style trick

• Check package versions and signatures before trusting them. Use an internal mirror your team controls instead of letting everyone pull straight from the internet, at least for anyone touching sensitive systems.
• Put real endpoint monitoring on every developer's machine, and watch specifically for weird installer behavior.
• On the highest-value machines (wallet and infrastructure teams), only let approved software run at all — don't just rely on catching the bad stuff after the fact.

To stop a fake recruiter from getting this far

• Teach your team that this is a real attack, not just a hypothetical. Unsolicited recruiter messages, "homework" that asks you to run code, a hiring process that drags out over weeks — all of it deserves suspicion.
• Any code from an outside interview process should run in a throwaway sandbox, never on a real work laptop.
• Have HR double-check who's actually reaching out to people on sensitive teams.

To stop one compromised laptop from reaching everything

• Keep ordinary engineering machines and the systems that actually move money far apart, with real barriers in between — not just a password.
• Don't give engineers standing access to wallet systems at all. Make them ask for it, and only for as long as they need it.

To stop an AI tool from becoming the weak point

• Give every internal AI tool only the access it actually needs for its job, nothing more.
• Treat a compromised AI tool as seriously as a compromised admin account, and watch what it's doing.

To catch it faster next time

• Put real effort into spotting unusual behavior, not just known malware signatures — the malware here was built specifically to dodge those.
• Run a practice drill for a slow-moving, months-long attack, not just a sudden break-in.
• And if you run BTCPay Server: check your version today. Anything older than 2.4.2 needs updating now, not next sprint.

What I want you to take away from this

• People and process were the weak point here, not code. Your developers, your hiring process and your internal tools are all part of your attack surface now, not just your servers.
• One compromised laptop should never be a short hop from real money. Keeping engineering and financial systems apart is the single best thing you can do.
• Treat your AI tools like you'd treat a privileged account — because attackers already do.
• Security training hasn't caught up. A fake job interview is now a proven way in, and most programs don't even mention it.
• This wasn't a one-off. Binance, BTCPay Server and Polymarket were all hit in the same week, all through something they trusted rather than their own mistakes. If you run anything like this, assume you're already a target.