The Binance Hack: $6.3 Billion, No Stolen Keys, and One Compromised Laptop

A compromised engineer laptop routing withdrawal requests through a server to multiple blockchains while the private-key vault stays locked

On October 29, 2026, at 20:05 UTC, five Binance wallets on the XRP Ledger sent 233.46 million XRP to a single unknown address. Within the next four hours, Binance hot wallets on ten blockchains had been drained. On-chain analytics firm TRM Labs puts the total at about $6.36 billion at the time of each transfer. Binance's own estimate is about $6.3 billion. Either way, it is the largest cryptocurrency theft on record, roughly four times the $1.5 billion taken from Bybit in February 2025.

Binance suspended deposits and withdrawals, said user funds are safe, and committed to covering all losses from its SAFU emergency fund and company funds. By early on October 30, around $3 billion of the stolen assets had been frozen, most of it stablecoins.

Only five weeks ago we wrote about the Bitget hack, where $352 million left an exchange without a single private key being stolen. Binance's first findings tell the same story, at eighteen times the scale. Binance says it has found no evidence of any wallet private key leak. The vault stayed locked. Someone simply got the system that asks the vault for money to ask for all of it.

How the Drain Unfolded

The theft itself took minutes. The preparation took more than a day. TRM Labs reconstructed the sequence from on-chain data; all times are UTC.

Oct 28, morning — The attacker's operator wallet is funded with three small withdrawals from the Tornado Cash mixer
Oct 29, early — Attack code is deployed and tested on two of the attacker's own wallets
Oct 29, later — A final version is rehearsed on a third wallet; about four hours later it is installed on a Binance hot wallet
20:05–20:09 — Five Binance XRP Ledger wallets send 233.46M XRP to one attacker address
20:20 — The Bitcoin hot wallet sends 18,270 BTC; the Ethereum hot wallet submits a transaction carrying 50 authorizations
~20:22 — The Tron hot wallet sends 612.7M USDT and 46.4M TRX
~20:23 — The Ethereum hot wallet sends 167,464 ETH and 63 tokens, including 1.615B USDT
20:41–23:56 — Six further sweeps of the Ethereum hot wallet
21:01 — Tether freezes 971.1M USDT
21:04 — Circle freezes 823M USDC
23:05 — A second wave drains Binance wallets on Avalanche and Polygon
23:35 — Binance reports $2.54B verified frozen
Oct 30, 00:08 — Arbitrum's Security Council forces 8,426 ETH and 74.6M ARB out of the attacker's wallet

The split by chain shows how wide the reach was: about $3.79B from Ethereum, $1.47B in bitcoin, $628M from Tron, $296M in XRP, $96M in SOL, and smaller amounts across Arbitrum, Optimism, Base, Avalanche and Polygon. Hitting ten chains within minutes is not what a single phished signature looks like. It is what control of the withdrawal machinery looks like.

The Entry Point: A Laptop, Not a Key

Binance's first public explanation is short and specific: "Binance's initial investigation suggests that the security 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 added that it has found no evidence of a wallet private key leak.

Read that carefully, because it describes two separate failures.

The first is the endpoint. A DevOps engineer's laptop is not an ordinary office machine. It typically holds credentials, tokens or network paths into production infrastructure. Compromising that one device gave the attacker a foothold inside the environment that runs Binance's wallets.

The second is the trust boundary inside the withdrawal pipeline. From that foothold the attacker reached a service container that was allowed to submit withdrawals. Exchange wallet systems normally separate the signing layer, where keys live in HSMs or multi-party computation, from the services that decide what gets sent to it for signing. If the signing layer signs whatever a trusted internal service submits, the keys never need to leave the vault. The attacker only needs to become that trusted service.

TRM Labs reaches a compatible conclusion from the outside: the attacker was able to get transactions signed across ten chains, and compromise of Binance's hot wallet signing infrastructure is "the most likely explanation." An early theory that Ethereum authorizations had simply been phished does not explain the other nine chains.

What is still unconfirmed: Binance calls these findings initial. How the laptop was compromised, what the service container was permitted to do, and why no control stopped withdrawals of this size have not been published.

The EIP-7702 Detail Every Exchange Should Study

The most technically revealing part of the attack is on Ethereum. EIP-7702, introduced in Ethereum's Pectra upgrade in 2025, lets an ordinary wallet sign an "authorization" that delegates its behavior to smart contract code. It was designed for convenience features like batched transactions and sponsored gas.

At 20:20 UTC, Binance's Ethereum hot wallet submitted a transaction carrying 50 pre-signed authorizations at consecutive nonces, delegating the wallet to an attacker-controlled sweeper contract. About three minutes later the wallet sent out 167,464 ETH and 63 different tokens. A Binance smart account whose executor was that same hot wallet then lost another 823M USDC.

Three things follow from this.

The signatures existed before the theft. Fifty authorizations for future nonces means the attacker had the signing system produce them in advance, then fired them in one burst. TRM notes the same pattern of pre-obtained signatures in the Bybit and KelpDAO thefts.
The signing system signed something an exchange hot wallet should never need. A withdrawal wallet's job is to send assets to customers. Delegating the whole wallet to new contract code is a different kind of action entirely, and it was not blocked.
One compromised wallet unlocked others. Because the hot wallet was also the executor of a smart account, taking it over handed the attacker a second pool of funds.

The lesson is not that EIP-7702 is dangerous. It is that a signer which approves every transaction type the protocol allows, rather than only the few its job requires, turns every new protocol feature into a new way to be drained.

Who Did It, and Why DevOps Engineers Are the Target

TRM Labs attributes the attack with high confidence to TraderTraitor, a North Korean state hacking unit, citing on-chain and off-chain intelligence. Investigator ZachXBT points to the Lazarus Group, the wider North Korean umbrella. Binance has not confirmed attribution and says it is working with law enforcement. TRM lists the hallmarks it recognized: small Tornado Cash withdrawals to fund an operator wallet, staging well before the theft, and pre-obtained signatures executed in a burst. The FBI named the same unit for the Bybit theft.

The entry point Binance describes fits this group's documented playbook almost exactly. A joint FBI, CISA and Treasury advisory on TraderTraitor (AA22-108A) says its intrusions begin with spearphishing aimed at employees of cryptocurrency companies, often in system administration or "software development/IT operations (DevOps)". The lure is a recruitment message offering a high-paying job, which leads the target to download a trojanized application dressed up as a trading or price-prediction tool.

We don't yet know how the Binance engineer's laptop was compromised, and it would be wrong to claim it was a fake job offer. But the advisory explains why the laptop mattered: this group goes looking for exactly the people whose machines can reach the money. North Korean groups stole at least $2.02 billion in cryptocurrency in 2025, according to Chainalysis. This single incident is roughly three times that.

Bybit, Bitget, Binance: One Pattern

Three of the largest exchange thefts of the last two years used different techniques but broke the same thing.

Bybit, Feb 2025

Stolen: $1.5B
Way in: A Safe{Wallet} developer's machine
What was abused: The signing interface, which showed signers a fake transaction
Private keys stolen?: No

Bitget, Sep 2026

Stolen: $352M
Way in: A backend system in the wallet infrastructure (initial access unconfirmed)
What was abused: Transaction data spoofed into the authorization process
Private keys stolen?: No

Binance, Oct 2026

Stolen: ~$6.3B
Way in: A DevOps engineer's laptop (initial finding)
What was abused: A service container allowed to submit withdrawals
Private keys stolen?: No evidence

In every case the cryptography held. What failed was the layer that decides what gets signed, and the fact that the signing layer trusted it without an independent check. Each time, one compromised machine belonging to a trusted insider was enough to make the system authorize transfers no legitimate process had asked for.

What Worked: Stopping the Money, Not the Attacker

The most encouraging part of this incident happened after the breach. Tether froze 971.1M USDT at 21:01 UTC, 56 minutes after the first XRP left Binance. Circle froze 823M USDC three minutes later. Ripple, World Liberty Financial, Aave and Arbitrum's Security Council followed. Tether alone says it froze more than $1.57 billion. Binance reported $2.54 billion verified frozen by 23:35 UTC, and around $3 billion was frozen by the next morning.

Look at what was saved and what wasn't. Assets with an issuer or a governance body that could freeze them were largely recovered. Native assets with no one to call were not: TRM estimates the attacker still controls more than 420,000 ETH and 18,270 BTC, about $2.4 billion, and is already moving them through DeFi lending, OTC-style sales and peel chains.

No one stopped North Korea from getting in. What saved billions was disrupting the flow of money after it moved. The FBI sees the same thing in ordinary business fraud: its Recovery Asset Team froze 58% of the money it acted on in 2025, $679 million, because the reports reached it fast enough. The faster and closer to the transfer you can intervene, the more you keep.

What Would Have Stopped This

None of these controls are exotic. Each one breaks the chain at a different link, and any two together would likely have turned a $6.3 billion loss into a contained incident.

Treat engineer laptops with production reach as crown jewels. A machine that can reach the withdrawal pipeline deserves the same protection as the pipeline. That means dedicated privileged-access workstations used for nothing else: no email, no browsing, no personal apps, no "take-home coding test". Add 24/7 managed endpoint detection and response with a human analyst behind every alert, application control so only approved software runs, and hardware security keys rather than codes that can be phished or replayed.

Remove standing access to anything that can move money. No engineer, laptop or service should hold permanent rights to submit withdrawals. Access should be just-in-time, approved by a second person, short-lived and recorded. An attacker on a laptop then finds an expired door rather than an open one.

Enforce transaction policy at the signer, not upstream of it. The signing layer should check every request against rules it holds itself: which transaction types are allowed, which destinations, what amounts. A hot wallet that exists to pay customers should refuse to sign an EIP-7702 delegation, a contract upgrade or 50 authorizations for future nonces, whoever asks.

Require an independent second approval. A separate co-signer, run on different infrastructure by a different team, should rebuild each high-value transaction from the source of truth and approve it only if the two match. The attacker would then need to compromise two unrelated systems, not one.

Install a cross-chain circuit breaker. Large outflows from at least seven chains within about 20 minutes, far beyond any normal pattern, should pause withdrawals automatically. A velocity limit doesn't need to understand the exploit to stop its effect.

Size and lock the hot tier. Keep in hot wallets only what you can afford to lose, and put a time delay on large withdrawals so a human can review them before they leave. Cold storage exists precisely for this kind of internal compromise.

Getting Ahead of the Next One

Prevention covers the controls you build. Pre-emption means acting on what attackers are visibly preparing before they use it.

Hunt for the TraderTraitor playbook inside your own company. Unsolicited recruiter messages to engineers, take-home coding tests, unfamiliar trading tools and new package dependencies on machines with production access are all early signals. Brief the people who run your infrastructure specifically: they are the targets, not your customer support team.
Watch the blockchain for your own attack being rehearsed. The attacker funded a wallet through Tornado Cash a day early, then deployed and tested sweeper code on test wallets for hours. On-chain monitoring that flags newly deployed contracts built to interact with your wallet patterns can turn that staging window into a warning.
Agree on freeze playbooks before you need them. Tether, Circle, Ripple and Arbitrum's Security Council moved within an hour because channels existed. Pre-agree contacts, evidence formats and thresholds with the issuers and protocols that hold your assets, and drill them.
Red-team the withdrawal pipeline, not just the smart contracts. Assume an engineer's laptop is compromised and test what it can reach. Commission independent audits of the authorization logic that decides what gets signed, and publish the results.
Plan for the next protocol feature. Each upgrade, like EIP-7702, adds new transaction types. Review every one against your signing policy before it goes live on the chains you use, not after it is used against you.

Why This Isn't Just Crypto News

Strip away the blockchains and this is a familiar story. One person with access to the system that releases money had their laptop compromised. That system then trusted a request from inside, because it came from somewhere it was used to trusting.

The same shape exists in every finance department. An accounts payable clerk's laptop, an ERP account or a finance mailbox can all submit or approve payments. If an attacker controls one of them, every check that asks "did this come from an authorized place?" passes. Business email compromise works the same way, and it cost businesses $3.05 billion in reported losses to the FBI last year.

That's why CyberFence works on both ends of the chain:

The endpoint and the identity. Managed EDR and identity threat detection and response, with human analysts watching around the clock, are built to catch a compromised laptop or a hijacked login before it is used, and to cut it off in minutes when it is.
The moment money moves. Our Fraud & Payment Verification engine doesn't take the requesting system's word for it. Any new or changed payment is confirmed with the verified recipient through a separate channel the attacker doesn't control, before it is released. A compromised machine can submit a request. It can't make the real recipient say yes.

Binance had the money to cover a $6.3 billion loss. Most businesses would not survive losing a single large payment. The engine remains in private pilot as we test it against real cases before wider release.

Sources

This incident is less than a day old. Figures come from Binance's statements and on-chain analysis and will change as investigations continue. Binance describes its findings as initial; the way the laptop was compromised, the exact role of the service container and the attribution remain unconfirmed and should be treated as provisional until Binance publishes its full incident report.