The Binance hack started with a laptop, and that’s the part worth talking about

On 29 October 2026 Binance lost about $6.3 billion in roughly 20 minutes, the largest crypto theft on record. A few days have passed, withdrawals are open again, and Binance, the blockchain analytics firms and US authorities have shared enough to form a clear picture. Here is our view on it: what happened, how the attack worked, how the industry responded, and what we think large companies should take from it.

What happened

The attacker prepared for about a day and a half, then emptied Binance wallets on ten blockchains in one evening. Most of the money left in about 20 minutes, starting at 20:05 UTC on 29 October, according to TRM Labs' on-chain reconstruction. Valued at the moment each transfer happened, TRM puts the total at about $6.36 billion, roughly four times the $1.5 billion Bybit hack of February 2025.

When (UTC)	What happened
1 Nov, 06:00 onwards	Binance starts phased withdrawals, beginning with Bitcoin, and says about 95% of the impacted amount is covered (CoinDesk)
31 Oct	FBI formally attributes the theft to North Korea's TraderTraitor; Binance says it has restored backing for 90% of affected assets (CNBC)
30 Oct	Binance says the incident may have started with a compromised laptop, then says further points of breach were found (Dexerto, quoting Binance)
30 Oct, 00:08	Arbitrum's Security Council forces 8,426 ETH and 74.6 million ARB out of the attacker's wallet
29 Oct, 23:35	Binance reports $2.54 billion verified as frozen
29 Oct, 23:05	Second wave hits Binance wallets on Avalanche and Polygon
29 Oct, 22:01	Ripple freezes the wallet holding stolen RLUSD
29 Oct, 21:01 to 21:04	Tether freezes 971.1 million USDT, Circle freezes 823 million USDC
29 Oct, 20:23	Binance's main Ethereum hot wallet sends 167,464 ETH and 1.615 billion USDT to the attacker
29 Oct, 20:20	One transaction carries 50 pre-signed EIP-7702 authorizations; a Bitcoin hot wallet sends 18,270 BTC; Tron follows within two minutes
29 Oct, 20:05 to 20:09	First theft: five XRP Ledger wallets send 233.46 million XRP
29 Oct, daytime	Attack code deployed, tested on two wallets, rehearsed on a third; installed on a Binance hot wallet four hours after the rehearsal
28 Oct, morning	Attacker's operator wallet funded with three small Tornado Cash withdrawals

Unless linked otherwise, times and amounts come from TRM Labs.

How the attack worked

The attacker never needed Binance's private keys. It got Binance's own signing system to approve the transactions it wanted.

Binance's preliminary findings, shared with BleepingComputer, are that a DevOps engineer's compromised laptop gave the attacker access to a service container, and from there the attacker submitted unauthorized withdrawal transactions. Binance says it has found no evidence that any wallet private key leaked. Co-CEO Richard Teng added that the attacker did more than reuse one engineer's permissions, that it was a more complex process, and that the investigation has not blamed any individual. Binance has also said it found additional points of breach beyond the laptop.

Putting Binance's statements next to TRM's on-chain analysis, the chain looks like this:

• An engineer's laptop is compromised. How exactly has not been disclosed yet.
• From the laptop, the attacker reaches a service container inside Binance's environment.
• That container can submit withdrawal requests to Binance's hot wallet signing system.
• The signing system produces valid signatures for the attacker on ten different blockchains within about half an hour.

The Ethereum part

The most technical piece happened on Ethereum. Since the Pectra upgrade in May 2025, a feature called EIP-7702 lets an ordinary wallet hand control of its behaviour to a smart contract, just by signing an authorization. After that, the wallet runs the contract's code until it signs a new authorization.

The attacker got Binance's main Ethereum hot wallet to sign 50 of these authorizations in advance, each pointing to a "sweeper" contract that only takes orders from the attacker. Every wallet has a transaction counter (the nonce), and an authorization only works at one exact counter value. A busy exchange wallet's counter moves constantly as customers withdraw, so the attacker signed for 50 consecutive values. One of them was bound to match. At 20:20 UTC all 50 went out in a single transaction, and three minutes and 24 seconds later the wallet sent its whole balance to the attacker: 167,464 ETH and 63 tokens, including 1.615 billion USDT.

The delegation then stayed in place. As Binance's normal deposit sweeps refilled the hot wallet, the attacker swept it again at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC. Binance has since said it revoked the authorizations on the affected address.

Why TRM points to the signing system

On the other nine chains there was no clever contract trick. Binance wallets on Bitcoin, Tron, the XRP Ledger, Solana, Arbitrum, Optimism, Base, Avalanche and Polygon simply sent ordinary signed transfers to the attacker. These chains use different key types and signing schemes, so phishing one set of keys does not explain all of them. TRM's assessment is that the attacker could make Binance's hot wallet signing system sign transactions of its choosing. The batch of 50 pre-signed authorizations also suggests the access was limited in time, or that signatures had to be requested through a system.

That is the key technical point of the whole incident. Keys stored in hardware or split across parties are only as safe as the rules about what they agree to sign. Binance's keys stayed where they were, and the system allowed to use them did the work for the attacker.

The small things we trust by default

This is something our tech team sees all the time. No matter how well the infrastructure is designed, it ends up relying on small things you trust by default: someone's machine, a container, a service that approves requests because they look correct.

These pieces have a few things in common:

• They sit between teams and tools. A DevOps laptop belongs to an engineer, the container belongs to the platform team, the signing service belongs to the wallet team. Each team secures its own part, and the connections between them are where nobody is fully responsible.
• They are trusted because they are internal. A request coming from inside the environment, formatted correctly, from a service that normally sends such requests, looks legitimate. That is exactly what the attacker relied on.
• Locking them down completely slows everything down. Engineers need access to production to keep it running. Withdrawal services need to sign quickly or customers wait. Every extra check has a cost, so in practice these points are rarely as tight as the key storage itself.
• Automation keeps working for the attacker. In this case Binance's normal deposit sweeps kept refilling the compromised Ethereum hot wallet, and the attacker swept it six more times over the next three and a half hours. The system was doing its job, for the wrong person.

Attackers know this and take their time. Here, according to TRM, preparation started at least 36 hours before the theft. The attacker funded its operator wallet through Tornado Cash on the morning of 28 October, deployed and tested its code on two wallets early on 29 October, ran a final rehearsal on a third wallet later that day, and four hours after that installed the same code on a live Binance hot wallet. By the time the money moved, the hard work was already done.

TRM's own recommendations after the incident point at the same layer. Signing policies should reject EIP-7702 authorizations unless they are expected, a request for many authorizations across a range of nonces should be treated as a sign of compromise, and signing infrastructure and approval paths should be separated by chain and wallet tier. In this incident, one actor got valid signatures for wallets on ten chains within hours.

How the rest of the ecosystem reacted

What we found really worth noting is how fast everyone else moved. Within about four hours, stablecoin issuers and protocols had frozen roughly $2.7 billion of the stolen funds, according to TRM. Chainalysis puts the figure at about $2.8 billion and Binance at close to $3 billion, as later freezes came in.

Who	What they froze	When (UTC)
Tether	About 1.77 billion USDT across Ethereum, Tron, Avalanche and Polygon	First 971.1 million at 21:01, 37 minutes after the main sweep
Circle	About 825 million USDC, in coordination with law enforcement	21:04
Ripple	40.5 million RLUSD, plus the RLUSD in the compromised Binance wallet	22:01
World Liberty Financial	27.8 million USD1	22:10
Arbitrum Security Council	8,426 ETH and 74.6 million ARB, about $30 million	00:08 on 30 October

DeFi protocols moved too. When the attacker supplied 60 million stolen USDT to Aave and borrowed about 19,760 ETH against it, Aave Labs, LlamaRisk, TokenLogic and Certora formed a joint response group within 10 minutes of the first reports (Bitcoin.com News). Aave's guardians then froze 175 reserves on Aave V3 across 16 networks and 117 reserves on V4 (Blockchain Reporter). The attacker's position stayed over-collateralized, so Aave reported no bad debt. Solana lender Kamino paused borrowing in one market as a precaution, even though it was not affected (Trending Topics).

The freezes also changed the attacker's behaviour. To get out of freezable stablecoins in time, it sold about 325 million USDT to market makers for ETH at a discount of more than 10%, according to TRM. Speed of response directly translated into money the attacker either lost or could not touch.

Competitors, issuers and protocols all moved quickly to minimize the damage, and that is a big part of why Binance has been able to say it already covered about 95% of the impacted amount, using its SAFU emergency fund and company funds (CoinDesk). When withdrawals reopened on 1 November, Binance processed about $4.6 billion in withdrawals and $1 billion in deposits within the first hours (CNN via Yahoo Finance), a real test of liquidity that the exchange passed.

It is fair to say that these freeze powers are a form of central control, and some in the industry are uncomfortable with that. In this case they worked as an emergency brake, and the debate about who should hold them is a separate one worth having.

The attacker still holds about $2.4 billion that no issuer can freeze, mostly ETH and the 18,270 BTC, and TRM expects it to move through bridges, swap services and OTC brokers next. That part of the story is far from over.

Who was behind it

The FBI formally attributed the theft to North Korea in an alert dated 31 October, naming the activity "TraderTraitor". TRM Labs and Chainalysis had reached the same conclusion a day earlier, and investigator ZachXBT reported that funds from this hack ended up at the same address as funds from September's Bitget theft after passing through THORChain (The Crypto Times). The FBI, the US Secret Service and IRS Criminal Investigation are asking node operators, swap services, DeFi services and other virtual asset providers to block transactions linked to the attacker's addresses.

TraderTraitor, also tracked as Jade Sleet, UNC4899 and Slow Pisces, is not new to this. Its recent record, as reported by BleepingComputer:

Date	Target	Amount
October 2026	Binance	About $6.36 billion
September 2026	Bitget	$387.5 million
April 2026	Drift	$280 million
February 2025	Bybit	$1.5 billion
May 2024	DMM Bitcoin	$308 million

What stands out across these cases is where the attacks start. The group's usual method is social engineering, and it often targets several employees of the same company at once (Free Press Journal). The Hacker News notes the same pattern: recruitment-themed lures used to get victims to run malicious code.

The DMM Bitcoin case shows how this plays out in practice. According to the FBI, a North Korean actor posing as a LinkedIn recruiter contacted an employee of Ginco, a wallet software company with access to DMM's wallet systems, and sent a malicious Python script disguised as a pre-employment test. The employee ran it, the attackers later used stolen session cookies to impersonate them, and eventually manipulated a legitimate transaction request to take 4,502.9 BTC (SecurityWeek). DMM Bitcoin later shut down. Bybit, in 2025, came through a supply chain attack on Safe{Wallet}, the multisig tool it used.

Binance has not yet said how the engineer's laptop was compromised, and we should not assume it was the same playbook. But the pattern is clear: this group goes after people and the tools around them, and lets the company's own systems do the rest.

Why this is not a crypto problem

A lot of the reaction online has been "this is why crypto is unsafe." We see it a bit differently. Every blockchain involved did exactly what it was built to do. It processed transactions with valid signatures. The weak point was inside Binance: a laptop, a container and the processes around them.

Traditional finance has had the same kind of breach, and from the same attacker family. In February 2016, the North Korean Lazarus Group used Bangladesh Bank's own SWIFT terminals to send 35 payment orders worth $951 million from the bank's account at the Federal Reserve Bank of New York. Most were blocked, partly because of a spelling mistake in one of them, but $81 million got through to the Philippines and was laundered through casinos (The Daily Star). The way in looks familiar too. The attackers had been inside the bank's systems for about a year, starting with job application emails sent to employees in January 2015, and they disabled the printer that kept a paper record of every transfer days before the heist.

Nobody concluded that bank transfers were the problem. The conclusion was that the bank's operations had to improve, and SWIFT introduced a mandatory customer security programme for its members afterwards (American Express, summarising SWIFT and Reuters).

The comparison also shows where crypto infrastructure actually helped. In Bangladesh, only about $15 million of the $81 million had been recovered two years later (PYMNTS). In the Binance case, roughly $2.7 billion was frozen within about four hours. That was possible because every transfer was visible on a public ledger in real time, so Tether, Circle, Ripple and the others could see exactly where the money went and act on it. If anything, the underlying principle of the ledger is what let the industry react so quickly, tracking and freezing billions of dollars.

What large companies should take from this

For large companies especially, the lesson is that security has to cover operations, training and execution just as seriously as the infrastructure itself. Groups like TraderTraitor usually start with people, and they often target several employees of the same company at once. The bigger the company, the more of these small trusted points there are, and the more important it is that the systems in place are designed to stop this from happening.

Here is how we think about it in practice.

Operations

• Treat engineer devices as part of production. A laptop that can reach production is production. Managed devices, hardware-backed authentication and short-lived sessions make a stolen session cookie or a compromised machine much less useful.
• Give access only when it is needed. Standing access to sensitive containers and services should be replaced with just-in-time access that expires, is logged, and needs a second person for the most sensitive systems.
• Check what gets signed, outside the signer. The signing system should not be the only thing deciding whether a transaction is allowed. Limits on amounts, destinations and transaction types should be enforced by an independent policy layer, so a compromised service cannot simply ask for a signature and get one.
• Separate by chain and wallet tier. TRM's point stands: one actor should never be able to get valid signatures for ten chains from one place.
• Alert on unusual signing, and be able to stop it. Unexpected EIP-7702 delegations, requests for many signatures across a range of nonces, or a hot wallet emptying in one transaction should trigger alerts and an automatic pause. Automation like deposit sweeps should stop too, so it does not keep feeding a compromised wallet.

Training

• Train the people attackers actually target. Engineers with production access, DevOps and wallet operations staff are the most valuable targets. Their training should cover the tricks used against them: fake recruiters, take-home coding tests, fake meeting links and malicious packages.
• Make it role-based and continuous. One annual course for everyone is not enough. A DevOps engineer and a customer support agent face different threats.
• Include leadership. Senior people are targeted too, and they set the tone for whether security rules are followed or quietly bypassed.

Execution

• Make someone own the gaps. Every piece that sits between teams, like a shared container or an internal service, needs a named owner responsible for its security.
• Have the incident plan ready before you need it. Binance and its partners froze billions in hours because the contacts, procedures and relationships with issuers, analytics firms and law enforcement already existed. Smaller companies should build those relationships too.
• Practise. Run drills for key compromise, signer compromise and mass withdrawal scenarios, and test that revocations and pauses actually work.
• Publish and learn. Binance has promised a full post-mortem. Sharing what went wrong is how the rest of the industry gets better.

The regulatory side in the EU

In the EU this is no longer optional. Since the MiCA transitional period ended on 1 July 2026, authorised crypto-asset service providers count as regulated financial entities and fall under DORA, the Digital Operational Resilience Act (Hacken). Article 13(6) of DORA requires compulsory ICT security awareness programmes and digital operational resilience training for all employees and senior management, at a level that matches each role, and where appropriate for ICT third-party providers as well (Advisera). In other words, the operations and training layer we describe above is exactly what regulators now expect.

Our take

The Binance hack will be remembered as the largest crypto theft in history. For us, it is above all an operational security failure at one company. The ledgers worked, the cryptography held, and the ecosystem froze billions within hours. What failed was a laptop, a container and the trust placed in them.

The moral here is that cybersecurity covers more than updated and well-maintained systems. It also means internal policy, training and rules that make the operations as safe as the infrastructure itself.

We will update this piece once Binance publishes its full post-mortem.

Sources

• TRM Labs: North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History
• FBI: North Korea Responsible for $6 Billion+ Binance Attack
• BleepingComputer: Binance links $6.3 billion crypto theft to compromised DevOps laptop
• BleepingComputer: FBI links $6.3 billion Binance crypto heist to North Korean hackers
• Dexerto: Binance responds to $6 billion crypto hack after claims a single laptop was to blame
• 21shares: Binance hack, the largest robbery in financial history
• CoinDesk: Binance opens crypto withdrawals in phases starting with bitcoin
• CNBC: Binance resumes withdrawals, says 90% of stolen user assets are covered
• CNN via Yahoo Finance: Binance withdrawals resume following $6 billion hack
• Bitcoin.com News: Aave freezes lending across 16 networks
• Blockchain Reporter: Aave freezes V3 and V4 markets
• Trending Topics: Binance hackers flee into DeFi as Tether and Circle freeze billions
• The Hacker News: FBI links North Korea's TraderTraitor to record Binance heist
• Free Press Journal: Who is TraderTraitor?
• The Crypto Times: on ZachXBT's Bitget link
• SecurityWeek: FBI blames North Korea for $308M DMM Bitcoin hack
• The Daily Star: When North Korean hackers almost pulled off a billion-dollar heist from Bangladesh Bank
• PYMNTS: Anatomy of a bank heist
• American Express: The story of the Bangladeshi money transfer heist
• Hacken: DORA training for crypto businesses
• Advisera: DORA training and awareness requirements