Back

02/11/2026

The Largest Crypto Heist Started Not on the Blockchain, but on a Single Laptop: Lessons from Binance

The Binance theft began on a compromised DevOps laptop, not with broken cryptography. What is confirmed, what is not, and five checks for your own systems.

On October 29, 2026, attackers drained Binance hot wallets on at least ten blockchains in a few hours. Binance puts the impact at about $6.3 billion, which makes it almost certainly the largest theft in crypto history. The cryptography was not what failed. According to Binance’s preliminary findings, the attack started on a single compromised laptop belonging to a DevOps engineer.

That makes this incident relevant far beyond crypto exchanges. Any organisation has people, devices and systems that can approve sensitive actions: production deployments, payments, signing, privileged cloud access. This article separates what is confirmed from what is still preliminary, explains why a compromised privileged endpoint can be worse than a stolen key, and lists five checks you can run on your own environment.

Key takeaways

  • Binance’s preliminary investigation points to a compromised DevOps engineer’s laptop as the entry point, and Binance says it has found no evidence of a wallet private key leak. Both findings are preliminary.
  • An attacker who controls the systems that request and approve signatures does not need to steal the keys.
  • The FBI and several blockchain analytics firms attribute the theft to the North Korean group TraderTraitor; Binance itself has not named an attacker.
  • The defences that matter most protect the people, endpoints and approval paths around the keys, not only the keys themselves.
  • The same pattern applies to cloud consoles, SSH, CI/CD pipelines and AI agents that can act in production.

What happened, and what is still preliminary

Blockchain analytics firm TRM Labs reports that funds began leaving Binance wallets at about 20:05 UTC on October 29, with most of the value moved within roughly 20 minutes. In its preliminary statement, reported by BleepingComputer, Binance said the incident may involve a compromised DevOps engineer’s laptop, through which the attacker reached a service container and submitted unauthorised withdrawal transactions. Binance suspended withdrawals, revoked the affected authorisation and began working with law enforcement.

Binance has since said its investigation “has uncovered additional points of breach.” Co-CEO Richard Teng said the attack was not the work of a single engineer’s permissions and, as quoted by Elliptic, that it “did not pass through our normal approval controls.” Binance has promised a detailed post-mortem, which had not been published at the time of writing (November 2).

PointStatus at the time of writing
Amount affectedAbout $6.3 billion by Binance’s estimate; analytics firms report $6.36 to $6.43 billion, depending on method and pricing.
Entry pointPreliminary: a compromised DevOps engineer’s laptop. Binance has since reported additional points of breach.
Private key leakBinance says it has found no evidence of a wallet private key leak. The investigation is ongoing.
Who did itThe FBI attributed the theft to North Korea’s TraderTraitor on October 31, in line with TRM Labs, Chainalysis and Elliptic. Binance has not named an attacker.
Frozen fundsNot final. Binance cites about $3 billion immobilised; Elliptic had verified about $2.85 billion frozen or seized on-chain as of November 1, mostly stablecoins.
Customer impactBinance says it will bear the loss and that user funds are safe. Withdrawals began reopening in phases on November 1.

Frozen is not the same as recovered. Stablecoin issuers such as Tether and Circle can freeze tokens they issue, but bitcoin, XRP and other native assets cannot be frozen that way, and much of the stolen value is still being laundered.

Why a compromised privileged endpoint can be worse than a stolen key

A stolen private key is a serious problem, but it is a single, well-understood one: rotate the key and the stolen copy loses most of its value. An attacker who controls a privileged engineer’s device is in a different position. They can use the systems that legitimately request signatures, call internal services with valid credentials, and send transactions that look like normal operations.

The on-chain evidence fits this picture. TRM Labs assessed that the pattern across many chains “points to a compromise of Binance’s hot wallet signing infrastructure,” meaning the attacker could get Binance’s own systems to sign transactions of the attacker’s choosing. On Ethereum, security firm Blockaid found that one hot wallet signed a batch of EIP-7702 authorisations that handed control of the wallet to the attacker’s contract. How those signatures were obtained is still unconfirmed, and we will cover that mechanism in a separate follow-up article.

This is not new. In the Bybit theft of February 2025, which the FBI also attributed to TraderTraitor, attackers compromised a developer machine at a wallet provider and manipulated the transaction that Bybit’s signers approved. In both cases, the keys did exactly what they were asked to do. The question was who was doing the asking.

Five defensive checks

1. Separate privileged devices from everyday work

The device used to approve production changes, sign transactions or administer infrastructure should not be the same device used for email, chat, browsing and installing developer tools. Use dedicated, hardened admin workstations or isolated virtual desktops, with no personal accounts and a short list of approved software. TraderTraitor has repeatedly used fake job offers and malicious coding tests to get onto developers’ machines; a separate device keeps that kind of compromise away from the approval path.

2. Require more than one person, and add time

No single person, device or service account should be able to move large amounts of value or change production on its own. Require approval from people on separate devices, set value limits per transaction and per time window, and add a delay (a timelock) for large or unusual operations. A delay of even a few minutes gives monitoring and people a chance to react.

Tip: Check that approvers see what they are actually approving. In the Bybit case, signers approved a transaction whose real content had been manipulated. The approval screen should show the exact action, destination and amount, generated independently of the requesting system.

3. Harden endpoints and watch them

Run EDR on every privileged device and make sure someone reviews its alerts around the clock. Keep systems patched, block unsigned or unapproved software, use phishing-resistant MFA such as hardware security keys, and limit how long admin sessions and tokens stay valid. Treat developer tooling, including packages, IDE extensions and AI coding assistants, as part of the attack surface.

4. Detect anomalies and be able to freeze quickly

The Binance funds moved within minutes. Define what normal looks like for your most sensitive operations, such as volumes, destinations, times of day and signing rates, and alert on deviations in real time. Prepare an emergency stop that can pause withdrawals, deployments or signing in seconds, decide in advance who may trigger it, and practise using it.

5. Audit who and what can invoke signing and production access

List every person, service account, container, pipeline and API key that can request a signature, approve a payment or change production. For each one, check whether it still needs that access, whether the access is scoped as narrowly as possible, and whether its use is logged somewhere the attacker cannot erase. Remove standing privileges where you can and use just-in-time access instead.

Lessons for enterprise cloud, SSH, CI/CD and AI operations

Most organisations do not run crypto hot wallets, but they all have something equivalent: credentials and systems that can act with authority.

  • Cloud: an administrator’s laptop with an active console session or cached CLI credentials is as valuable as the root account. Use short-lived credentials, device-bound sessions and approval workflows for destructive or high-impact actions.
  • SSH: long-lived keys sitting on engineers’ machines give an attacker direct server access. Prefer short-lived SSH certificates issued per session, and log every privileged session centrally.
  • CI/CD: pipelines often hold deployment and signing credentials. Protect pipeline definitions with review requirements, separate build and release credentials, and require approval for production releases.
  • AI-driven operations: AI agents that can run commands, open pull requests or call production APIs are new privileged identities. Give them their own narrowly scoped credentials, keep a human approval step for sensitive actions, and log what they do.

Tip: Run a tabletop exercise with one question: “If this engineer’s laptop were fully compromised tonight, what could the attacker do before anyone noticed?” The answer shows where your approval paths depend on a single device.

What to watch next

Binance’s post-mortem should confirm or revise the laptop theory, explain how the signatures were obtained and show which controls were bypassed. Until then, treat the root cause as preliminary. The defensive lessons above do not depend on the final details: whatever the exact path, the attacker reached the systems that could authorise sensitive actions.

How LOGIQ can help

LOGIQ helps organisations review privileged access across Linux servers, cloud environments and CI/CD pipelines, and design approval and monitoring controls that fit the way their teams actually work. If you want a second look at who and what can act with authority in your environment, contact us.

Sources