One laptop, $6.3 billion: what the Binance hack teaches anyone who ships code

This is the fourth in a series where I build a realistic app, break it, and fix it, all in my own lab with nothing pointed at anyone else's systems. Day one was a file upload, day two was one number in the address bar, and day three was keys in a JavaScript bundle. Today's topic came from the news: the largest crypto theft on record, and how ordinary its beginning sounds.

On October 29, 2026, Binance lost about $6.34 billion in digital assets, by its own estimate. TRM Labs puts it at about $6.36 billion across ten blockchains, most of it within about 20 minutes, and calls it the largest hack in history.

What Binance has said so far

Everything in this section comes from Binance's initial findings, published November 3. The report says the investigation is ongoing, so treat this as a first account and not the final word.

• June 2026. A wallet DevOps engineer searched for a popular AI coding tool and downloaded a tampered Homebrew installation. Binance's security team detected it, replaced the device and rotated the credentials.
• September 2026. A fake recruiter on a legitimate job platform, followed by fake interviews, led a second engineer to download an "assignment" onto a work computer. Binance says the 0-day malware "was not detected by the endpoint security protection tools at the time."
• October 20. Using that computer and an internal AI tool, the attacker gained control over the first engineer and a third one. The attacker found a container deployment token on the first engineer's computer.
• October 29, 17:15 to 19:56 UTC. From the third engineer's computer, with stolen credentials, the attacker deployed a container and triggered a malicious script.
• From 20:05 UTC. Unauthorized access to an internal wallet signing service started transactions "outside the normal withdrawal process". The final unauthorized transfer settled at 23:56 UTC.
• Throughout. The attacker "took steps to conceal the malicious activity and remove traces of the compromise."

Binance says about $2.85 billion has been frozen or intercepted, that it has replenished 98% of the impacted assets, and that it will absorb the loss. It cites the FBI, which says North Korea is responsible. There is still no public detail on how the AI tool was used or on how the signing policies were set up.

The part that matters: no key needed

In its first update, Binance said it had found "no evidence of any wallet private key leak." TRM Labs' assessment is that the attacker most likely gained the ability to make the signing system sign transactions of its choosing.

That's the lesson I wanted to show on screen. We protect private keys very carefully, then we build a service that will use the key for whoever asks nicely. If you can reach the thing that signs, you may not need the key at all.

The same shape, in my own lab

My lab is not a copy of Binance's systems, because nobody outside knows them. It's a small fictional exchange called Ledgerline, with fake money, running on my own Kali box. It has the same five links:

engineer laptop → deploy platform → service container → signing service → hot wallet

The assignment. A readme and a setup script, completely normal looking. Between the friendly messages is one line:

cp "$HOME/.config/deployctl/token" /tmp/lab_collected 2>/dev/null

Real malware does far more than this, and the real one was a zero-day. I don't need any of that to make the point. Anything you run, runs as you, and can read everything you can read. A deploy token in a dotfile that never expires is exactly the kind of thing it finds.

The sweep. That token deploys a container with no questions asked, and the container gets a service identity. The signer's whole policy looks like this:

// vulnerable: "are you a service container?" is the only question
if (bearer() !== $serviceIdentity) reply(401, ['error' => 'not a service identity']);
$signature = sign($to, $amount, $key);   // the key never leaves this process

Twenty requests later, a million fake dollars have gone to an address nobody has ever paid, in about ten seconds. The private key never left the signer. Nothing leaked, and the wallet is empty anyway.

The logs. The audit log recorded all of it, but it lived on the same system, and the same identity could rewrite it. One request and it was empty. If your logs live where the attacker lives, you investigate with nothing.

What would have caught it

No single clever alert, just a few boring ones:

• a personal token deploying outside the pipeline
• a brand-new destination address on a hot wallet
• dozens of signing requests in a minute
• on Ethereum, any EIP-7702 delegation on a treasury wallet, which TRM says should trigger an immediate alert, because that wallet should have no code on it at all

The four fixes

I patched the lab and ran the same attack again. The assignment, run in a throwaway environment with an empty home folder, had nothing to take. The old token got a 401. Then I assumed the worst, that the attacker was already inside a real container with its real identity. The signer denied every request, and after three denials it froze itself. The balance never moved. The log wipe got a 403, and each entry had already left the box, chained to the one before it.

// fixed: the signer assumes its caller is already compromised
if ($state['frozen'])                  return deny(423, 'signer frozen, on-call paged');
if (!in_array($to, ALLOWLIST, true))   $deny = 'destination not on allowlist';
elseif ($amount > TX_CAP)              $deny = 'over cap: needs a second approval';

if ($deny && ++$state['denied'] >= BREAK_AFTER) {
  $state['frozen'] = true;             // stop trusting this caller
}

1. Run untrusted code in a throwaway environment, with no production credentials, no single sign-on session, and no access to your home folder. That means job assignments, and anything you found by searching for an installer. Check an installer's address before you run it. StepSecurity adds forwarded SSH agents to that list.
2. No long-lived tokens on laptops. Use short-lived credentials, with an approval path that is separate from a developer's session, so a compromised session can't approve itself.
3. The signer assumes its caller is compromised. It gets its own allowlist, caps, a rate breaker and a second approval from somewhere else, and on Ethereum it rejects delegations nobody expected.
4. Logs leave the box immediately. Ship them to a place the app's identities can't write to, and make them tamper-evident, so an attacker can't clean up behind themselves.

And one more for this era: an AI tool that can reach other machines is a production identity. Binance hasn't said how its internal tool was used, only that it was part of the path. Give yours the same scoping, logging and review you would give any service with that kind of access.

---

You probably don't have six billion dollars at risk. But you likely have a cloud token and a payment key on your laptop right now, and the same five links between them and your customers' money. I build these labs, break them, and fix them in the open every weekday. If you've shipped something AI-built and want it checked properly, that is exactly the work I do. For the wider pattern, see the security risks nobody checks in vibe-coded apps.