AI did not steal $6.3 billion from Binance

9 min read

Binance lost $6.36 billion on Wednesday. The most-shared explanation blames an AI agent, and it is wrong in a way that points you at the wrong defence.

On Wednesday evening somebody moved $6.36 billion out of Binance's hot wallets across ten blockchains. About $3.79 billion of it on Ethereum, about $1.47 billion on Bitcoin, the rest spread over Tron, XRP Ledger, Solana and five more. It is the largest crypto theft ever recorded — roughly four times the $1.5 billion taken from Bybit in February 2025.

Binance says it is covering all user losses out of its own reserves. The companies that issue the tokens froze about $2.7 billion of it in flight. About $2.4 billion is still gone and unfreezable, because more than 420,000 ETH and 18,270 BTC have no issuer to call.

That is the news. The reason I am writing is the explanation that has attached itself to it.

What the internet decided happened

Three posts landed in my feed within an hour of each other. The first was straight reporting. The second was a crypto channel with the one detail that actually matters, which I will come back to. The third had the explanation that is spreading fastest, and it goes like this:

An AI agent scanned millions of files, chat messages and folders in about three seconds, found a password an engineer had left lying around, walked up to the vault with the right key, and emptied it before any human noticed. "It has to be the agents."

It is a good story. It is vivid, it explains the speed, and it arrives with a told-you-so. Under the straight news report, the top comments say the same thing in fewer words: that AI really comes in handy, they definitely used AI to hack.

I understand the appeal. It is also contradicted by the two organisations that have actually looked.

What the evidence says instead

Binance's co-CEO Richard Teng gave an initial account on Thursday. The entry point was a compromised DevOps engineer's laptop, which gave an attacker access to a service container from which unauthorised withdrawal transactions were submitted.

Then the three sentences that take the viral version apart:

Binance found no evidence of any wallet private key leak. No dropped key was found, because the investigation says no key was taken.
The attacker "did not simply use one engineer's permissions."
It was "not a single 'one-click' action" but "a more complex attack process."

Binance has since said further investigation uncovered additional points of breach. It has not blamed any individual, and it has promised a full technical post-mortem.

TRM Labs' forensic account fills in the mechanism, and it is the opposite of a lucky three-second grep. On Ethereum the attacker submitted a delegation carrying 50 pre-signed authorizations across consecutive transaction counts, which turned a Binance hot wallet into a sweeper under its control. The signatures were obtained in advance. The staging began well before the money moved. TRM attributes the operation to North Korea's TraderTraitor, the crew behind Bybit, partly on the strength of small Tornado Cash withdrawals funding an operator wallet weeks earlier.

Nobody — not Binance, not TRM — has published any evidence of AI or autonomous agents in this attack.

So why does the difference matter?

Because the viral story's defining feature is speed, and speed is precisely what the evidence contradicts.

The theft took about 20 minutes, from 20:05 UTC, in sweeps at 20:23, 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56. That is real and it is where every headline is pointing. But those 20 minutes were the last 20 minutes. The signatures already existed. The access already existed. The operation had been sitting inside the building for weeks, waiting.

Mistaking the visible fast part for the whole event changes what you buy. If you believe a fast robot found a dropped password, you go shopping for something that watches for fast robots. If you understand that one compromised laptop reached a path that could authorise an irreversible withdrawal, and that nothing further down that path was able to refuse, then you fix the authorisation path. Those are different purchases, and only one of them would have helped.

The AI angle that is actually real

There is one, and it is duller and more useful than agents-did-the-heist.

An engineer's laptop in 2026 is not what it was. It holds tokens, cloud sessions, repository access and increasingly AI tooling that acts with that engineer's permissions on their behalf. The laptop has not become easier to steal. What one stolen laptop can reach has grown. That is a blast-radius problem, and it is worth money to fix — but it is a boring architectural fix, not a product with a logo.

While I am here: the same post that explained the hack as AI agents also suggested moving money into metals. I am not a financial adviser and I am not repeating that as advice. I mention it because it is the tell. An explanation that arrives already knowing what you should do with your savings is selling something, and the thing it is selling is usually itself.

The php2shell line, and an admission

The same post chains this hack to php2shell, the critical PHP flaw that had banks and governments turning their own websites off a week earlier. I wrote about that at the time, and I said plainly that as of 22 October no successful break-in had been publicly confirmed anywhere.

That sentence is now out of date, and it took two days to go out of date. On 23 and 24 October php2shell moved from attempts to working shells: a Chinese threat actor chained it with a firewall flaw to root about 24 firewalls, two of them in a United States government-affiliated environment, and CISA added both flaws to its Known Exploited Vulnerabilities catalogue. Against millions of attempts, six or so confirmed successes is still a small number — but it is not zero, and zero is what I wrote.

I am correcting it here because I dated that claim on purpose and told readers to re-check it. The dating is the only reason it is merely stale rather than wrong, and it is the single cheapest habit in technical writing.

What has not been shown by anyone is a link between php2shell and this theft. Different flaw, different attacker — php2shell's confirmed exploitation is attributed to a Chinese actor, this theft to North Korea. Two serious events in the same fortnight is a fortnight, not a chain.

What I would change, if it were your business

You are not running a crypto exchange. The principle survives the change of scale anyway, and it is one sentence:

No single compromised thing should be able to authorise an action you cannot reverse.

Not one laptop, not one API token, not one admin login, not one automation running unattended at 3am. The question worth asking about your own systems is not "could someone get in" — assume yes — but "if they got into the worst single thing, what could they move, and what downstream of it would say no?"

I build to that rule because I have to. The payment service I run never holds a key and never sends funds; the customer's wallet pays the business's own wallet and my code only reads the chain. That is not a promise in a document, it is a test that fails the build if any file in it gains the ability to hold a key or send a transaction. The repositories behind all of this are read with per-repository read-only keys rather than one token that could write to everything, for exactly the reason Binance is now explaining to its customers: a stolen credential should cost you one thing, not all of them. That service is running on a test network, with no live money yet, and an accountant and an attorney sign off before that changes.

None of that is clever. It is just deciding, in advance and in writing, what each piece of your system is allowed to do — which is a design decision, taken once, by one engineer with the whole picture in view.

The limits of what I have told you

This is one day old. Binance's own account changed between Thursday morning and Thursday afternoon, from one laptop to several points of breach, and it will change again when the post-mortem lands. The attribution is TRM's, and attribution in this field is probabilistic. I am not a security vendor and I am not selling you an incident response.

What I am fairly confident of is the shape: this was a patient, human, well-resourced intrusion into a signing path, not a robot that got lucky in three seconds. If that turns out to be wrong, the correction will appear on this page with the date on it.

Sources

Forensics and figures:

Binance's own account:

On php2shell, including the correction above:

The cheap version of the blast-radius question starts with what is already public about you. I run a free check that loads your site in a real browser and tells you what is broken on it — no signup, no email, nothing to buy: run the website check.

If you would rather have the conversation about the authorisation paths, the free 30-minute Operations Audit is where I go through how your business actually runs, what runs unattended, and what one stolen laptop could reach — including when the honest answer is "less than you feared."

9 min read