Binance DevOps Laptop Hack: $6.36 Billion in 20 Minutes

On October 29, 2026, a Binance DevOps laptop hack preceded about $6.36 billion in withdrawals across ten blockchains, most of it gone in roughly 20 minutes, according to TRM Labs. Binance says no wallet private key leaked. For anyone running a hot-wallet signer behind an engineer workstation, that path is the failure mode.

What left Binance in about 20 minutes?

TRM Labs calculated that about $6.36 billion left Binance wallets across ten blockchains on October 29, 2026, and that most of it moved in roughly 20 minutes. TRM said it traced each transfer on-chain. Binance put the damage at about $6.3 billion. SecurityWeek, in reporting by Eduard Kovacs, ran the headline “$6 Billion.”

The previous record was the Bybit theft in February 2025, at $1.5 billion. October’s figure is about 4.2 times that. Spread evenly over 20 minutes, $6.36 billion is an average outflow near $318 million a minute.

Real bursts are lumpier, but the average sets the window. A daily reconciliation, a morning queue review, or an alert tuned for a human trader all finish after the coins have moved.

Ten chains should bother a custodian more than the round number. One hot wallet on one chain can fail from one bad approval or one buggy contract call. Ten chains in the same short window, which TRM described as spanning different key types and signing schemes, means the failure sat above any single wallet.

Something in the withdrawal path could ask unlike signers for unlike assets and get valid signatures back.

Binance halted withdrawals and pledged to reimburse losses from company funds and from SAFU, the Secure Asset Fund for Users, an emergency reserve it set up in 2018 from a share of trading fees. That is a balance-sheet remedy. A confirmed on-chain transfer still stands.

Customers can be made whole on the exchange’s books while the stolen coins stay with whoever controls the destination wallets. Reimbursement and recovery are separate jobs, and only the first is something an exchange can promise on the day of the theft.

How did the Binance DevOps laptop hack reach withdrawal authority?

Binance says a compromised DevOps engineer’s laptop let an attacker into a service container that submitted unauthorized withdrawal transactions. It has not published a container name, a privilege list, or an intrusion timeline. The stated path is short: workstation, service container, withdrawals.

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.

In the same statement, Binance said: “We have found no evidence of any wallet private key leak.” The two claims fit together. Keys can stay inside the signer while the thief leaves with valid withdrawals, if the process allowed to request signatures is one the laptop can reach.

A service container that submits withdrawals is an authority, not a log viewer. Segmentation that keeps an engineer laptop out of a database shell does nothing useful if the supported path is an orchestrator session on the job that already holds the signing client.

On engagements we find this in admin and release tooling, not the public API. The signing endpoint is closed to the internet and open to CI and the break-glass group, because that is how hot-wallet top-ups and deploys get done. Once a laptop holds that session, it is a signer console with a human at the keyboard.

Binance has not said how the laptop was first compromised. A stolen session, a remote-support tool left running, a malicious package, and a phish that dropped a remote-access tool are different investigations. Once the session reaches the container, the blast radius is the same.

In the first hour, preserve the endpoint before rebuilding anything. Its identity-provider sessions, CI and CD credentials, container audit records, and the exact payloads presented for signing matter more than rotating key material that, per Binance, never left the signer.

A container security assessment should answer one question before any other: which containers can talk to the signer, and with which credentials.

Some facts that would shape the hunt are still missing. Binance has not named the signing software, the ten chains, or the attackers, and TRM’s trace as relayed by SecurityWeek does not list the networks by name.

Why did valid signatures show up on ten unlike chains?

TRM’s leading assessment is that the attacker could make Binance’s hot-wallet signing system sign transactions of its choosing across chains. That is a claim about control of the request path, and it is the explanation that covers all ten chains in about half an hour.

Preparation ran far longer than the drain. TRM said the attackers spent at least a day and a half getting ready, funded an operator wallet with a few small Tornado Cash withdrawals, and tested their malicious code on other wallets before going live.

A day and a half is enough to learn how nonces move, see which wallets will sign, and stage destinations. The 20-minute burst was the execution phase of a rehearsed job.

On Ethereum, the visible mechanism was EIP-7702, activated with the Pectra upgrade in May 2025. It lets a standard externally owned account delegate its behavior to contract code by signing an authorization. The delegation persists until something replaces or clears it. It does not expire when one transaction ends.

The authorization covers the delegate address, the chain ID, and the nonce, and a different account can submit it and pay the gas. Pre-signed authorizations can therefore sit off-chain until someone broadcasts them.

TRM said the attackers submitted a batch of 50 EIP-7702 permissions, all pre-signed by a Binance hot wallet, so that one would match the wallet’s transaction count at execution time. Pre-signing a run of nonces covers whatever legitimate transactions the wallet sends between preparation and the strike.

The wallet ended up delegated to a contract only the attackers could command, and they used it to empty the wallet. On its own, the Ethereum side looks like phishing: a signer approved a delegation. TRM said that theory fails on the other nine chains, where Binance wallets sent funds through ordinary, validly signed transactions.

These wallets use different chains, key types and signing schemes. All of them produced valid signatures for the attacker within about half an hour.

Hardware security modules and multiparty-computation custody stop key material from leaving as a file. They do not decide whether a requested payment is a real treasury movement. A compromised service in front of the module can still collect valid signatures when the signer checks the caller and skips intent.

Intent at that boundary means a destination allowlist, per-asset and per-chain limits, amount and velocity caps, simulation before signing, and a second approval whenever a request sets or calls contract code. A valid signature shows the signer was willing. It does not show that treasury meant to pay that address.

Who is named, and who is not?

TRM attributes the attack to TraderTraitor, which it calls North Korea’s elite hacking unit, with high confidence based on on-chain and off-chain intelligence. That is a vendor assessment. It is not a Binance statement, and it is not an FBI release about this incident.

Chainalysis CEO Jonathan Levin said his firm also believes TraderTraitor is the likely perpetrator. Chainalysis investigators found proceeds from the Bitget exploit the previous month mixed with funds taken from Binance. Investigator ZachXBT named the Lazarus Group as the probable attacker.

Those labels overlap without being identical. TraderTraitor is the name the FBI uses for a North Korean cluster focused on the crypto industry. Lazarus is the broader umbrella researchers apply to Pyongyang’s cyber units. “This cluster” and “this state program” are related claims, and a board brief should keep them apart.

The FBI attributed the February 2025 Bybit theft to TraderTraitor. For this incident, Binance has not publicly identified the hackers and says it is cooperating with law enforcement. As of SecurityWeek’s October 30 report, the stack is TRM at high confidence, Chainalysis aligned, ZachXBT on Lazarus, and the victim naming no one.

That is enough to drive hunting for this cluster’s habits. It is short of a criminal complaint.

TRM said the operation shares traits with Bybit and with the KelpDAO hack in April 2026: a mixer-funded operator wallet, preparation long before any money moved, and signatures collected in advance and fired all at once.

Laundering diverged. Where the Bybit thieves leaned on cross-chain bridges, this crew has mainly used large trades with market makers and lending platforms.

Bybit also set the precedent for valid signatures without exported keys. Safe’s investigation found that a compromised developer machine planted malicious JavaScript in the wallet interface, and Bybit’s signers approved a malicious transaction. The workstation was the entry. The signature was the exit. Binance’s account follows that shape even where the mechanics differ.

What froze by morning, and what could no issuer touch?

By 00:30 UTC on October 30, TRM tallied about $2.7 billion in frozen assets, including roughly 1.77 billion USDT frozen by Tether and about 825 million USDC frozen by Circle. Ripple and World Liberty Financial froze smaller amounts. Arbitrum’s Security Council used emergency powers to move about $30 million out of an attacker wallet.

Binance puts the frozen total at about $3 billion. The gap is two parties counting while events were still unfolding, and both can be honest numbers.

A freeze stops further transfers from the blocked address. It does not return the coins to Binance. That takes a separate issuer process, a court order, or a law-enforcement seizure. Native ETH and BTC have no issuer and no freeze function.

The attackers acted on that. To stay ahead of the issuers, they sold USDT for ETH at more than 10 percent below market price. TRM said they still hold more than 420,000 ETH and 18,270 BTC, about $2.4 billion that no issuer can freeze.

That discount is the price of moving from an asset Tether can freeze to one nobody can. For a defender, asset type belongs in the loss model. A hot wallet that pays unlimited USDT is painful and partly containable. A hot wallet that pays unlimited ETH or BTC is a bearer-asset loss at the first confirmation.

The reimbursement pledge sits beside that $2.4 billion. If customers are paid from SAFU and company capital, Binance absorbs the loss whether or not the ether comes back. Security teams should treat the pledge as a customer promise, not containment. Paying users does not evict an attacker who may still have a path to the signer.

What should you ask if a laptop can reach your signer?

If one engineer laptop can reach your signer, the effective holder of the production key is that workstation plus whatever service container it can open. Binance’s public path is laptop, service container, cross-chain signing, with no private-key leak found. Preparation took at least a day and a half, so staging was the window worth detecting, not only the drain.

TraderTraitor’s public record, from FBI and CISA advisories and industry reporting, centers on engineer laptops. Fake recruiters offer a role, a coding test, or a video interview, and the test repo or meeting installer is the payload. Trojanized npm packages run the same play through a package manager, on a machine that already has production access.

Binance has not said the October laptop was taken that way. The unit TRM named has used that approach against exchange staff before. A red team that skips the hiring lure and the dependency, and only scans the cluster, misses the door this playbook uses.

The custody failure we see in testing is narrow: the signer rejects a bad certificate and accepts a bad payment. The caller is a real service account. The payload is a well-formed withdrawal to an address treasury never approved, for an amount nobody signed off, on a chain added because a token listed that week.

Authentication succeeded. Business authorization never ran. An assumed breach assessment that starts from a DevOps laptop and stops at a shell is unfinished. The real question is whether that shell can make the signer emit a withdrawal the treasury desk would reject.

• Map every process that can request a signature: admin laptops, CI jobs, service containers, and break-glass accounts. One hop from an engineer workstation to a multi-chain signer is the finding.
• Enforce destination allowlists, asset and chain limits, velocity caps, and calldata simulation on the signer itself. A policy that lives only in the admin UI disappears when the attacker calls the client the UI uses.
• Require independent approval for contract interactions, including any delegation that sets code on a hot wallet. Watch signer request logs and the mempool. Pre-signed EIP-7702 authorizations are invisible on-chain until broadcast, and the wallet’s code after the funds move is a late signal.
• Reconcile every signature request to an internal withdrawal record: chain, asset, destination, amount, nonce, and calldata. On a mismatch, the signer refuses, even when the caller is authenticated.
• In the first response hour, isolate the signing service and preserve the endpoint, identity sessions, CI credentials, container audit logs, and signed payloads before anyone rebuilds the box.
• Test the human door in the same quarter. A social engineering assessment aimed at engineers, with a fake hiring process and a dependency to install, shows whether the laptop can be reached. Red team operations then carry that session to the container and stop at the signing boundary, before any real funds move.

What is still open?

Binance has not disclosed how the laptop was first compromised, has found no private-key leak, and has not named the attackers. TRM, Chainalysis, and ZachXBT have named North Korean actors at different levels of specificity, with TRM the most explicit and the most confident.

The ten chain names, the signing product, and a container audit are not public. Until they are, the durable fact is the path: a DevOps workstation, a service container, and a signer that produced valid multi-chain withdrawals within half an hour, after at least a day and a half of preparation.

FAQ

How much did the Binance hack steal in October 2026?

TRM Labs calculated about $6.36 billion siphoned from Binance wallets across ten blockchains on October 29, 2026. Binance estimated about $6.3 billion. That is roughly 4.2 times the previous record, the $1.5 billion Bybit theft in February 2025.

Was Binance hacked through a DevOps laptop?

Binance's initial investigation says a compromised DevOps engineer's laptop may have let an attacker access a service container and submit unauthorized withdrawal transactions. The company has not published how that laptop was first compromised.

Did Binance leak wallet private keys?

Binance said it found no evidence of any wallet private-key leak. TRM's leading explanation is that the attacker could make the hot-wallet signing system sign transactions of the attacker's choosing, which produces valid withdrawals without exporting keys.

Will Binance reimburse the October 2026 hack?

Binance halted withdrawals and pledged to reimburse all losses using company funds and its Secure Asset Fund for Users (SAFU). That pledge covers customers on Binance's books. It does not reverse the on-chain transfers.

Who is behind the Binance hack, TraderTraitor or Lazarus?

TRM attributes it to TraderTraitor, a North Korean state-sponsored unit, with high confidence, and Chainalysis agrees. ZachXBT named the Lazarus Group, the broader label for North Korean cyber units. Binance has not named the hackers and is working with law enforcement.

How much of the Binance theft was frozen?

TRM counted about $2.7 billion frozen by 00:30 UTC on October 30, mostly USDT frozen by Tether and USDC frozen by Circle. Binance estimates about $3 billion. The attackers still held over 420,000 ETH and 18,270 BTC, about $2.4 billion no issuer can freeze.

If a DevOps laptop in your environment can reach a signer, an assumed breach assessment is how you find out whether that session can authorize a withdrawal before a real operator tries the same path.