The Binance Hack, Explained: One Laptop, One AI Tool and 20 Minutes to $6.3 Billion

At 20:05 UTC on Thursday, October 29, five of Binance’s XRP hot wallets started sending money to a single address. By 20:09 they had sent 233.46 million XRP. A few minutes later, wallets on Solana and Optimism emptied. At 20:20, a Bitcoin hot wallet sent 18,270 bitcoin, and in the same block the coins were split into pieces of 1,000 and 100 for the long walk through the laundering chain. Within two minutes a Tron wallet sent 612.7 million USDT. And on Ethereum, about three and a half minutes after a single transaction carried 50 pre-signed authorizations, the hot wallet’s entire balance left: 167,464 ether and 63 other tokens, including 1.615 billion USDT (TRM Labs).

Most of about $6.3 billion moved in roughly 20 minutes. It’s the largest crypto theft on record, about four times the size of the Bybit theft in February 2025 (PBS NewsHour). The FBI attributes it to North Korea’s TraderTraitor group. North Korea called the claim “preposterous nonsense” (Tom’s Hardware).

Last week, Jon wrote about how it started, in Hiring Is Now an Attack Surface: a fake recruiter, two video interviews and a take-home test run on a work computer. That’s the part of the story everyone repeated. This post is about the part in between, from the moment the attackers had one laptop to the moment the money left, because that’s where nearly every lesson for founders lives.

Two links in that chain have “AI” in them. In June, an engineer picked up a tampered copy of Homebrew while searching for an AI coding tool. And on October 20, the attackers used an internal AI tool to take over two more engineers’ machines. Neither is a story about artificial intelligence being clever. Both are stories about AI tools being trusted, which is a more useful lesson, and an older one than it looks. Jon puts it in one sentence: “AI does not change the security game, it just amplifies it.”

The short answer

The Binance hack was a five-month campaign that ended in a 20-minute sweep. Attackers attributed to North Korea got a foothold on one engineer’s work computer through a fake job interview, used an internal AI tool to take over two more engineers’ computers, found a container deployment token on one of them, and used it to deploy a container that reached Binance’s internal wallet signing service. The service signed transfers from five hot wallets outside the normal withdrawal process, including Ethereum delegations that pausing withdrawals couldn’t stop. Binance says about $6.34 billion was affected, about $2.85 billion was frozen or intercepted, and customers were made whole.

For a founder, the lessons fit on one card:

1. A developer laptop is part of production if anything on it can deploy, sign or reach customer data.
2. Internal AI tools are privileged systems. Anything that can act on employees’ machines needs its own authorization, separation and logs.
3. Production credentials don’t live on laptops. Deploy from a pipeline, with short-lived credentials tied to the workload.
4. Put the rules on the money path itself: limits, allowlists and approvals enforced by the system that signs or pays, not by the session asking.
5. A pause button is only as good as the paths it reaches. List every way value or data can leave, and test that you can stop each one.
6. Speed belongs to whoever prepared. Rate limits, delays and pre-arranged relationships buy the minutes humans need.
7. The response is part of the product. Binance kept its customers by paying, explaining and apologizing quickly.

Five months, step by step

Binance published its initial findings on November 3, five days after the theft (The Hacker News). We’ve read it alongside the reporting and the on-chain analysis, and here’s the chain in order.

June: the search. Engineer A, on Binance’s Wallet DevOps team, searched for a popular AI coding tool and downloaded a tampered Homebrew installation, the package manager most Mac developers use. Binance’s security team detected the anomaly, replaced his computer and rotated his credentials. But the attacker had already learned what he did and who he worked with on the wallet infrastructure (StepSecurity).

September: the interview. Engineer B, looking at jobs, was contacted through a legitimate recruiting platform by someone posing as a project director. After a video interview and a second round with someone posing as a chief executive, he downloaded a coding “assignment” onto his work computer. The code ran during setup, replaced a component of a common Python development tool with a poisoned copy, contacted the attacker’s server and cleaned up after itself. In Binance’s words, “The 0-day malware was not detected by the endpoint security protection tools at the time.” StepSecurity, reading Binance’s forensic notes, points out how small the change was: the legitimate pyenv file was 3,344 bytes, the replacement 3,414 (StepSecurity). Seventy bytes.

October 20: the AI tool. The attacker used Engineer B’s computer and an internal AI tool to take control of the computers of Engineer A, the one from June, and another wallet engineer, Engineer C. On Engineer A’s computer they found a token with permission to deploy containers.

October 29, 17:15 to 19:56 UTC: the container. The attacker logged into Engineer C’s computer, used the credentials taken from Engineer A, deployed a container and triggered a malicious script (The Hacker News). That gave it access to Binance’s internal wallet signing service.

From 20:05 UTC: the sweep. The signing service initiated transactions from five hot wallets outside the normal withdrawal process. On Ethereum, it signed the authorizations that handed a hot wallet’s execution to the attacker’s contract. The last unauthorized Ethereum transfer, 2,961.9 ether, finalized at 23:56 UTC, and Binance cleared the affected wallet’s delegation at 00:10 UTC on October 30 (StepSecurity).

Binance’s own summary of the whole thing is the sentence we’d want every board to hear: “It was not a single isolated breach or a simple phishing incident.” Its co-chief executive, Richard Teng, put it more bluntly on X: “This wasn’t one mistake or one breach,” but “a months-long campaign” (The Block).

The search box was the first door

The first compromise didn’t involve a recruiter at all. It involved a search engine and an engineer doing exactly what engineers have been told to do all year: try the new AI coding tools.

That’s the quieter AI story in this hack. The rush to adopt AI tools has created a steady stream of people searching for installers, plugins and command-line tools they’ve never installed before, from names they half-remember. Attackers have always followed demand. A tampered installer waiting at the top of a search for a popular AI coding tool is the 2026 version of the fake browser update. StepSecurity’s write-up lists a run of recent cases on the same theme: trojanized builds of a popular AI coding agent distributed through a code editor’s marketplace in October, and malicious repositories that launch credential stealers the moment an AI coding session starts (StepSecurity).

The answer isn’t to slow your engineers down. It’s to give them a paved road. Keep a short, current list of the AI tools your company has approved, with the one correct place to get each, and make adding a new one a five-minute request rather than a reason to go searching. Developers will take the road you pave if it’s faster than the one they’d find on their own. We wrote about how to do that without turning into the department of no in The Art and Zen of Adopting AI.

Notice, too, what Binance did right in June. It caught the tampered install, replaced the laptop and rotated the credentials. The incident was handled. What it couldn’t take back was information: who worked on the wallets. Attackers this patient treat every small incident as reconnaissance. A good postmortem asks “did we contain it?” and then a second question: “what did they learn, and what will they do with it?”

The AI tool in the middle

Here’s what we know about the internal AI tool, and it’s not much. Binance says the attacker used Engineer B’s compromised computer and an internal AI tool to gain control of Engineers A and C. It refers to “compromised internal AI tooling,” says it has rebuilt the tool and its access controls, and hasn’t said how the tool was used (The Hacker News). StepSecurity’s careful reading is right: the report doesn’t identify a software zero-day, a prompt injection, a Model Context Protocol exploit or a named commercial product as the cause (StepSecurity).

So we won’t guess at the mechanism. We’ll say what the outcome tells you, which is enough. Somewhere inside Binance was an AI tool that could do things on more than one engineer’s computer, and someone with access to one engineer’s computer could use it to reach the others. Whatever the tool was, it was a bridge between people’s machines, and bridges work in both directions.

Most startups now have tools like that, and most founders haven’t counted them. An internal assistant wired into Slack that can run scripts. A coding agent with access to every developer’s repository and a shared set of credentials. A support bot that can look up customers and issue refunds. A device management tool with an AI layer that can push commands to every laptop. Each of these is, functionally, one of the most privileged identities in your company. Most of them were set up in an afternoon by someone who was trying to save the team time, which is a good instinct, and nobody wrote down what they can reach.

StepSecurity’s advice is the one we’d adopt word for word: “Review internal AI tools as systems with execution privileges.” Inventory what each one can reach. Require authorization at each target, not just at the front door of the tool. Keep one user’s session from acting on another user’s machine. And log the initiating user, the effective identity, the target and the action, so that “who asked the tool to do this?” has an answer (StepSecurity).

We’ve made the same argument about agents in Your AI Agent Said No. Your API Key Said Yes., about shared credentials in Your Agents Share One API Key, and about write access in Are You Actually Going to Give the Agent Write Access?. The Binance report is the most expensive illustration yet. The tool’s job was to help engineers. Its reach made it the attacker’s best lateral movement tool.

This is where Jon’s full line belongs, because it’s the honest frame for the AI part of this story:

He’s been saying a version of it on the show for a long time. Here he is on episode 53, in 2024:

Listen · Jon on episode 53, from 8:53

The internal AI tool at Binance was picked up by someone good, for good reasons, and then by someone evil, for the reasons you’d expect. The tool didn’t change. Its reach did the amplifying.

The token on the laptop

If one detail in Binance’s report should change something at your company this month, it’s this one: Engineer A’s computer held a token with permission to deploy containers.

That single fact turned a compromised laptop into a path to the signing service. When the report came out, the Hacker News discussion went straight to it:

"Why did the employee have direct access to $6.3 billion in customer funds?"

paxy, commenting on North Korean fake job interview led to $6.3B Binance heist, November 2026

Another commenter answered that the engineer didn’t have the funds directly, but:

"...he could deploy code that had access to customers' wallets. Which is even worse."

Maken, replying in the same thread, November 2026

That reply is the whole lesson. Nobody at Binance had the wallets’ keys on a laptop. Someone had the ability to deploy code that could use them, and that turned out to be just as good. Most startups have the same shape somewhere: a cloud admin token in an engineer’s shell profile, a deploy key in a .env file, a long-lived personal access token that can push to the main branch, a kubeconfig with cluster-admin. We wrote a whole post about the first of those, The .env File Is Your First Security Program, because it’s where nearly every startup’s secrets problem starts.

Daniel Feldman, who worked on SPIFFE and SPIRE, the open-source standards for giving software workloads their own identities, at Scytale and then HPE, put the principle more memorably than we can on episode 3:

Listen · Daniel Feldman and Jon McLachlan on episode 3, from 28:19

The practical version: production deploys happen from your build pipeline, which proves its own identity with short-lived, workload-bound credentials, and never from a person’s laptop. If an engineer needs to touch production, they request access that expires, through a system that logs it, on a device that proves who they are. Jasson Casey of Beyond Identity made the device half of that argument on episode 92, and we wrote it up in device-bound credentials. None of it is exotic. All of it would have broken this chain at the token.

The signing service did what it was told

On the night of the theft, Binance said: “We have found no evidence of any wallet private key leak” (CoinDesk). That’s true, and it’s the scariest sentence in the incident. The keys never left. The service that held them did exactly what it was asked, by a container that had been deployed with real credentials.

TRM Labs saw this in the chain before Binance said a word. On nine of the ten blockchains, the stolen funds left through ordinary signed transfers, all within about half an hour, which is why TRM pointed to the signing infrastructure rather than to phishing alone (TRM Labs). One commenter summed up the category:

"Access to use keys is less bad in many ways than leaking keys, but still pretty useful."

justincormack, commenting on The $6.3B Binance hack was pulled off in just 20 minutes, October 2026

The defense is to put the rules on the key, not around it. Riad Wahby, co-founder of Cubist, which builds key management for exactly this kind of signing, described it to us on episode 69:

Listen · Riad on episode 69, from 2:02

Jon’s reply on the tape was “I love connecting your authZ directly into the mechanism that’s driving the transaction,” and it’s still the most important design idea in this post. Authorization that lives in the session, the dashboard or the withdrawal workflow can be walked around by anyone who reaches the service behind it. Authorization that lives with the key, or with whatever system signs, pays or exports, holds no matter who’s asking: limits on how much can move per minute, allowlists of destinations, delays on large or unusual transfers, and independent approval for anything outside the pattern.

For a startup without a single crypto wallet, the same idea applies to whatever your signing service is: the payout system that moves money to your customers’ customers, the export job that can copy your whole database, the release pipeline that signs the software your customers install, the admin API that can reset any account. Ask what it would do if a valid-looking request arrived from inside, at 20:05 on a Thursday. If the answer is “whatever it was asked,” that’s the first thing to fix.

The pause button that couldn’t reach

When Binance realized what was happening, it suspended withdrawals. It didn’t stop everything, and the reason is the most technical part of the story and one of the most transferable.

EIP-7702 is an Ethereum feature, added in the Pectra upgrade in May 2025, that lets an ordinary account delegate its execution to a smart contract’s code. The delegation persists after the transaction that sets it. Using Binance’s signing service, the attackers submitted 50 pre-signed authorizations in a single transaction, spread across a range of the account’s sequence numbers so that one of them would match when it executed, and pointed a hot wallet at a contract only they controlled (TRM Labs). From then on, the wallet would do what the contract said, whatever Binance’s withdrawal system did.

Binance’s report says it plainly: “Suspending withdrawals alone could not stop all unauthorized asset movements.” And because the wallet’s key was split across parties using multi-party computation, “there was no single private key that could be used to immediately revoke the malicious EIP-7702 authorizations,” so the team had to use a specialized procedure to revoke them (Kapitalexperte). It cleared the wallet’s delegation at 00:10 UTC, about four hours after the sweep began.

A pause button is only as good as the paths it reaches. Every company has this problem in a less exotic form:

• Disabling a user doesn’t end their active sessions or revoke the refresh tokens they already hold.
• Rotating an API key doesn’t revoke the short-lived tokens already minted from it.
• Turning off a feature doesn’t stop the background job that already picked up the work.
• Removing someone from the admin group doesn’t remove the OAuth app they authorized or the webhook they registered.

The exercise that finds these is simple and slightly uncomfortable. List every path by which money or data can leave your company: payouts, exports, integrations, admin tools, API keys, scheduled jobs. For each one, write down what stops it, how long it takes, and when you last tested it. Our blast radius playbook and agent offboarding checklist both walk through this for different kinds of identity. The rule underneath them is the same: revocation has to reach everything that was granted, not just the front door.

Twenty minutes, and the forty that followed

Speed is the part of this story that feels new, and it’s worth understanding where it came from. The attackers didn’t type fast. They prepared. TRM traced the operator’s wallet being funded through Tornado Cash on the morning of October 28, the attack code deployed and tested on two wallets early on October 29, a final rehearsal on a third, and only then the run against Binance (TRM Labs). By 20:05 the decisions had been made. What was left was execution, and execution by machine takes minutes.

The defenders’ side moved fast too, and it deserves more attention than it got. Tether froze 971.1 million USDT at 21:01 UTC, 37 minutes after the main sweep. Circle froze 823 million USDC at 21:04. Ripple, World Liberty Financial and others followed within the next hour and a half, and just after midnight Arbitrum’s Security Council forced about $30 million out of the attacker’s wallet (TRM Labs). By November 3 Binance counted about $2.85 billion frozen or intercepted. Unchained’s guests put the share frozen at about 43 percent, against under 3 percent after Bybit (Unchained). Richard Teng’s comment on X: “The speed of coordination could not be matched in traditional finance” (The Block).

The useful idea for founders is that both sides of that timeline were won before the night started. The attackers had rehearsed. The stablecoin issuers had freeze procedures, relationships with exchanges and analysts watching. On Unchained’s Bits + Bips, Austin Campbell argued that crypto never adopted what the show’s notes call “the withdrawal delays and circuit breakers TradFi treats as basic risk management” (Unchained), which is the same point from the other direction: a rule that slows large movements buys the minutes that humans and partners need.

Your version is smaller and just as real. If someone started moving customer data out of your company at 20:05 on a Thursday, who would notice, how fast, and whom would you call? Do you know the right person at your cloud provider, your payments processor and your identity provider, and do they know you? Have you ever practiced?

Channi Greenwall, founder and chief executive of Olympix, made the broader point on episode 85, about Bybit, and it fits Binance even better:

Listen · Channi Greenwall on episode 85, from 16:02

Laptops, recruiters, developer tools, deployment tokens and an internal assistant. Every door in the Binance hack was a Web2 door. Only the money was on-chain.

What Binance got right

It would be easy to write this post as a list of Binance’s mistakes, and we don’t think that would be fair, or useful. Companies with large, skilled security teams get breached by patient state-backed attackers. Binance says it stopped an estimated 57 suspected North Korea-linked attacks this year (The Block). This one got through. What happened next is worth studying as carefully as what happened before.

It paid first. Binance said within hours that it would cover all losses, reserved more than $6.34 billion of its own funds, and reported replenishing 98 percent of the affected token assets. Deposits kept working, and withdrawals reopened in phases from November 1 (PBS NewsHour, StepSecurity). A pre-committed reserve, its Secure Asset Fund for Users, made that promise believable on the first night.

It explained, specifically and quickly. The initial findings came out five days after the theft, with dates, file sizes and the uncomfortable parts left in. Teng: “We’re publishing the full report because the lessons go far beyond Binance.”

It apologized without hedging. “This should not have happened, and we apologise for the concern, disruption and uncertainty it caused” (TNW).

It picked up the new tools. Binance says it is expanding AI-based behavioral anomaly detection, investing more in AI security and setting up a security research fund with AI companies and security firms (Blockhead). That’s Jon’s line in practice. The attackers used AI tools as a lure and as a bridge. The answer isn’t fewer AI tools. It’s defenders using them at least as well.

For a founder, the lesson is that incident response is a product your customers experience, and they judge it on the same things they judge everything else: did you take care of them, did you tell them the truth, and did you do it quickly. You can decide most of that in advance, the way Binance did with its reserve: who speaks, how fast, what you’ll cover, and what you’ll publish.

One commenter in the Hacker News thread put the criticism as sharply as anyone: “Binance has the IT culture of a SV start-up when it should have the IT culture of a bank.” It stings a little, reading it as founders. We’d turn it into the useful version. The culture that gets a company from zero to something, try everything, move fast, trust your people, is the right culture for the early days. As the value you hold grows, the parts of that culture that touch the money have to grow up first. Not the whole company. The money path.

Why this lands on a founder’s desk

Most founders reading this don’t run an exchange. You still have a money path, and the Binance chain maps onto it with almost no translation.

Your signing service is whatever system can move your most valuable thing: the payout service, the database export, the release pipeline that signs your software, the admin API that can reset any account. Your deployment token is whatever credential on an engineer’s machine can reach it. Your internal AI tool is the assistant, agent or bot that can act on more than one person’s behalf. And your pause button is whatever you’d reach for at 20:05 on a Thursday.

Enterprise buyers have started asking about all four, in plain language, because their boards asked them after Binance:

• Can a single compromised laptop deploy to production or reach customer data?
• Which internal AI tools can take actions, on whose behalf, and how is that logged?
• Where do production credentials live, and how long do they last?
• What independent check sits between a request to move money or data and the movement itself?
• How fast can you revoke every path an engineer or tool had, and when did you last test it?

Chainalysis gave the scale of the pattern in one line from its senior analyst Tom McLouth: “We’ve identified dozens of other job interview compromises that have led to wallet compromises,” adding up to more than $14.3 million over the past 18 months before Binance (Chainalysis). The big one makes the news. The small ones happen to companies your size.

Run the one-laptop drill

This drill walks the Binance chain through your own company, one step at a time, and shows how far a single compromised laptop would get before something stops it. It takes about five minutes, runs entirely in your browser, and ends with a short list of fixes in the order they’d break the chain.

Interactive · 5 minutes · Runs in your browser

The one-laptop drill

Pick the answer closest to what's true today. The chain updates as you go.

The drill needs JavaScript. Its nine steps follow this post: where tools come from, whose code runs on work machines, what internal AI tools can reach, where production credentials live, how deploys happen, what rules live on the money path, what the pause button reaches, how fast you'd notice, and how fast you can revoke.

Load an example startup Start over

…chain strength, out of 100

…where you stand

…where the chain breaks first

…the weakest link

Copy the plan Download (.md) Print

Everything here runs in your browser and is saved only in this browser. The weights reflect our experience with startups and the order of the Binance chain, not a standard. A real answer comes from testing the chain, not from a form.

Have an operator run the drill with you →

We get your email, the level you picked for each step and your result, nothing else. Jon or Sasha replies to set up a short session that tests the chain for real. No sequence.

What to do this week

Start at the top. Each item breaks the chain earlier than the one below it.

1. Pave the road for AI tools. Publish the short list of approved AI coding tools, assistants and extensions, with the one correct place to install each, and a five-minute way to request a new one.
2. Keep strangers’ code off work machines. Interviews, take-home tests and side projects happen on personal devices or in throwaway sandboxes, as a written, no-blame norm. The hiring post has the full version.
3. Count your internal AI tools. For each assistant, agent or bot that can take actions: what it can reach, on whose behalf, whether one user can make it act on another user’s machine, and where its actions are logged.
4. Get production credentials off laptops. Find every long-lived cloud key, deploy token, cluster credential and signing key on engineers’ machines, and replace them with short-lived, logged access.
5. Deploy only from the pipeline. Make it impossible, not just discouraged, to push production changes from a laptop.
6. Put rules on the money path. Limits, allowlists, delays and independent approval enforced by whatever system pays, signs or exports, regardless of who’s asking.
7. Test the pause button. List every path for money and data to leave, and for each one confirm what stops it and how long it takes. Then practice revoking one engineer’s entire access and time it.

If you want help with the quiet version of this, it’s what our counter nation-state espionage and AI access control audit teams do, under a nondisclosure agreement and on a need-to-know basis inside your company.

Turn it into an answer buyers trust

When a customer’s security team asks what you learned from Binance, the answer that builds trust is the same shape as always: short, specific, dated. Once it’s true, it sounds like this:

Sasha’s guide to building sentences like that one is The 10 AI Security Questions Your First Enterprise Buyer Will Ask in 2027. On Monday we covered *sshole, the OpenSSH bug that AI agents found and attackers used within hours, and the same lesson runs underneath both: the clock is shorter now, so the preparation has to happen before the night it’s needed. Friday’s post is about ARTEX, the open-source AI hacking tool that turned up in a string of breaches this autumn. We’ll also be in Austin next April for MicroConf US, where YSecurity is a sponsor and our talk is “How Founders Turn Security Commitments Into Revenue.” It’s on our events page.

The Binance hack will be remembered for the number. We’d rather remember the shape: one ordinary search, one ordinary interview, one helpful tool with too much reach, one token in the wrong place, and a signing service that did exactly what it was told. Every one of those is fixable this month, at a company of any size, before anyone patient comes looking.

Jon and Sasha