Confirmed and reported timeline

The intrusion-to-signing path before 20:05 UTC is not public. Binance has promised a technical post-mortem.

What Binance has said

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, Security Incident Update, 30 October 2026

The attacker used a known multi-signature protocol EIP-7702, to obtain on-chain execution approval over a hot wallet. That delegation did not pass through our normal approval controls.

Richard Teng, Binance co-CEO, video on X, 30 October 2026 (via Bitcoin.com News, BBC)

Note: EIP-7702 is code delegation for ordinary accounts ("Set Code for EOAs"), not a multi-signature scheme. Maborak and Bitcoin.com News both flag the wording. The finding that matters is that a normal approval control was bypassed.

Plausible attack model (Analysis)

1. 1
   Persistence on a developer endpoint

   Analysis. TraderTraitor has used crypto-themed lures and trojanised apps (CISA AA22-108A); BBC quotes Aikido on fake job interviews and poisoned dependencies. The vector here is unknown. ATT&CK T1566, T1195.002, T1204.
2. 2
   Credential and session harvest

   Analysis. A DevOps laptop typically holds SSO session cookies, cloud CLI tokens and kubeconfig files. Replaying them bypasses MFA. Not reported for this incident. T1539, T1550.004, T1528, T1552.007.
3. 3
   Pivot to a trusted service

   Confirmed in outline by Binance (service container). Exact privileges unknown. T1078.004, T1613, T1609.
4. 4
   Abuse of the signing path

   Reported by TRM: wallets on different chains, key types and schemes all signed within about 30 minutes, so the signer was instructed rather than a key stolen. The 50-nonce batch suggests signing access was time-limited or had to be requested. T1657.
5. 5
   Pre-staged, fast execution

   Confirmed on-chain: Tornado-funded operator wallet 36 hours earlier, rehearsed sweeper, then a burst across chains. Self-destructing tooling (Binance). T1070.

Why perimeter and encryption controls did not help (Analysis)

• Perimeter: the attacker operated from inside, through a device and service already trusted.
• Encryption and key storage: keys did not need to leave the HSM or MPC cluster; the signer was asked to sign.
• Transaction approval: the EIP-7702 authorisation is not a transfer, so value or destination checks on withdrawals would not see it.
• Persistence on-chain: once delegated, Binance 14 obeyed the sweeper for nearly four hours with no new signatures.
• Shared blast radius: one signing path served many wallets and chains, so one compromise reached all of them.

Behavioural baselines worth building

The last row is the strongest single control: every signature should reconcile to an approved business request ID. GCSA makes the same point about closing the causal chain from endpoint to on-chain transaction.

Dwell time

Confirmed: on-chain preparation began at least 36 hours before the theft. Not public: when the laptop was first compromised. Analysis: SIEM and UEBA shorten dwell time only if signing-service and Kubernetes audit logs reach the SIEM, and if identities in custody namespaces are scored more strictly than general staff.

Log sources

Detection opportunities against the 20-minute window

Analysis: a velocity rule with authority to pause would have fired within the first five minutes on the XRP Ledger, about 15 minutes before the largest Ethereum loss. This is the clearest missed opportunity visible in public data.

Example rules

title: Unexpected EIP-7702 authorisation or nonce-range batch from signing service
id: analysis-example-0001        # illustrative, not a published rule
status: experimental
logsource:
  product: custody_platform      # your signing-service audit log
  service: signing_requests
detection:
  delegation:
    request_type: 'eip7702_authorization'
  not_allowlisted:
    delegate_address|expand: '%approved_7702_delegates%'
  nonce_batch:
    distinct_nonces_per_wallet|gte: 3   # computed field over 10 min
  condition: (delegation and not not_allowlisted) or nonce_batch
level: critical
tags:
  - attack.impact
  - attack.t1657                 # Financial Theft
falsepositives:
  - Planned smart-account migration with change ticket

// Human identity runs exec/attach into a production withdrawal or signing pod,
// and the same user's workstation raised any EDR alert in the prior 72 h.
let Window = 72h;
let EdrHits = DeviceAlertEvents            // EDR alerts (e.g. MDE AlertInfo/AlertEvidence)
  | where Timestamp > ago(Window)
  | summarize EdrAlerts = count(), Titles = make_set(Title) by AccountUpn;
K8sAudit                                   // Kubernetes API audit log, ingested to SIEM
| where Verb in ("create") and ObjectRef_Subresource in ("exec","attach","portforward")
| where Namespace in ("withdrawal-svc","signing-svc","wallet-ops")
| where UserType == "human"                // service accounts should never need exec
| join kind=leftouter EdrHits on $left.User == $right.AccountUpn
| extend Severity = iff(EdrAlerts > 0, "Critical", "High")
| project TimeGenerated, User, SourceIP, UserAgent, Namespace, Pod, Severity, Titles
// ATT&CK: T1609 Container Administration Command, T1078.004 Valid Accounts: Cloud

// Session or OAuth token replayed from a new device, ASN or geography
// within the token's lifetime (pass-the-cookie / stolen app token).
SigninLogs
| where TimeGenerated > ago(1d)
| summarize Devices = dcount(DeviceDetail.deviceId),
            ASNs = dcount(AutonomousSystemNumber),
            Countries = make_set(LocationDetails.countryOrRegion)
            by UniqueTokenIdentifier, UserPrincipalName
| where Devices > 1 or ASNs > 1
// ATT&CK: T1539 Steal Web Session Cookie, T1550.004 Web Session Cookie,
//         T1528 Steal Application Access Token

index=custody sourcetype=hotwallet:outflow
| bin _time span=5m
| stats sum(usd_value) as out_usd dc(dest_address) as dests
        values(chain) as chain by _time wallet_id
| lookup wallet_baseline wallet_id OUTPUT p99_5m_usd allowlisted_dest_ratio
| eval breach=if(out_usd > 3*p99_5m_usd, 1, 0)
| where breach=1
| stats dc(chain) as chains_hit sum(out_usd) as total_usd
        values(wallet_id) as wallets by _time
| where chains_hit >= 2 OR total_usd > 50000000
| eval action="AUTO-PAUSE withdrawals + page custody on-call"
# ATT&CK: T1657 Financial Theft. Thresholds are illustrative.

# Multi-stage correlation: any 3 of 5 stages for one identity,
# device or wallet inside 20 minutes => critical incident
index=notable earliest=-20m
| eval stage=case(
    rule_name="EDR: suspicious process / anti-forensics on dev endpoint", "S1_endpoint",
    rule_name="IdP: token replay new device or ASN",                      "S2_identity",
    rule_name="K8s: human exec into signing or withdrawal pod",          "S3_container",
    rule_name="Signer: off-pattern request (7702, nonce batch, fee)",    "S4_signing",
    rule_name="Chain: hot-wallet outflow above baseline",                "S5_outflow")
| stats dc(stage) as stages values(stage) as seen by entity_key
| where stages >= 3
# T1566/T1195.002 -> T1539/T1550.004 -> T1609/T1613 -> T1657 ; T1070 anywhere

# On-chain watcher for treasury and hot-wallet EOAs (pseudo-code)
for wallet in TREASURY_EOAS:
    code = eth_getCode(wallet, "latest")
    if code.startswith("0xef0100"):         # EIP-7702 delegation indicator
        delegate = "0x" + code[8:48]
        if delegate not in APPROVED_DELEGATES:
            alert(CRITICAL, wallet, delegate)
            trigger_runbook("sign pre-approved 7702 revocation; pause wallet")
for tx in mempool_and_new_blocks(from_addresses=TREASURY_EOAS):
    if tx.type == 4:                         # set-code transaction
        alert(CRITICAL, "type-4 tx touching treasury wallet", tx.hash)
    if tx.max_priority_fee not in PIPELINE_FEE_PROFILE[tx.from_]:
        alert(HIGH, "fee fingerprint differs from withdrawal pipeline", tx.hash)

All rules are illustrative pseudo-rules written for this report (Analysis). Table and field names are placeholders; tune thresholds on your own baseline. The 0xef0100 prefix is the delegation indicator defined in EIP-7702.

Signing and custody controls

CI/CD and workload hardening

• SLSA Build Level 3 provenance on every image that reaches signing or withdrawal namespaces; admission control rejects unsigned or unprovenanced images.
• No interactive exec or attach into custody pods; break-glass only, two-person approved, time-boxed, recorded.
• Workload identity (short-lived, attested) instead of static service-account secrets, per NIST SP 800-207A.
• Pipelines cannot reach signer APIs; deploy and sign are separate trust domains.
• Secure development practices per NIST SP 800-218 (SSDF), including dependency pinning to blunt poisoned packages.

Just-in-time access and developer workstations

• No standing access to production custody systems; JIT elevation tied to a change ticket and auto-expiring in minutes.
• Phishing-resistant MFA (FIDO2 or passkeys) and device-bound, short-lived sessions so stolen cookies fail elsewhere.
• Privileged-access workstations for custody engineers, separate from email, browsing and interview calls.
• Continuous device posture checks feeding access decisions, per the CISA Zero Trust Maturity Model v2.0.
• For Australian operations: ASD Essential Eight controls (application control, restricting admin privileges, MFA) as a floor.

Financial API gateways

• Mutual TLS and signed requests between withdrawal services and signers, with per-caller scopes.
• Rate and value limits enforced at the gateway, independent of the calling service.
• Anomaly scoring on caller, request type and destination before forwarding to the signer.
• Immutable, off-host audit logs so self-destructing tooling cannot erase the trail.

How large organisations implemented it

How ZTNA maps to the Binance risks

Phased implementation path

Analysis, aligned to CISA ZTMM v2.0 stages and the ASD Modern Defensible Architecture. Durations depend on estate size; the metrics are suggested targets, not benchmarks from any source.

Controls and what they addressed

MFA itself is much older than this list; the dated milestones above are the phishing-resistant forms. Bybit's attacker reused a live AWS session token and bypassed MFA, so MFA without device-bound sessions is not enough.

Major exchange and custody hacks

US dollars at the time of each event, as reported then. Bitfinex's 119,754 BTC was valued at over $3.6B when the DOJ recovered most of it in 2022.

Which controls would have stopped or limited each (Analysis)

The pattern across a decade: attacks moved from the network edge, to endpoints, to identities and sessions, to the build and signing path. Each control in the timeline still matters, but none is enough without the one after it.