The Biggest Theft in Crypto History

What happened

The following chronology is a summary of published accounts. Times are UTC where shown. Binance's report uses Brasília time for several wallet events; those entries are converted here. Its preparation window is omitted because the timezone is not separately identified.

The direct sources are Binance's preliminary report, TRM's blockchain analysis and the FBI's October 31 alert.

Loss and recovery figures need a date and a source. Binance reported about $6.34 billion affected and about $2.85 billion frozen or intercepted on November 3. It said 98% of affected token assets had been replenished. That percentage refers to assets, not a count of hot wallets. Frozen funds, replenished reserves and funds returned to a victim describe different outcomes. ¹

TRM estimated $6.36 billion across ten chains, valuing transfers when they occurred. Elliptic reported approximately $6.43 billion across eleven chains. These are source estimates with different scopes; this report does not reconcile every transfer or valuation. ^{2, 3}

The attack chain and the permission that survived

The reported path runs from engineers' devices to a deployment credential, then to a signing service and finally to transactions the chains accepted. The internal steps rest on Binance's account. The transaction analysis comes from the named analytics firms. Keeping those two kinds of evidence separate prevents a visible transfer from being treated as proof of an unseen internal event.

TRM's interpretation was that access to signing infrastructure could explain valid transfers across several chains. Binance's later account describes such access. That agreement strengthens the explanation, but the incident report remains preliminary. Neither a valid signature nor a transaction receipt reveals everything that happened on the signing hosts. ^{1, 2}

On Ethereum, EIP-7702 permits a signed authorization to direct an account to delegated code. The authorization includes a chain identifier, delegate address and nonce. The protocol processes the authorization list in order and increments the authority's nonce after each valid tuple. Consecutive tuples can therefore validate in sequence. It is incorrect to assume that one matching tuple necessarily makes the other forty-nine unusable. The last valid delegation for an authority determines the resulting delegation. Ethereum specification, source 6.

That correction does not make the batch benign. A single valid authorization to malicious code may be sufficient. The control question is whether the signing system understood and permitted that change of authority.

The delegation also changes the recovery problem. Once on-chain permission exists, stopping the process that created it does not automatically withdraw it. A responder must identify the persistent permission and clear or replace it through a valid recovery transaction. ^{1, 6}

Four questions for the controls

When did the signer last serve the attacker?

A transaction's inclusion time does not reveal when its signature was produced. The final ETH transfer makes the distinction concrete: Binance says it was already pending before it finalized. A late outflow cannot, by itself, prove that fresh signing access remained available at that time. ¹

The question still matters. To answer it, investigators would need signing-service logs, authorization records, transaction submissions and a reliable time relationship between them. A useful incident record would distinguish request received, policy decision, signature produced, broadcast attempted and transaction included.

Nonce ranges may help examine the sequence, but they do not supply a signing timestamp. Concurrent transactions, retries, submission delays and private delivery paths can alter the relationship between a signature and its later appearance on-chain.

What exactly did the pause stop?

SSX360's reading is that containment has at least three separate jobs: stop new unauthorized signing, deal with transactions already signed or pending, and remove persistent authority already granted on-chain.

A customer-withdrawal pause may affect only part of that work. A signing halt can reduce further exposure while leaving a live delegation untouched. A recovery procedure should name each affected account and permission, identify who can revoke it, and record how completion will be checked.

This is a control-design lesson. It is not a finding that Binance lacked every such control, or that its teams took no action while assets moved. The public account leaves internal response details undisclosed.

Could replenishment route funds into an account under attacker control?

TRM reports repeated sweeps as assets reached the delegated wallet. That makes destination state a relevant question for refill systems. ²

A destination allowlist answers where a transfer may go. It may say little about what now controls that address. For an account intended to remain undelegated, an unexpected delegation should trigger investigation and a hold on refills. Legitimate delegated accounts require a different baseline.

A code check alone is insufficient. The system also needs to know the approved delegate, the account's intended use and how state can change between inspection and transfer. This report does not establish which checks Binance ran, who initiated particular refills, or the precise losses a different refill policy would have prevented.

How quickly can authority be withdrawn under incident conditions?

Clearing EIP-7702 delegation requires a valid authorization to the zero address. That authorization also changes the account nonce. A leaked or prematurely used recovery authorization can disrupt legitimate activity; it should not be described as harmless. ⁶

The practical test is whether authorized responders can recover when ordinary credentials, workstations or submission paths are unavailable. They need an agreed recovery identity, the current chain and nonce state, a funded submission path and a way to verify the result. Recovery should be rehearsed under congestion and failure, with elapsed time measured.

Pre-signing a range of recovery authorizations is a design choice requiring its own threat analysis. This report does not recommend it as a universal remedy or promise inclusion in the first block.

Evidence register

The labels below identify the basis of a claim. They do not turn a third-party statement into an SSX360 test result.

The FBI alert is the basis for the official attribution. Chainalysis's account explains its separate assessment and the reported commingling with Bitget proceeds. Those sources support attribution to the group; this report does not identify individual operators.

Desk exercise: a signer that enforces policy

The following is SSX360's proposed evaluation plan. It has not been run against Binance's systems or reproduced on a bench for this report. Its purpose is to turn the incident into tests a custodian can perform on its own authorized equipment.

Start with the attacker already holding a valid platform credential. That is a harder and more useful starting point than assuming all compromised requests arrive with an obviously invalid identity.

A physical approval can add a useful constraint when it is tied to a faithfully decoded request. The device must make the decision meaningful. A button that approves an opaque digest, an inaccurate display or an unbounded session does not establish what the operator intended.

A hardware counter can help identify approval reuse or gaps in a record. It cannot determine whether a destination was legitimate. Signature protection, transaction interpretation and authorization policy each need their own tests.

What the replay can say

If an independently enforced policy refuses a delegation before the signer authorizes it, that attempted delegation cannot be installed using that refused request. If an attacker controls another permitted signing path, or obtains an authorization elsewhere, the condition no longer holds. The test must cover those alternatives.

Similarly, a destination policy can refuse a proposed transfer when its inputs, implementation and enforcement remain trustworthy. It cannot support an exact dollar-saving claim from a public incident timeline. Such a claim would need the full request sequence, balances, concurrent activity, recovery timing and credible assumptions about how the attacker would adapt.

The six controls also share dependencies. Compromised firmware, a faulty parser, a policy-update path or a misleading display may defeat several at once. An assessment should test those shared failures instead of counting the controls as six independent guarantees.

A useful comparison: Bybit

Sygnia's account of the February 2025 Bybit incident describes a compromised Safe developer workstation and altered JavaScript delivered to signers. It is a relevant comparison because it places the request interface and the signer's view inside the security boundary. Sygnia, source 7.

The two incidents should not be collapsed into an identical attack. The reported Binance path involves internal signing-service access and persistent delegated code. Bybit illustrates how a compromised interface can misrepresent the action being approved. Each points to a question about the relationship between an operator's intent, the message signed and the authority created by that message.

For a custodian, the useful comparison is the test plan: which component interprets the request, which component decides it is permitted, and what evidence connects that decision to the signature? Storage temperature and signature validity alone do not answer those questions.

What a custodian can test this quarter

1. Inventory signing authority. List callers, message types, credential dependencies, policy-update paths and recovery identities. Include service accounts and unattended workflows.
2. Exercise the compromised-caller case. In an authorized test environment, check whether a workload with valid platform credentials can exceed its signing authority.
3. Verify what approval means. Bind approval to the complete decoded request. Test substitution, replay, retries, concurrent requests and every raw-digest path.
4. Baseline account state. Monitor unexpected changes in delegation or permissions. Apply a hold appropriate to the affected account before refilling it; do not treat legitimate delegation itself as evidence of compromise.
5. Measure containment and recovery separately. Record when new signing stops, what remains pending and when persistent permissions are removed. Include congestion, failed submissions and unavailable staff in the drill.
6. Constrain internal automation. Give AI tools and other assistants only the credentials and reach their tasks require. Review their access to engineers' sessions, secrets and deployment systems.

The resulting report should identify the requests tested, the expected policy decisions, observed behavior, bypasses found and unresolved conditions. A passing test applies to that configuration and test scope. It is not a promise about every future attack.

Work with SSX360. Start with one signing workflow or device and an agreed set of questions. Hardware security assessments explain the service; bench intake is the route to discuss scope, custody and deliverables. Contact mission@ssx360.com. For a product overview, see PNT-1’s HSM signing functions, including the separate secure-element and host roles.

Sources

1. Binance, October 29 Security Incident: Preliminary Findings and Response Update, November 3, 2026. Verified official Binance account. Company account of the intrusion, recovery actions and asset totals.
2. TRM Labs, North Korea Steals USD 6.36 Billion From Binance in the Largest Hack in History, dated October 29, 2026; account states its figures reflect observations through October 30 at 00:30 UTC. First-hand analyst account of transfers and attribution.
3. Elliptic, The largest theft in history: North Korea likely behind the $6.4 billion Binance hack. Analyst estimate and incident coverage; live page consulted November 7, 2026.
4. Federal Bureau of Investigation, North Korea Responsible for $6 Billion+ Binance Attack, October 31, 2026. Official attribution and address advisory, with USSS and IRS-CI.
5. Chainalysis, The $6.4 Billion Binance Hack: Tracing the North Korea Link, dated October 30, 2026, with subsequent figures through November 3. First-hand analyst account of fund movements and attribution.
6. Ethereum Improvement Proposals, EIP-7702: Set Code for EOAs, especially the Behavior section. Protocol source for authorization processing, nonce changes, delegation and clearing code.
7. Sygnia, Bybit: What We Know So Far, March 16, 2025. Investigator account and synthesis of the Bybit incident.

Limits of this report

This is a desk review of the linked public record as accessed on November 7, 2026. Binance's account is preliminary. The detailed internal signing policy, request format, access logs and independent review were not available to SSX360 for this report. We did not reproduce the analysts' blockchain queries, inspect their complete datasets or test the proposed controls on Binance equipment.

Reported dollar totals and recovery figures use their sources' dates and definitions. The headline follows TRM, Elliptic and Chainalysis in describing the incident as the largest crypto theft on record at publication. The proposed controls are an assessment plan; their effectiveness depends on implementation and testing. No certification or guaranteed prevention claim is made.