Binance’s $6.3 Billion Hack: A DevOps Laptop, a Service Container, and Withdrawals Nobody Approved

The largest crypto theft on record did not, on Binance's account, begin with a broken cipher or a stolen wallet key. It began with a laptop. Binance has said roughly $6.3 billion of client assets were affected after an attacker gained access through what its initial investigation described as a compromised DevOps engineer's laptop. That access, Binance said, allowed the attacker into a service container and to submit unauthorised withdrawal transactions. The exchange says it found no evidence that private keys leaked from its wallets.

The pattern will be familiar to anyone who read our piece on the Bitget theft a month ago: the funds moved because a system with the authority to ask for withdrawals was taken over, not because the cryptography was defeated.

Updated 3 November. The FBI has since attributed the theft to North Korea. The update below covers what that settles and what it does not.

Update: the FBI names TraderTraitor

On 31 October the FBI published a short statement advising that North Korea was responsible for the theft of more than $6 billion in virtual assets from Binance, attributing it to the group known as TraderTraitor. BleepingComputer, Infosecurity Magazine and The Hacker News report that the statement dates the theft to on or about 29 October, says the group is converting the stolen assets mainly into Ether, and urges cryptocurrency firms to block related addresses. We could not open the FBI's own page, which returned an access error, so these details come from that reporting and from the statement's opening line as it appears in our feed.

That moves the attribution from vendor assessment to government assessment, and it follows the earlier attributions by TRM Labs and Chainalysis. It does not tell us how the attacker got in. The reporting still describes Binance's own technical analysis as pending, and the figure varies by outlet, from about $6.3 billion in most reports to $6.43 billion in The Hacker News's headline.

What is confirmed

According to CNBC, PBS NewsHour and other outlets reporting Binance's statements, the exchange says about $6.3 billion in token assets was stolen from its hot wallets, that deposits were unaffected and that most user assets sit in cold wallets. Roughly $3 billion has been frozen with partners. TRM Labs counted about $6.36 billion moving across ten blockchains, most of it in about 20 minutes.

How it started. Binance's early statement pointed to a compromised DevOps engineer's laptop, a service container and unauthorised withdrawal transactions.
It got bigger than one laptop. Co-CEO Richard Teng later said the attack was more complex than the misuse of a single engineer's permissions, and reporting describes several “points of breach”.
Keys. Binance says there is no evidence of private-key leaks from wallets. We read that in one summary of its statements rather than in Binance's own words.
Coverage. Binance says it will absorb the loss, not its users, and that it has restored backing for up to 90% of the affected assets from its user-protection fund, part of its futures insurance fund and corporate treasury. Withdrawals were expected to resume on Sunday, 1 November, subject to security checks.

What is not known

The full attack path. Binance has promised a detailed technical analysis. Until then, every account of the mechanism is preliminary and the reporting differs on whether the service container is part of the confirmed picture.
Binance's own position on attribution. The FBI, TRM Labs and Chainalysis all point to the North Korea-linked group TraderTraitor, TRM citing similarities to earlier heists including Bybit. In the reporting we read before the FBI statement, Binance had not confirmed an actor and said it was working with law enforcement. We have not seen a later Binance statement either way.
How much has been laundered or recovered. Unclear.
Which controls existed and failed. Binance has not described its withdrawal approval or monitoring setup.

The lesson is about authority, not keys

A hot wallet exists to move money quickly, so some system must be allowed to request withdrawals. If that authority sits in a service that an engineer's workstation can reach and influence, then compromising the workstation is a path to the money without touching a single private key. Binance's own phrasing, access to a service container and the ability to submit withdrawals, describes exactly that gap.

Engineers' machines are also where long-lived credentials collect: cloud and cluster access, deployment tokens, SSH keys, tokens in shell history and environment variables. An attacker who owns one such machine inherits whatever it was trusted to do.

What to do, whatever you run

Treat privileged engineers' devices as production. Require hardware-backed sign-in, managed and patched devices, endpoint detection and no standing access from personal machines.
Remove standing privileges. Replace permanent cluster and cloud admin rights with just-in-time access that expires, and use short-lived credentials instead of tokens that live for months on laptops.
Separate who can ask from who can approve. A service that can request a high-value action should not be able to authorise it. Require an independent approval path, outside the compromised environment, for transfers above a limit.
Limit what the hot path holds. Keep only operating balances where automation can move them, with per-transaction and per-hour caps and automatic holds on anomalies.
Watch behaviour, not just credentials. Alert on service containers that begin doing things they never did, such as submitting withdrawals from unusual contexts or in unusual volumes.
Plan the response before you need it. Know who can freeze movement, how to rotate every credential a given engineer's device could reach, and how replacements are delivered.

The handover during an incident

When one engineer's laptop is the suspected entry point, anything that engineer could read has to be rotated, and the replacement values must reach other engineers. If they travel through the chat or ticketing system the compromised machine could see, you have given the attacker the new keys. Deliver each value once, to the one person who needs it, over a channel that does not keep it and does not depend on the suspect device.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not an exchange security product, an approval workflow or a wallet system. It cannot harden an engineer's laptop, limit what a container may request or stop a withdrawal. Those controls belong in your infrastructure; a one-time link is for the moment a person hands another a credential.