Glacyn Security

Inside the Binance hack: how US$6.3 billion vanished in 20 minutes

Trading screen showing a falling price chart

At 20:05 UTC on Thursday 29 October, late evening in Europe and before dawn across much of Asia, the biggest theft in the history of cryptocurrency got under way. Twenty minutes later, roughly US$6.3 billion had left Binance, the world’s largest crypto exchange, across ten different blockchains. Nobody broke the cryptography. Nobody guessed a password. The attackers simply got Binance’s own systems to sign the money away.

This is the story of how that happened, told as far as the public evidence goes today. It is also, surprisingly, a story with lessons for a 20-person business that has never touched crypto.

The night in numbers

  • ~US$6.36B taken, about four times the previous record (Bybit, US$1.5B in 2025)
  • 10 networks hit, from Ethereum and Bitcoin to Tron, XRP and Solana
  • ~20 minutes for the bulk of the transfers
  • 56 minutes before the first stablecoin freeze
  • ~US$2.7B to 3B frozen by issuers; the rest is still moving

Twenty minutes, ten blockchains

The first transfer hit the XRP Ledger at 20:05 UTC: 233 million XRP pulled from five Binance wallets. Within five minutes, Solana and Optimism wallets were emptying too. At 20:20 the attackers moved 18,270 bitcoin and, within two minutes, more than 600 million USDT on Tron. Around the same moment, the most technically interesting part of the attack was landing on Ethereum. More on that shortly.

What stands out is the choreography. These were not panicked, opportunistic withdrawals. Blockchain analysts at TRM Labs found the attacker’s wallets had been funded through Tornado Cash at least 36 hours earlier, so the gas money for every chain was sitting ready. A second, smaller wave hit Avalanche and Polygon around 23:05, three hours after the first.

Timeline of attacker and defender moves on 29 October 2026, from the first XRP transfer at 20:05 UTC to the Arbitrum Security Council freeze at 00:08
Figure 3. Attacker moves in red, defender moves in green. All times UTC.

How they got in

Every exchange keeps most customer funds offline in “cold” storage, and a working float in “hot” wallets so withdrawals can be paid out in seconds. Hot wallets are connected to the internet by design. The security question is never whether they can sign transactions. It is who gets to ask them to.

According to Binance, the chain started with a single DevOps engineer’s laptop. From that laptop the attackers reached an internal service container, a piece of infrastructure that sits inside the trusted network and is allowed to submit withdrawal requests. From there, requests flowed to the signing system, which did exactly what it was built to do: it signed them.

Binance has stressed that no private keys were leaked. That sounds reassuring, and technically it matters, but it is also the uncomfortable heart of the incident. The attackers did not need the keys. They needed to be inside the room where the keys are used. Binance has also said its investigation found “additional points of breach”, and its CEO Richard Teng described a multi-step attack, so the laptop is probably the opening chapter rather than the whole story.

Attack chain: compromised engineer laptop to internal service container to signing system to hot wallets on ten networks, then to attacker wallets, with part of the funds frozen
Figure 1. The attack chain as reported so far. Binance has not yet published its full root-cause analysis.

How was the laptop compromised? Binance has not said. But the people analysts suspect (see below) have a well-documented playbook: fake recruiters, deepfake video interviews where the “candidate” is asked to install a plugin to fix their audio, and poisoned code repositories or software packages sent as a coding test. Engineers with production access are exactly who they target.

The clever part: turning a wallet into a puppet

On most blockchains, the attackers simply used the signing system to send funds out. On Ethereum they did something more elegant, and more worrying, using a feature called EIP-7702.

Some background. A normal Ethereum account (an “EOA”) is just a key pair. It can sign transactions, but it cannot run code. EIP-7702, added in Ethereum’s Pectra upgrade in 2025, lets an ordinary account delegate to a smart contract, so the account temporarily behaves like that contract. It was designed for good things: batching payments, paying fees in stablecoins, recovering lost access. The owner signs a small “authorisation” saying, in effect, “run this contract’s code as me”.

Each authorisation is tied to the account’s nonce, a counter that ticks up by one every time the account sends a transaction. If the nonce in the authorisation does not match the account’s current nonce when it lands on-chain, it is ignored. That is a safety feature. It also created a problem for the attackers: a busy exchange hot wallet sends transactions constantly, so they could not know in advance exactly what the nonce would be.

Their solution, as reconstructed by TRM Labs, was brute and clever at once. They had the signing system produce 50 authorisations with 50 consecutive nonces, all delegating the hot wallet to an attacker-written “sweeper” contract, and packed them into a single type-4 transaction. Forty-nine would be skipped as stale or early. One would match. It did.

Diagram showing one EIP-7702 transaction carrying 50 pre-signed authorisations with consecutive nonces; the one matching the wallet's current nonce delegates the wallet to the attacker's sweeper contract
Figure 2. Fifty lottery tickets, one guaranteed winner. Only the authorisation matching the live nonce takes effect.

Once delegated, Binance’s hot wallet was effectively running the attacker’s code, and that code only took orders from the attacker’s operator wallet. About three and a half minutes later came the sweep: 167,464 ETH and 63 different tokens, including 1.615 billion USDT, in a handful of transactions.

The nastiest detail is what happened next. A delegation stays in place until it is replaced or revoked. So for the next three and a half hours, every new deposit that landed in that wallet was swept again, until 23:56 UTC. A separate smart-account “executor” path was used to pull a further 823 million USDC. Binance has since revoked the authorisation.

Why does this matter beyond Binance? Because it shows a legitimate convenience feature being turned into a persistent backdoor. Any system that will sign whatever it is asked to sign, including delegations, is only as safe as the system doing the asking.

Every other chain

Ethereum was the biggest prize, but not the only one. The bitcoin was split immediately using a peel chain: the attacker sends most of a balance to a new address and “peels off” a small amount to another, then repeats, hundreds of times. Each hop is trivial, but together they create a branching maze that takes investigators time to follow, and time is what launderers need most.

Bar chart of value taken by chain: Ethereum 3,790 million, Bitcoin 1,470 million, Tron 628 million, XRP 296 million, Solana 96 million, Arbitrum Optimism and Base 39 million, Avalanche 28 million, Polygon 10 million US dollars
Figure 4. Ethereum accounted for well over half of the total. Values in US dollars at the time of transfer.

Estimates of the total vary a little: about US$6.36B from TRM Labs, about US$6.3B from Binance, US$5.9B from Chainalysis and US$6.43B from Elliptic. The differences come mostly from which prices are used and which wallets are counted. They all agree on the headline: it is the largest crypto theft on record.

Laundering at speed

Stealing billions is one problem. Spending them is another. Within hours the attackers were working three angles at once:

  • Fast swaps at a loss. About 325 million USDT was swapped for roughly 122,300 ETH through intent-based and over-the-counter channels at a discount of more than 10%. That is tens of millions of dollars thrown away, which tells you how badly they wanted to be out of stablecoins.
  • Borrowing against stolen collateral. Some funds went into lending protocols such as Aave and JustLend as collateral, letting the attackers borrow “clean” assets against them. If the collateral is later frozen, the borrowed assets are already gone.
  • Dumping freezable tokens. Smaller stablecoins such as RLUSD were sold on decentralised exchanges before their issuers could act.

The urgency around stablecoins is the key to the next part of the story.

The freeze race

Bitcoin and ETH cannot be frozen by anyone. Stablecoins like USDT and USDC are different: their issuers can blacklist an address so the tokens in it can never move again. On the night, that power became the main line of defence.

Tether froze the attacker’s main USDT wallet at 21:01 UTC, 56 minutes after the first transfer, locking around 1.77 billion USDT. Circle followed three minutes later with about 825 million USDC. Ripple froze 40.5 million RLUSD at 22:01, World Liberty Financial froze 27.8 million USD1 at 22:10, and just after midnight the Arbitrum Security Council took the unusual step of freezing 8,426 ETH and 74.6 million ARB on its network.

Together that is somewhere between US$2.7B and US$3B out of the attackers’ reach, a remarkable result for an hour’s work. It also means roughly US$2.4B to US$3.3B, mostly in assets nobody can freeze, is still in play. Expect it to trickle through mixers, cross-chain bridges and OTC desks for months.

Who did it?

TRM Labs and Chainalysis both attribute the attack, with high confidence, to TraderTraitor, a North Korean state-backed group also linked to the Bybit theft. They point to the pre-positioned infrastructure, the laundering patterns and the targeting of individual engineers. Elliptic has been more cautious, and Binance has not named anyone. Attribution in these cases usually firms up over weeks as law enforcement and analysts compare notes, so treat it as likely rather than settled.

What we still do not know

  • How the engineer’s laptop was first compromised.
  • What the “additional points of breach” were, and whether the attackers had been inside for days or months.
  • Why one service container could ask for withdrawals of this size across ten networks without a human approval step or a hard limit stopping it.
  • Whether any controls fired and were missed, or simply did not exist for this path.

Binance has promised a full post-mortem and says customer losses will be covered by its SAFU emergency fund. Withdrawals were halted while the affected systems were rebuilt, and bitcoin fell about 5%, briefly dipping below US$77,000, as the news spread.

What a $6 billion hack teaches a 20-person business

You probably do not run a crypto exchange. But strip away the blockchains and this attack is a familiar shape: compromise a trusted person, reach a trusted system, and make it do something it was always allowed to do. Swap “signing system” for “Xero”, “your banking portal” or “the Microsoft 365 admin centre”, and the lessons translate directly.

  • Treat admin laptops as crown jewels. The people who can change production, payroll or banking need separate admin accounts, phishing-resistant MFA and, ideally, a dedicated device that is not used for email and browsing.
  • Be suspicious of hiring and “coding test” lures. Fake recruiters asking staff to install plugins, run test projects or join unusual video calls are now a standard attack technique, not a curiosity.
  • Limit what any one system can do. A service account or integration should have the narrowest permissions possible, with hard caps on payment size and volume.
  • Require a second approval for big or unusual actions. Dual approval on payments over a threshold is the small-business version of not letting one container drain a hot wallet.
  • Watch for “standing” access. The EIP-7702 delegation kept working for hours. In your world that is a forgotten mail-forwarding rule, an OAuth app nobody remembers approving, or a remote access tool left installed. Review them regularly.
  • Know who to call in the first hour. Tether and Circle saved billions because they moved within an hour. Your equivalent is having your bank’s fraud line, your IT provider and the ACSC’s ReportCyber details written down before you need them. Banks can sometimes recall a fraudulent transfer, but only if you are fast.

The Binance hack will be studied for years for its technical craft. The lesson, though, is old: attackers go where trust is concentrated. Make sure that in your business, no single laptop, account or system holds all of it.

Sources

  • Binance: official incident statements and updates (binance.com)
  • TRM Labs: analysis of the Binance hack, timeline and fund flows (trmlabs.com)
  • The Hacker News: reporting on the Binance breach (thehackernews.com)
  • Hackread: coverage of the incident and freezes (hackread.com)
  • Al Jazeera: market reaction and Binance response (aljazeera.com)
  • Jamf Threat Labs: research on North Korean fake job and interview lures (jamf.com)

This article reflects public information as of 1 November 2026. Figures and attribution may change as Binance and investigators publish more detail.

Worried about who can approve what in your business? Book a free consultation and Glacyn will review your privileged access, approval controls and incident response plan.