Binance Stopped Withdrawals. The Theft Wasn’t Using Them.

What Binance reported

Binance describes a campaign that began months before the theft. The FBI attributes it to the Democratic People’s Republic of Korea.[1]

As of the report, about USD 2.85 billion had been frozen or intercepted, Binance said it would absorb the loss rather than pass it to users, and 98% of the affected token assets had been replenished by 31 October.[1]

Two paths, not one

The June episode and the September–October campaign are best recorded as two attack paths. The June compromise was detected and contained: the device was replaced and the credentials rotated. What survived it was information, A’s role and team, and that information later decided whose computers mattered. A Data Risk Event links the two paths, not a step.

Binance also reports 57 suspected DPRK-linked cases that its security team detected and prevented during 2026. They belong in neither path. A cluster assignment asserts that the step succeeded; a blocked attempt is evidence about controls, not a step.

#9 ||[human][@Attacker⇒@SearchEngine→@Binance]|| → #7 + [DRE: C]      // Path A, June 2026

Binance calls this step a supply chain attack. Under TLCTC it is not, at least not on what the report says. Since v2.6, a #10 step requires that the trust artifact, or the third party issuing it, was subverted before the target accepted it (R-SUPPLY).[3] A “tampered Homebrew installation” found through a search engine is a counterfeit from an impostor source, not Homebrew’s own distribution delivering something bad. The engineer was deceived about where the file came from: #9. Running the installer executes foreign code: #7. If forensics later show that Homebrew’s official channel served the tampered file, the step becomes #10, and the record changes with the evidence.

The path to the signing service

The theft itself is a twelve-step path, two of whose steps run in parallel. Written out with the intervals the report supports:

#9 ||[human][@Attacker⇒@JobPlatform⇒@ChatApp→@Binance]||
 →[Δt=?]          #7
 →[Δt=?]          #7
 →[Δt=~weeks]     #1 [conf=low]
 →[Δt=?]          (#7 + #7) + [DRE: C]
 →[Δt~9d]         #4
 →[Δt<2h41m]      #1
 →                #7
 →[Δt=9m..2h50m]  #1 [conf=low] + [DRE: If]
 →[Δt=?]          #1 + [DRE: If]
 →[Δt<3h47m]      #1 + [DRE: If]

Why If, not C. Every unauthorised transfer is a correct transaction. The amounts, addresses and signatures are all valid, and the ledger records exactly what happened. What fails is provenance: each transaction carries Binance’s authority, and Binance’s authorised process never issued it. That is the misattributed state of the v2.7 DRE tree — the record claims an origin it does not have, while its content is accurate.[3] It is not Ii as well: the balances that remain are exactly what the ledger says they are. Calling them “wrong” because the transfers were unauthorised would split the code by how the state came about, which the DRE stopping rule forbids. The controls the dictionary names for it are the right ones here too: segregation of duties, provenance logging, behavioural monitoring.

If the shape looks familiar, it should. Bybit, February 2025: a developer approached with a trojanized project, malware on the workstation, stolen development credentials, abuse of a deployment function, and a contract that redirected the funds.[5] The specific techniques differ. The causes, step by step, are the same, which is why the same controls apply.

Three labels that do not survive classification

Binance writes that this “was not a single isolated breach or a simple phishing incident.” That is true. It does not follow that it needs new categories. Three of the report’s labels dissolve once each step is asked what it exploited.

Counted over both paths, the incident is fourteen steps: two #9, six #7, one #4, five #1. A sophisticated campaign, built from four generic vulnerabilities that every organisation already has to control.

Where the business events begin

Clusters stop at the data. What happens to the business is recorded on the consequence side, as Business Risk Events, each reached from a DRE or from an earlier BRE.[3] Placed with the TLCTC+ catalogue codes, at the step whose DRE triggers them, and only where the report gives evidence:[4]

… → #1 [conf=low] + [DRE: If]
       + [BRE: BRE-FIN.23 → BRE-ORG.14 → (BRE-SVC.11 + BRE-ORG.16 + BRE-REP.13)]
  → #1 + [DRE: If] + [BRE: BRE-ENT.17]
  → #1 + [DRE: If] + [BRE: BRE-FIN.23]
       + [Impact: IMPACT-FIN.12 Direct Fraud Loss = USD 6.34bn gross]

Two steps carry the same DRE and lead to different business events. The signing step moves money directly: BRE-FIN.23. The delegation step moves no money at all. It grants authority, in Binance’s name, to someone else: BRE-ENT.17. That second event is the one Binance’s containment could not reach.

The edge containment had to cut

A consequence chain breaks only at a causal edge, and each causal edge has an interval, Δt, that bounds the window for detection and response.[3] Read the Binance chain edge by edge and the windows are very uneven.

From [DRE: If] to BRE-FIN.23, the window is on-chain finality: seconds. Once the signing service has signed, nothing on the response side can stop the transfer. That edge can only be prevented, not detected. The real detection windows were earlier: about nine days between gaining control of A’s and C’s machines and the use of A’s token, and between nine minutes and 2h50m between the malicious script and the first transfer.

From BRE-ENT.17 to the later BRE-FIN.23, the window was hours. This is the edge where response could still have acted, and Binance’s report explains why it largely did not. Suspending withdrawals stops the withdrawal process. The delegation did not run through the withdrawal process; it lived on-chain, in the hot wallet’s own account code, which is where EIP-7702 places a delegation.[2] Removing it required a transaction signed by the wallet’s key, and the wallet was an MPC wallet: there was no single key to sign with quickly. Binance built and ran a special procedure. It cleared the delegation at 00:10, fourteen minutes after the last transfer had finalised.

Expected, but not yet in the record

A record should hold only what the evidence shows. Some business events will follow almost certainly, but the report does not mention them, so they stay out of the path and are listed here as expected:

One event that might be expected is not on the list. Binance says users will bear no loss, and topping up its own reserves is not compensation paid to customers, so there is no BRE-CUS.14.

Reputation is not on the list either, because it is not a single event. It works as an amplifier: one incident dents trust and visible repair restores it; repeated incidents make the loss of trust final, and only then do customers leave. For Binance this is the second hot-wallet theft, after 7,000 BTC in May 2019.[6] Replenishing 98% of the assets within two days and pointing to the Proof of Reserves page is exactly that visible repair. Whether it holds depends on whether there is a third.

One lever per step

The use of classifying each step is that each cluster has its own control lever and its own owner. Binance’s remediation list — rebuilt systems, replaced devices, revoked tokens, AI-based anomaly detection — is mostly response and detection. The prevention levers sit at the steps:

The signing-service row carries the most weight. Every path to the signing service needs the service’s cooperation in the end. A signing policy that covers every request, not only the requests that arrive through the expected door, closes the incident at the step where the money would have moved, whatever happened upstream.

The decisive #1 belongs to the business

Look at the owner column again. Every lever up to the deployment belongs to IT. The last three steps of the path — signing, delegating, draining — are #1 in a functional domain: the function abused is not a server or an operating system but a business function, the release of customer assets. Who may sign what, to which destination, in what volume and through which process is a custody and treasury decision. Its control regime — signing policy, limits, four-eyes release, reconciliation — is typically owned by the business, not by IT.

The detection rules for that domain are of a different kind as well. They are not malware signatures or login anomalies; they are financial and transactional rules:

• Provenance reconciliation: every signed transaction matched against a withdrawal ticket from the authorised process. A signature without a ticket is the [DRE: If] itself, caught the moment it occurs.
• Volume and velocity limits per hot wallet, per asset and per destination, with a hard stop rather than an alert.
• Destination rules: first-time destinations, destinations outside the allowlist.
• Authority-change monitoring: any EIP-7702 authorisation, approval or delegation touching a house wallet treated as a critical event, because it changes who can move funds, not just how much moves.

These controls are not in the standard toolkit of a CISO. EDR, SIEM use cases and identity analytics cover #7 and #4; they do not know what a normal withdrawal pattern looks like. Binance’s own account shows this. The one detection that fired on 29 October was a transactional one — “an internal alert regarding large-volume transfers” — and it fired only after the XRP, SOL and OP transfers. Endpoint protection had missed the malware in September; nothing reported a signature without a withdrawal behind it.

What is still open

Four points depend on details Binance has not published yet, and the record should change as they arrive:

• The AI tool step. Designed function (#1), an authorisation flaw (#2), or B’s credentials presented to it (#4)?
• The signing service. Did it sign for anything that could reach it (#1), or did the container present a credential (#4)?
• “Logged onto C’s computer.” If that involved C’s own credentials, a further #4 belongs before the use of A’s token.
• Homebrew. A counterfeit installer (#9) or the official channel subverted (#10)?

One point is not open, although it can look that way. Under EIP-7702 the attacker’s contract code runs as the Binance account, and a Turing-complete virtual machine invites the reading “foreign code executes, so #7”. It is still #1. The EVM is not one of the general-purpose execution engines that define foreign executable content;[3] it is the designed transaction function of the ledger, and the delegation used it exactly as designed. That is how the Bybit record classifies contract execution too.[5]

Contain where the authority lives

Binance did the hard part of a report well: it said what happened and why containment took time. Read with a cause-oriented taxonomy, the incident needs no new vocabulary. It is a fake interview, foreign code allowed to run, a token that should not have been on a laptop, and a signing service that signed for a caller nobody intended. The novel part is the last edge. Withdrawals stopped. The authority to move funds had already left the withdrawal process.

Stopping a process does not revoke authority that the attacker has already moved outside it.