Binance says a DevOps laptop may be behind its $6.3 billion theft; TRM and Chainalysis blame North Korea

From $5.8 billion to $6.36 billion: what changed, and what Binance has not said

On the evening of 29 October 2026 BleepingComputer reported that Binance was investigating a possible theft of up to $5.8 billion. By the morning of 30 October, SecurityWeek and Help Net Security reported about $6.3 billion, and TRM Labs put its own count at about $6.36 billion. The gap between the first figure and TRM's is about $0.58 billion, or 10 per cent (derived: 6.36 minus 5.78, divided by 5.78). The two numbers are different kinds of number. The $5.8 billion figure was Arkham Intelligence's value of what 55 tracked addresses held, and BleepingComputer said at the time that it was "rather than a confirmed amount stolen from Binance". TRM's figure is the sum of every transfer from Binance attributed wallets to attacker addresses on ten blockchains, each valued at the price of the asset when it moved. At today's prices TRM says the same assets are worth about $6.23 billion.

No text read for this briefing says why the figure rose. One tempting explanation does not fit the numbers: TRM says a second wave at 23:05 UTC reached Binance wallets on Avalanche and Polygon, but those two chains total at most about $38 million on TRM's figures (derived: 28 plus 10, and part of the Avalanche figure was moved in the first window), far short of $580 million. The likeliest reading is measurement, a snapshot of the holdings of addresses known at the time against a sum of every transfer found later (this briefing's inference, not a statement by anyone). The figure Binance itself has given, about $6.3 billion, is reported by SecurityWeek and is not independently checkable here.

That is the first thing the record does not establish: a single agreed loss. The second is more important. Binance's account of how the attacker got in is one conditional sentence, and it names no actor. The attribution to North Korea comes from two blockchain analysis firms and an independent analyst, not from Binance and not from any government statement found for this theft. The article that follows separates what Binance says, what the chain shows, and what rests only on analysts' reading.

This briefing was read from 09:49 UTC to 10:05 UTC on Friday 30 October 2026. The on chain account and TRM's attribution are from TRM Labs' post, dated 29 October with figures as of 00:30 UTC on 30 October. Chainalysis's assessment is from its own blog post of 30 October. Binance's words are the ones quoted in SecurityWeek, Help Net Security and BleepingComputer; the first two quote the same sentence word for word; BleepingComputer's earlier 29 October report is the source for the first figure. Binance's own announcement page, which Help Net Security links, answered an automated request with an empty response, and Binance's posts on X are closed to automated readers by that site's robots file, so neither could be read directly. Binance is the victim and the source of its own account, and it has an interest in reassuring customers. TRM and Chainalysis sell blockchain intelligence products, and a public attribution to a state actor is also a showcase for them. None of that makes them wrong; it is a reason to read their evidence rather than their confidence.

Stated and not stated: one table for the whole incident

The DevOps laptop: a conditional, not a finding

Binance's statement, as SecurityWeek and Help Net Security quote it, reads in full:

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.

Three hedges sit in that one sentence: the investigation is "initial", it "suggests", and the incident "may involve" the laptop. BleepingComputer's headline says Binance "links" the theft to the laptop and its opening sentence says Binance "has linked" it. SecurityWeek's standfirst is more careful, "possibly compromised". The quoted sentence supports the careful version.

One of Binance's two chief executives added, as BleepingComputer quotes him, that "the attacker did not simply use one engineer's permissions" and that the event was not a single one click action but "a more complex attack process". Binance also said it had "uncovered additional points of breach" and was still gathering facts, and told Help Net Security that the incident "stems from multiple factors". Read together, these lines say the laptop may be one entry point among several and that Binance has not told the public what the others are.

The friendly names here deserve a second look. "No evidence of any wallet private key leak" reads as reassurance, but what it excludes is one way of stealing. TRM reports that wallets on different chains, with different key types and signing schemes, all produced valid signatures for the attacker within about half an hour, and judges the most likely explanation to be that the attacker could make Binance's hot wallet signing system sign transactions of its choosing. On that reading no key needed to leak: a signing service that signs what it is asked is as useful to a thief as the key behind it. That is TRM's inference and this briefing's reading of it, not a Binance finding. "User funds are safe" is a promise to cover losses, and the SAFU fund is a reserve; neither says who or what could cause the signing system to sign. A promised Proof of Reserves is a statement about balances after remediation, not about the control that failed. And "DevOps engineer's laptop" is a label that points at one person's machine while one of Binance's own chief executives says it was not one engineer's permissions.

Zoom

What the chain shows: preparation, a 20 minute sweep, and 50 signatures in advance

The on chain record is TRM's, and Chainalysis's account agrees with it where they overlap. TRM says preparation began at least 36 hours before the theft: an operator wallet received three small Tornado Cash withdrawals from the morning of 28 October, code was tested on two wallets and rehearsed on a third early on 29 October, and four hours after the rehearsal the same code was installed on a Binance hot wallet. Between 20:05 and 20:09 UTC five Binance XRP Ledger wallets sent 233.46 million XRP to one address. At 20:20 UTC a Bitcoin hot wallet sent 18,270 BTC and, on Ethereum, one transaction carried 50 signed authorizations.

The Ethereum mechanism is EIP 7702, which lets an ordinary wallet hand its behaviour to a smart contract by signing an authorization. Each authorization carries a transaction count, called a nonce, and works only at the count the wallet has reached when it executes. Binance's hot wallet processes a steady flow of withdrawals, so its count keeps moving. By preparing signatures for 50 consecutive counts the attacker made sure one would match, and one did. The wallet was then pointed at a contract that only the attacker could instruct. Three minutes 24 seconds later (20:23:24, derived from 20:20 plus 3:24) the attacker told it to send its whole balance: 167,464 ETH and 63 tokens including 1.615 billion USDT. The delegation stayed in place and was used again at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC.

The detail that matters for the laptop claim is what happened elsewhere. TRM says early indicators on Ethereum suggested the authorizations had been phished, an explanation that covers Ethereum and leaves the rest unexplained. Wallets on the XRP Ledger, Arbitrum, Avalanche, Optimism, Base, Bitcoin, Tron and Solana, and a second Ethereum hot wallet, sent funds through ordinary signed transfers with no delegation. TRM adds that the batch of 50 presigned authorizations suggests the access may have been limited in time, or that signatures had to be requested through a system, and that Binance has yet to publish a root cause.

Zoom

Zoom

How much, where, and what frozen means

TRM and Chainalysis call this the largest crypto theft on record; Help Net Security says it "could be". TRM sets it against the $1.5 billion Bybit theft of February 2025: 6.36 divided by 1.5 is about 4.2 times (derived), which TRM rounds to four. The comparison depends on valuing each theft at the price when it moved, which is TRM's method.

"Frozen" is the next friendly word. Nobody read for this briefing says frozen funds have been returned to Binance. A freeze is an issuer or a network council making tokens at an address unspendable. It worked only on assets that have an issuer or a council, and the figures differ by source and by hour.

The attacker raced the freezes. TRM says about 325 million USDT was sold to market makers for about 122,300 ETH, a discount of more than 10 per cent to the market price, and that a second wallet borrowed about 19,760 ETH on Aave against 60 million USDT. Chainalysis puts the same sale at $325 million of stablecoins into $285 million of ETH, which is a 12 per cent discount (derived: 285 divided by 325). TRM says the attacker still holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer's reach, and expects bridges, swap services and over the counter brokers to be next.

Do not subtract. About 2.7 billion frozen is 42 per cent of 6.36 billion, and 2.4 billion beyond reach is 38 per cent (both derived), but the figures use different valuation bases and count funds that moved between categories, so they cannot be netted to a loss after recovery. Binance says it will cover all losses regardless.

North Korea: who says it, and what the evidence is

Binance's own account names no actor: one of its chief executives says the investigation "has not attributed responsibility to any individual" and Binance says it is working with law enforcement to confirm the identity of those responsible. No FBI or other government statement on this theft turned up in the sources read. The only government attribution on the record is the FBI's from February 2025, when it said North Korea was responsible for the $1.5 billion Bybit theft and that it "refers to this specific North Korean malicious cyber activity as" TraderTraitor (FBI public service announcement, 26 February 2025). The label belongs to that earlier attribution; whether this theft shares an operator is what the analysts are asserting.

BleepingComputer writes that Chainalysis confirmed TRM's finding "with a high degree of confidence". The Chainalysis post read for this briefing says its investigators "assess" the attribution and gives no confidence level in those words, and its chief executive's post, as Help Net Security quotes it, says "likely". The confidence in the headline coverage is a little stronger than in the primary text.

The chain of evidence is worth reading link by link. TRM's method overlaps (a mixer funded wallet, staging, presigned signatures) describe how an operation was run, and a technique seen in one theft can be copied. Chainalysis's strongest link, commingling with the Bitget proceeds, is only as firm as the Bitget attribution. Chainalysis's Bitget post calls that theft attributed to DPRK actors, while this site's Bitget briefing recorded in September that TRM said it had "not definitively attributed" that theft and that another actor "remains technically possible". Neither point shows the analysts are wrong. They show that the Binance attribution leans on money handling and method resemblance, and none of the texts read links the laptop, the container or the signing system to a named actor.

Zoom

Technical details

TRM's post prints no wallet addresses, transaction hashes or contract addresses in its text, and Chainalysis's post prints none either, so there are no indicators to copy here and none are invented. What the primaries do print is the statement Binance is quoted as making, TRM's timeline sentences, and TRM's advice for defenders. The EIP text below is the Ethereum specification TRM's mechanism rests on. Blocks are copied exactly and attributed in their captions.

Binance's statement, with the sentence on cover for losses, as quoted in the press. This is a secondary quotation because Binance's own page could not be read; SecurityWeek and Help Net Security give the same wording.

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.
We have found no evidence of any wallet private key leak.
Binance will cover all losses from the SAFU fund and the company's funds. User funds are safe.

TRM's own sentences on the Ethereum hot wallet, in order. Defenders should read the middle lines as the signature of the technique: one transaction carrying many authorizations, the same wallet delegated to a contract only the attacker could instruct, then repeated sweeps of new funds.

At 20:20 UTC, the operator submitted a single transaction containing 50 authorizations.
Each was signed by the Binance hot wallet, and each pointed it to a sweeper contract that accepts instructions only from the operator.
By preparing signatures for 50 consecutive counts, the attacker guaranteed that one would still be valid when the transaction executed.
Three minutes and 24 seconds after the delegation, the operator instructed the Binance hot wallet to send its entire balance to an attacker-controlled address.
The delegation remained in place.
As new funds reached the Binance hot wallet, the operator swept them again at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC.

What a delegation looks like on the chain, from the EIP itself. This lets a defender recognise it: the account's code is the prefix 0xef0100 followed by the address of the contract it delegates to (this briefing's reading of the EIP text). The nonce line is why TRM says a batch of authorizations for consecutive counts was needed.

For each tuple, a delegation indicator (0xef0100 || address) is written to the authorizing account's code.
Verify the nonce of authority is equal to nonce.
Set the code of authority to be 0xef0100 || address. This is a delegation indicator.

TRM's advice to treasury and signing teams, as printed. This is the vendor's advice, and TRM sells products that screen addresses, so weigh it as such; the monitoring points are consistent with how the technique works.

Treasury teams should monitor Ethereum-compatible wallets for EIP-7702 delegations, which appear as code at an address that should have none.
Any such delegation on a treasury wallet should trigger an immediate alert.
Teams should keep a tested, pre-approved method for signing a revocation.
Signing policies should reject EIP-7702 authorizations unless they are expected.
A request for many authorizations across a range of transaction counts should be treated as an indicator of compromise.
Signing infrastructure and approval paths should be separated by chain and wallet tier.

What exchanges, custodians and treasury teams should do, in order

TRM's advice is marked as TRM's. The other items are this site's recommendations, drawn from the shape of the incident rather than from any Binance post mortem, which does not yet exist. The first fact to design against is speed: TRM times the first freeze at 21:01, about 56 minutes after the sweep began (derived: 21:01 minus 20:05), by which time most of the funds had moved.

The question that exposes the gap

If one engineer's laptop can reach a service that makes your hot wallets sign, which control stops it, and when did anyone last test that control with the laptop assumed hostile? Binance has said what it believes may have happened. It has not said which control failed. Until it does, every exchange and custodian should ask the question of its own estate rather than wait for the post mortem.

Key facts