Executive summary

Binance estimates that its security incident affected about $6.3 billion and says roughly $3 billion has been frozen, with losses to be covered from company and user-protection funds. Binance security update The public transaction record shows an Ethereum wallet being delegated to attacker-controlled code before a large withdrawal, while researchers describe additional ordinary signed transfers across other networks. Etherscan delegation record, Blockaid investigation TRM attributes the attack to North Korean TraderTraitor activity with high confidence, an assessment that remains distinct from Binance's continuing investigation. TRM investigation Likely (B2) — the priority control question is how an intruder could obtain spending and account-management authority, because protecting key material alone would not prevent an authorised signing service from executing malicious requests. This is our assessment of Binance's preliminary account and the recorded delegation, not a completed root-cause finding. Binance security update, Etherscan delegation record

Context and current service position

This report examines the exchange incident of 29 October 2026. Sources were checked through 09:43 UTC on 30 October; balances, recovery figures and service status below are dated observations, not a live tracker. TRM investigation

Binance's initial account is deliberately qualified: an engineer's compromised laptop may have provided access to a service container able to submit unauthorised withdrawals. The company says it has found no evidence of wallet private-key leakage and promises a technical post-mortem. That is neither proof that keys could not have been copied nor evidence that copying them was necessary. Binance security update

The later company service update says deposits are operating normally, withdrawals remain suspended, and restoration is expected within 48 hours. It describes multiple contributing factors and continues to investigate the compromised computer as a possible entry point. The notices give different accounts of deposits: the earlier statement says they were suspended, while the later update says they remained unaffected. They do not establish whether deposits were interrupted or when any resumption occurred. A restoration estimate is not confirmation that withdrawals have resumed. Binance service update, Binance security update

The distinction matters for incident commanders. An exchange can change a customer-facing service state while other work continues in transaction preparation, signing, wallet routing and recovery. Readiness should therefore be expressed as separate decisions: whether a service is available, whether its requests are trustworthy, whether its destinations are clean, and whether outstanding authority has been removed. Treating those decisions as a single green status conceals the question investigators most need to answer.

Technical analysis

A signature can authorise a change of control

Ethereum Improvement Proposal 7702 allows an externally owned account, or EOA, to delegate execution to contract code. Its signed authorisation specifies a chain identifier, delegate and nonce; an account's nonce is a sequence value used in transaction processing. The delegation survives the transaction that establishes it, and the specification provides a means to clear it. It also warns that delegated code has extensive access to the account. EIP-7702 specification

This creates two separate questions for a custodian: who may request an ordinary payment, and who may authorise a change in how the account behaves? A control that checks only recipient and amount on familiar transfer requests may leave a different class of signed message insufficiently governed. The defensive requirement is to evaluate the meaning of every supported signature request, including its future effects, before allowing a trusted signer to produce it. This is a control implication, not a claim that Binance used a particular hardware module or approval policy.

Ondology Labs reports recovering the Binance 14 signer from all 50 authorisations submitted in the takeover transaction. They covered consecutive nonce values; one matched the active wallet's state. The researchers say this demonstrates possession of the key or access to a service willing to sign the requests, and note that a low nonce in the batch corresponded to wallet activity only minutes earlier. The batch is therefore evidence of deliberate accommodation for a busy wallet, not a measurement of how long the attacker controlled Binance's internal systems. Ondology investigation

The signing distinction prevents two opposite mistakes. A valid signature does not establish that a human approved the intended business action. Equally, a valid signature does not reveal whether a key was extracted, a signing interface was abused, a session was hijacked or an approval process was manipulated. Each hypothesis needs evidence from the systems that prepared and authorised the request. On-chain reconstruction can constrain those hypotheses, but it cannot supply missing endpoint or service audit logs.

What the transaction record actually establishes

Etherscan records the delegation transaction as successful at 20:20:59 UTC on 29 October, with transaction type 4 and Binance 14 as its destination. Its displayed delegated address matches the contract identified by the researchers. The subsequent record shows a successful call at 20:24:23, including an internal transfer of approximately 167,464.25 ETH and 63 token transfers. The explorer also displays individual execution errors inside that successful transaction; a failed internal call should not be mistaken for failure of the overall drain. Delegation transaction, Withdrawal transaction

The interval between those two recorded timestamps is three minutes and 24 seconds. For defenders, this is a retrospective detection opportunity: a change of account code preceded the major transfer. It is not evidence that a monitoring team received an alert, had an authorised responder available, or could necessarily have completed containment in that interval. Response exercises should measure those additional steps explicitly rather than treating visibility on a public chain as equivalent to operational readiness.

Blockaid's account places ordinary transfers from Binance 16 and wallets on Optimism, Arbitrum and Avalanche alongside the Ethereum delegation. It also describes subsequent use of Binance 14's authority over Hot Wallet 34 to move USDC. This separates an account-code takeover, ordinary signed payouts and a dependent wallet relationship; a single Ethereum feature does not explain every reported leg. Blockaid investigation

The drk technical reconstruction identifies Hot Wallet 34 as a smart wallet that accepted Binance 14 as an operator, with two reported transfers totalling 823 million USDC. That relationship is analytically important: the assets directly held by a signing address may understate the assets it can command. Its reconstruction also distinguishes Binance 16's ordinary outgoing transactions from the delegated account's behaviour. drk reconstruction

An investigation should therefore build a permissions graph as well as a transaction graph. For each compromised identity or signing capability, enumerate accounts it could manage, contracts it could instruct, queued requests it could alter and services that could replenish those accounts. A dependency that appears harmless during routine operations can extend the blast radius when the trusted principal becomes attacker-controlled. The question is not merely how many keys were involved; it is how much authority a common workflow could exercise.

Selected timeline and the limits of each clock

Times below are UTC. The table combines distinct source observations and does not imply that every researcher covered every network.

Time Evidence Interpretation limit
From 28 October TRM describes preparation beginning at least 36 hours before the theft. TRM Preparation is not a demonstrated foothold inside Binance.
29 October, 20:20:59 Ethereum delegation succeeds. Etherscan Shows the account change, not the off-chain access method.
29 October, 20:24:23 Main Ethereum withdrawal transaction. Etherscan This transaction is only one part of the incident.
29 October, 20:58–21:01 LlamaRisk reports 60 million USDT supplied and 19,762 wrapped ETH borrowed on Aave. Aave response Borrowing against proceeds differs from selling them.
30 October, 00:08 Arbitrum's Council reports its emergency action, stated as 08:08 Hong Kong time. Council statement Network intervention time, not necessarily final execution on the destination chain.
30 October, 00:10:35 Ondology reports revocation of Binance 14's delegation. Ondology Does not establish complete eradication from internal infrastructure.

Impact assessment: several totals answer different questions

TRM's approximately $6.36 billion covers ten networks, valued when transfers occurred; its account says most outflows occurred in about 20 minutes, with later activity as well. Bitquery reports about $6.3 billion across nine networks and a longer observation window. These are attributed datasets, not interchangeable audited loss statements. TRM investigation, Bitquery investigation

Dataset Reported scope Reading discipline
TRM Ten chains, about $6.36 billion transferred; freeze tally about $2.7 billion at 00:30 UTC. TRM Gross transfer value and frozen value are different quantities.
Bitquery Nine chains; about $2.7 billion frozen or rescued; approximately $3.2 billion still held at 06:43 UTC. Bitquery This chain breakdown includes Polygon but omits Avalanche, which other investigators include.
Ondology Its own tracing covers Ethereum, Arbitrum and Avalanche; other chains in its aggregate table are attributed to CertiK's Dickson. Ondology Do not describe the entire table as independently traced by Ondology.

Bitquery explicitly limits the completeness of its transfer histories and links the XRP Ledger and Solana activity through timing and transaction characteristics rather than a shared address. It also prices different assets at different intervals. These qualifications matter when comparing precise-looking totals: address labelling, network coverage, observation time and pricing can all change a figure without a new theft occurring. Bitquery methodology

For accounting and communications, maintain separate totals for assets transferred, assets immobilised, assets returned to the custodian, customer balances restored and unresolved liabilities. A freeze is a containment state. It does not by itself prove restitution, reconcile ownership claims or establish when a customer can withdraw. Likewise, subtracting one rounded headline number from another does not produce a reliable final loss: the component sets may overlap differently and may have been valued at different times.

Binance's coverage pledge should be reported as a company commitment, not an independent solvency assessment. The company also promises updated proof-of-reserves information after remediation. The immediate analytical priority is the reconciliation between incident outflows, recovered control and the obligations being honoured, rather than inferring financial health from a single wallet balance. Binance security update

Containment depends on the asset and the venue

Arbitrum's own statement reports freezing 8,425 ETH and 74,559,805.2 ARB on Arbitrum One. It says the funds were moved to a designated address and require an ArbitrumDAO governance vote to move again. This was a network-specific emergency action; it should not be generalised into a claim that an issuer can freeze native ETH on Ethereum. The Council says other users' funds and applications were unaffected. Arbitrum Council statement

LlamaRisk's response report says the attacker-linked Aave position was over-collateralised at its snapshot. The response froze new supply and borrowing while allowing repayment, withdrawal and liquidation; it explicitly says no market was paused. A freeze and a pause therefore cannot be used as synonyms here. The same report warns that withdrawing supply during a prolonged freeze can increase utilisation and borrowing rates. Aave response

The lesson for defenders is to identify who has the power to stop each next step. A token issuer, an exchange, a lending protocol and a network governance body do not possess the same controls. Escalation requests should specify the asset, chain, address, transaction and requested action. Asking a responder to “freeze the wallet” without that context can obscure which assets remain movable and which intervention is actually available.

Borrowing also changes the containment problem. Where proceeds become collateral, investigators need to follow both the collateral and the borrowed asset, and distinguish restrictions on new positions from the management of an existing one. The relevant exposure cannot be represented accurately by looking only for swaps. This is our analytical implication of the reported Aave position, not a claim that Aave itself was breached.

Attribution and historical context

TRM bases its high-confidence TraderTraitor attribution on both on-chain and off-chain intelligence. The off-chain basis is not fully disclosed in the report. That limits what an outside analyst can reproduce, even when the transaction reconstruction is detailed. Shared laundering behaviour or a familiar target class should not be promoted into a new independent attribution. TRM investigation

The Federal Bureau of Investigation's 26 February 2025 notice attributes the approximately $1.5 billion Bybit theft to North Korea and calls the activity TraderTraitor. That official historical attribution does not automatically attribute this Binance incident. The earlier case provides a useful comparator and a source-backed reason to examine trusted transaction workflows, rather than a licence to merge every cryptocurrency theft under one actor name. FBI Bybit notice

There is a closer workflow precedent in the joint US–Japanese DMM disclosure. The agencies describe a malicious recruitment coding test targeting a Ginco employee in March 2024, later use of session information to impersonate that employee, and likely manipulation of a legitimate transaction request in May. They attribute the resulting theft to TraderTraitor. The word “likely” belongs to their transaction-manipulation assessment and remains important. FBI, DC3 and Japan NPA disclosure

Sygnia's Bybit analysis provides a different technical boundary. Its investigation found modified JavaScript in resources served to the signers, with malicious behaviour activated for selected contract addresses. Its chronology, incorporating other published investigative findings, places the earliest known developer compromise on 4 February and the theft on 21 February 2025. This is evidence about that incident, not a measured Binance dwell time or a generic duration for this operator. Sygnia investigation

Our comparison is architectural: a legitimate workflow can carry a malicious instruction when an upstream source of authority is compromised. At DMM the published account centres on a transaction request; at Bybit, on what signers were shown and what they approved. Binance's preliminary account and the delegation evidence raise questions about another part of the same broad problem, but do not establish an identical lure, malware family, supplier compromise or access mechanism.

The current TraderTraitor actor profile separates vendor naming from incident attribution. Our earlier Bybit article is related coverage. The BeyondTrust trusted-access analysis offers a wider comparison of delegated authority; it is not evidence of a shared actor or exploit.

Dwell time and persistence

Three durations should remain separate: preparation outside the victim, access inside the victim, and authority that remains usable after a transaction. The public Binance materials reviewed here do not establish the initial compromise date or a complete internal dwell interval. The documented preparation and delegation endpoints answer narrower questions. Replacing “unknown” with the earliest visible wallet funding would create a false precision that the evidence cannot support.

This incident also illustrates why persistence should be investigated beyond malware. Account state can preserve spending authority even after the endpoint or session that first enabled it is isolated. That is a consequence of the delegation mechanism, not evidence of a rootkit or an unseen implant in this case. Conversely, clearing the visible delegation cannot establish that the endpoint, service credentials and other signing permissions are clean. A recovery decision needs evidence for both layers. EIP-7702 specification

For a post-mortem, request a chronology with the first malicious endpoint action, first abnormal service request, first unauthorised signature, first externally visible account change, last successful attacker action and verified revocation. Specify the log source and retention limit for each time. Where a time cannot be recovered, preserve that gap. This makes it possible to distinguish delayed detection, delayed authorisation of a response, incomplete containment and incomplete visibility without assuming they are the same failure.

Indicators and evidence pivots

These Ethereum addresses are investigation pivots published by Blockaid and shown in the transaction records. The victim address is included to locate the incident, not as a malicious destination. Addresses are inert text; the source links lead to research or transaction records. Do not label all historical counterparties of a listed address as attacker-controlled. Blockaid investigation, Etherscan record

Ethereum identifier Role in the cited reporting
0x28C6c06298d514Db089934071355E5743bf21d60 Binance 14: affected account, not an attacker-owned wallet.
0x7C8601d4645b93cea45F71e118A729332e6B5CA0 Attacker operator address.
0x63e842B054Bd624a465454D533C33F573e9c6fAe Delegate contract.
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c Collection address.

Retain full transaction identifiers and chain context when exchanging evidence. A balance snapshot without a block reference cannot establish what was available at the moment an issuer acted. Similarly, an explorer label is an investigative aid, not a substitute for the underlying transfers and a recorded attribution basis. Keep the role, first observation and reason for inclusion alongside every pivot, and revise a classification openly when later evidence changes it.

Detection and hunting guidance

The clearest behavioural mapping is financial theft, MITRE ATT&CK T1657. The remaining opportunities below are precautionary hunts and control tests derived from the reported mechanism; they are not claims that specific endpoint techniques have been observed at Binance. Avoid filling an attack chain with guessed phishing, credential-dumping or lateral-movement technique identifiers.

Defensive question Evidence to collect Response decision
Has a treasury account acquired unexpected delegated code? Account-state changes, authorised delegate inventory and signed-message audit trail. Suspend replenishment and invoke a tested authority-revocation process.
Did a service request an unusual message class or batch? Request origin, workload identity, message type, nonce range and policy verdict. Quarantine the requester and preserve the request-to-signature relationship.
Did several wallets pay an unfamiliar destination in a short interval? Per-chain transfers correlated with internal business requests. Investigate common approval services and dependencies, not only individual keys.
Can a compromised principal instruct another wallet? Operator permissions, contract owners and downstream execution records. Expand containment to dependent authority.
Are funds still being routed into a suspect address? Internal sweeper, treasury refill and deposit-routing logs. Stop inflow until the destination's state is verified.

Tune these checks against the actual operating model. Legitimate delegation may exist in some wallet designs; the alert should identify deviation from an approved state, not simply the presence of code. Similarly, a large transfer may be routine treasury activity. The stronger signal combines a new destination, abnormal authority, inconsistent business approval and timing across independent wallets. Preserve enough context to explain why an alert fired, so an incident commander can act without reconstructing the whole chain from scratch.

Incident response and mitigation priorities

For an organisation investigating comparable exposure, the immediate objective is to remove usable authority while preserving evidence. Isolate the suspected endpoint and workload, capture volatile and audit evidence where feasible, revoke associated sessions and credentials, and identify which signing services accepted their requests. Do not treat an endpoint rebuild as the completion criterion when account or contract permissions can survive it. These are our recommended actions, grounded in the distinctions above.

Separate transaction containment from financial recovery. Stop automated replenishment to suspect addresses; review pending requests; use a clean, independently controlled process to clear unauthorised authority or migrate assets. Validate the resulting on-chain state before restoring automated flows. Recovery teams should maintain a parallel register of frozen, transferred and returned assets, with owner, responder and next required decision. A successful freeze and a completed customer repayment belong in different fields.

Policy enforcement should be independent of the service that requests a signature. Review whether payment, delegation, contract administration and ownership changes receive distinct approval. Require a readable statement of the requested action and its scope, and exercise rejection paths for unsupported message types. A multi-party approval arrangement is only useful if those parties can independently verify the action they are authorising; counting approvals alone cannot answer that question.

Finally, test the response as a timed sequence. Measure state-change detection, analyst validation, authority to interrupt the service, clean access to the responder, execution and confirmation. Include a scenario in which the normal administrative workstation or signer is unavailable. The purpose is to expose where an apparently simple revocation depends on a compromised component, an undocumented exception or a person who cannot be reached during the response window.

Outlook

A realistic possibility (B3) — subsequent reporting will change the technical access-path account more than the core lesson about controlling signing authority. Binance explicitly describes multiple factors and has not completed its root-cause account; meanwhile, the transaction evidence already shows an unauthorised delegation followed by asset movement. This assessment should be revisited against the promised technical report, particularly the bridge between endpoint access and authority to sign different message types. Binance service update, Etherscan delegation record

The most useful next disclosures would identify the actual credential or session boundary crossed, the policy decisions that permitted the signatures, the full extent of dependent wallet authority, and the evidence used to declare containment complete. For attribution, additional disclosed infrastructure or forensic links would make the vendor assessment more reproducible. For recovery, asset-level reconciliation would be more informative than another aggregate headline. Those are concrete tests for the next update, not assumptions that any particular answer has already been established.

Further reading