Binance Hack 2026: How $6.3B Was Stolen, and the Lessons

The Binance hack is the theft of about $6.3 billion in crypto from Binance hot wallets on 29 October 2026, the largest crypto theft on record. Binance’s initial investigation points to a compromised DevOps engineer’s laptop. TRM Labs and Chainalysis attribute the attack to North Korea’s TraderTraitor group.

This post reflects public reporting up to 30 October 2026, one day after the theft. Binance has not published a full root cause, so we separate what is confirmed from what is assessed.

TRM Labs traced about $6.36 billion leaving Binance wallets on ten blockchains, most of it in roughly 20 minutes from 20:05 UTC. Binance’s own estimate is about $6.3 billion. That is about four times the $1.5 billion Bybit theft of February 2025.

The largest losses by chain, valued by TRM at transfer-time prices:

Chain	Approximate loss	Includes
Ethereum	$3.79 billion	200,630 ETH, 1.875 billion USDT, 823 million USDC
Bitcoin	$1.47 billion	18,270 BTC
Tron	$628 million	612.7 million USDT, 46.4 million TRX
XRP Ledger	$296 million	233.46 million XRP
Solana	$96 million	970,500 SOL

Binance suspended deposits and withdrawals. It says it will cover all losses from its SAFU fund and company funds.

Binance has given one early answer. Its statement on X says the incident “may involve a compromised DevOps engineer’s laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions.” It adds that it found no evidence of a wallet private key leak.

That is not the whole chain. Co-CEO Richard Teng said the attacker “did not simply use one engineer’s permissions,” and Binance has “uncovered additional points of breach” it has not described. How the laptop itself was compromised is not public.

TRM’s assessment fits Binance’s account: the attacker most likely gained the ability to make the hot wallet signing system sign transactions of their choosing across chains. If that holds, the attacker never needed the keys. They only needed the system that uses them.

The attack was rehearsed. TRM’s timeline shows preparation starting at least 36 hours before the theft, funded by small Tornado Cash withdrawals.

Time (UTC)	Event
28 Oct, morning	Operator wallet receives three small Tornado Cash withdrawals
29 Oct, early	Operator deploys code and tests it on two wallets, then rehearses on a third
29 Oct, 20:05	Five XRP Ledger wallets begin sending funds to one attacker address
29 Oct, 20:20	Bitcoin hot wallet sends 18,270 BTC; Tron wallet follows within two minutes
29 Oct, 20:20	One Ethereum transaction carries 50 pre-signed EIP-7702 authorizations
29 Oct, about 20:23	Ethereum hot wallet is swept: 167,464 ETH and 63 tokens
29 Oct, 21:01	Tether freezes 971.1 million USDT in the main receiving wallet
29 Oct, 23:05	Second wave hits Avalanche and Polygon wallets

The Ethereum step is the unusual one. EIP-7702 lets a wallet hand its behavior to a smart contract through a signed authorization, so the attacker pointed the hot wallet at a sweeper only they could instruct. They pre-signed 50 consecutive nonces to be sure one would match, which TRM reads as a sign that access was time-limited or signatures had to be requested through a system.

TRM attributes the attack to TraderTraitor with high confidence, and Chainalysis named the same group as the likely perpetrator. Binance has not named anyone. No government attribution for this theft had appeared when we published, though the FBI attributed the Bybit theft to the same North Korean activity.

The group’s past intrusions are well documented, and they start with people. In the $308 million DMM Bitcoin theft, an operative posing as a LinkedIn recruiter sent a wallet-software employee a GitHub-hosted Python script disguised as a pre-employment test. Wiz’s analysis describes the Bybit path starting from a compromised Safe{Wallet} developer workstation, then stolen AWS session tokens.

Nothing yet shows this is how the Binance laptop was compromised. It is still the pattern a DevOps team should plan for.

About $2.7 billion was frozen by 00:30 UTC on 30 October by TRM’s on-chain count, while Binance’s later update says about $3 billion. Most of it is stablecoins, because Tether and Circle can freeze tokens at the contract level. TRM says the attacker still holds about $2.4 billion in ETH and BTC, which have no issuer to freeze them.

The attacker knew the freezes were coming. They sold about 325 million USDT to market makers at a discount of over 10% and borrowed ETH against USDT on Aave. A freeze is also not a refund: CNBC reports that recovery needs a separate legal process that can take months or years.

You do not need a crypto treasury for these to apply. Any company where an engineer’s laptop can reach something that moves money, ships code or signs things has the same shape of problem. These are our conclusions from the public record, and TRM’s guidance covers the wallet-specific items.

• Make the signer check the request. A service that signs whatever a trusted container sends turns one container into the whole treasury. Enforce amount limits, destinations and rate limits inside the signing system, with a second approval path above a threshold.
• Split signing by chain and wallet tier. One compromised path reached ten chains here. TRM recommends separating signing infrastructure and approval paths.
• Cut standing access from laptops to production. Use short-lived credentials and just-in-time elevation. Our long-lived access keys and privileged access basics exercises drill both sides of this.
• Treat a shell in a container as a breach of the host. The privileged containers exercise shows how quickly that boundary falls. Our container security guide covers the runtime controls.
• Alert on what should never happen. TRM advises alerting on any EIP-7702 delegation on a treasury wallet, and rejecting batches across a nonce range. The general form is logging you have tested, which the audit logging gaps exercise walks through.
• Rehearse the first hour. Tether’s first freeze came 37 minutes after the main sweep, and every minute decided what stayed recoverable. Keep issuer, exchange and law enforcement contacts in a runbook before you need them.

Developers, DevOps and IT staff are the people to brief first, because their laptops hold the access. The approach usually looks like an ordinary career or open source conversation, and the danger is the code you are asked to run.

• Never run a recruiter’s test on a work machine. Use a disposable environment with no credentials, or decline. Our safe browsing and downloads exercise trains the pause before running anything.
• Read code from new contacts as hostile. The malicious pull requests exercise hides a backdoor inside a friendly test fix, the same trust trick applied to a repository.
• Assume your public profile is the briefing. A job title that says “DevOps at an exchange” is targeting data, which is what our spear phishing exercise and social engineering guide cover. Hiring fraud runs the other way too, as in the deepfake hiring fraud exercise.
• Report it even if you already ran it. Early reports are worth more than clean records, and they stop coming if people expect blame. Teng’s statement that the investigation “has not attributed responsibility to any individual” is the right tone for any company.

Crypto makes the loss visible to the cent, but the path is an ordinary one: an engineer’s workstation, then a service, then a system that trusts that service. Enterprise networks have the same chain, ending in a payment system or a production deploy instead of a hot wallet.

The Real-World Incidents catalogue turns breaches into hands-on exercises, and secrets in Git and CI/CD covers the credentials attackers look for once they land. Want your engineers drilled on these approaches before a recruiter message reaches them? Talk to us about rolling out role-based training.