Binance hack: how USD 6.36 billion left with no sign of leaked keys

In the Binance hack of 29 October 2026, an attacker took about USD 6.36 billion from wallets spread across ten blockchains, most of it in roughly twenty minutes from 20:05 UTC, according to TRM Labs' analysis of the public blockchain transactions. It is the largest crypto-asset theft on record, more than four times the Bybit theft of February 2025, and TRM attributes it to TraderTraitor, a North Korean unit.

Figures vary with the source and the valuation time, with about USD 6.3 billion according to Binance and USD 5.912 billion according to Chainalysis. Binance has pledged to cover losses from its SAFU fund and company funds.

TRM's hypothesis is that the attacker got Binance's signing system to sign the transactions it wanted, and neither Binance nor Blockaid sees signs of leaked private keys. The article reconstructs the attack chain from public data and explains the mechanism used on Ethereum. It then maps the pattern onto controls within reach of a Spanish financial entity, such as OAuth consents, workload identities (the accounts applications use, as opposed to people), secrets management and the obligations under DORA.

How did the Binance hack unfold?

Most of the funds left in about twenty minutes, and a second wave came roughly two and a half hours later. Between 20:05 and 20:09 UTC, five Binance wallets on the XRP Ledger sent 233.46 million XRP to a single attacker address. Solana and Optimism followed at around 20:10.

At 20:20, 18,270 BTC left a Bitcoin wallet that TRM describes as hot, meaning connected for day-to-day operations, and CryptoQuant, as cited by Forbes, describes as cold. Within the same block the attacker began splitting the funds into round amounts of 1,000 and 100 BTC, a dispersal TRM describes as a peel chain and which makes tracing harder. Within the next two minutes, 612.7 million USDT and 46.4 million TRX left Tron. At 23:05, a second wave reached wallets on Avalanche and Polygon.

By chain, Ethereum accounts for about USD 3.79 billion, Bitcoin about 1.47 billion and Tron about 628 million, according to TRM. The split matters less than the fact that wallets on ten networks, with different types of keys and signing schemes, produced valid signatures for the same attacker in a single evening.

Binance confirmed a security incident and suspended withdrawals while it rebuilds its withdrawal service and rotates the related addresses, and expects to resume them within about 48 hours. According to its initial investigation, a DevOps engineer's compromised laptop may have been the entry point to a service container used to submit unauthorised withdrawals. In a later update reported by The Next Web, the company said it had found additional points of breach and that multiple factors were involved. Its chief executive, Richard Teng, made clear that the attacker did not simply use one engineer's permissions. The root cause analysis is still pending.

How long did the attacker spend preparing?

The attacker prepared the operation for at least 36 hours, according to TRM. From the morning of 28 October, its operator wallet received three small withdrawals from Tornado Cash, a mixing service that hides where funds come from. TRM sees the same funding pattern in Bybit and in the KelpDAO attack of April 2026.

Early on the 29th, the operator deployed a first version of the attack code and tested it on two wallets. Later it rehearsed the final version on a third wallet and sent the test funds back to its operator wallet. About four hours after that rehearsal, a Binance hot wallet was delegated to that same code.

Two readings follow from that sequence. There was a day and a half of preparatory activity visible on the blockchain, although linking it to Binance in advance would have required knowing what to look for. And the final rehearsal describes a planned operation, with room to fix mistakes before going live.

TRM attributes the attack with high confidence to TraderTraitor, the North Korean unit the FBI linked to the USD 1.5 billion Bybit theft. Chainalysis also ties it to that group and has found proceeds from September's Bitget exploit mixed with the Binance funds, according to Forbes. Binance has not named the attackers. The attribution is a third-party assessment, not a confirmed fact. North Korean APT groups have featured on this blog before, in the Lazarus Dream Job campaign.

How did the attacker take over an Ethereum wallet without stealing keys?

On Ethereum, the attacker used an EIP-7702 delegation that turned a Binance hot wallet into a contract under its control. EIP-7702 arrived with Ethereum's Pectra upgrade in May 2025 and lets an ordinary account delegate its behaviour to a smart contract through a signed authorisation. From then on, calls to the account execute that contract's code, and the delegation stays in force until the account signs another authorisation that replaces it. It resembles an OAuth consent, except that only the account's own signature can clear it, not an administrator from outside.

At 20:20 UTC, the operator sent a single transaction carrying fifty authorisations signed with the hot wallet's key, all pointing to a contract programmed to empty the wallet (a sweeper) that only takes orders from the attacker. Each authorisation is valid only for one specific value of the account's transaction counter, the nonce, and a hot wallet's counter moves constantly as customers withdraw funds. With signatures for fifty consecutive values, one of them was bound to match the counter at execution time.

Three minutes and 24 seconds later, the contract emptied the wallet in a single transaction of 167,464 ETH and 63 tokens, including 1.615 billion USDT. The delegation stayed active until at least 23:56 UTC. The attacker emptied the wallet again as funds arrived, at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56. The same wallet was also authorised to order operations on another contract-managed Binance wallet, which let it move 823 million USDC that Circle froze at 21:04.

Blockaid, a blockchain transaction security vendor, says its engine classifies a delegation like this as malicious as soon as it appears, because it turns an account into an untrusted contract. According to the firm, the attack could have been stopped at the delegation transaction, and once it was published there were 3 minutes and 24 seconds left to react. It is the view of a vendor. Binance is not known to have used its product, but the analysis identifies the first signal visible from outside, in the configuration change and before the funds moved.

Why do the other chains point to the signing system?

The other chains point to the signing system because there was no delegation on them and the attacker still obtained valid signatures. Binance wallets on the XRP Ledger, Arbitrum, Avalanche, Optimism, Base, Bitcoin, Tron, Solana and, later, Polygon sent it funds through ordinary signed transfers. Another Ethereum hot wallet moved 28,006 ETH, 55.7 million USDT and 25.9 million RLUSD with no delegation involved.

The networks involved use different types of keys and signing schemes, which is why TRM considers it most likely that the attacker got Binance's hot wallet signing system to sign the transactions it wanted. The batch of fifty authorisations prepared in advance also suggests that the access may have been time-limited or that signatures had to be requested through a system.

Multi-party computation (MPC), which splits signing between several parties, and hardware security modules (HSMs) protect keys, not the decision to sign. The distinction explains how there can be no sign of leaked keys while ten networks still accepted the attacker's signatures. The fifty authorisations were signed before 20:20, so the first trace sat in the signing service's own logs, not on the blockchain.

TRM and Blockaid therefore place the control before signing. They recommend rejecting unexpected EIP-7702 authorisations, treating requests for many authorisations across a range of nonces as a sign of compromise, and enforcing destination allowlists and value caps. Blockaid's chief executive, Ido Ben-Natan, does not think keys were leaked either and speaks of misuse of the signing system.

Where is the signing system in an entity without crypto-assets?

In an entity that holds no crypto-assets, the equivalent is any system that authorises operations on the organisation's behalf without asking for credentials again. Treating the story as irrelevant to banking would be a mistake, since what was compromised at Binance was a system of that kind. In a Microsoft environment it takes three common forms.

The first is OAuth consents and app registrations in Entra ID. An application with delegated or application permissions on Microsoft Graph operates without asking anyone for credentials, just as an EIP-7702 delegation acts until it is cleared. Microsoft documents the abuse of this mechanism as an illicit consent grant, a pattern similar to the Salesforce data theft through connected apps. MITRE ATT&CK covers it under T1528 (Steal Application Access Token) and T1550.001 (Application Access Token), and its use for persistence under T1671 (Cloud Application Integration).

The second is adding credentials to a service principal, the identity an application acts with. An attacker with enough permissions does not need to steal the existing secret, because it can add a new certificate or secret to the application and sign with that. The legitimate application keeps working, its owners notice no change and the access survives user password resets. MITRE classifies it as T1098.001 (Additional Cloud Credentials), a common route to persistence in the cloud that our guide to non-human identities covers.

The third is token and code signing. Whoever obtains the token-signing certificate of a federation such as AD FS can issue valid SAML tokens (T1606.002). Whoever controls the signing of software artefacts gets the same effect as at Binance, with operations indistinguishable from legitimate ones because, cryptographically, they are legitimate.

In all three cases, detection based on anomalous sign-ins, geolocation or brute force may not fire, because the attacker presents a valid signature. The useful signal lies in changes to how authorisation is configured.

Which controls can be started this week?

The first steps are to inventory OAuth consents, restrict user consent, alert on new application credentials, limit who can add them and test revocation.

1. An inventory of live delegations should list granted OAuth consents and applications with application permissions on Graph, with the grant date and who approved it, details recorded only in the audit log. Any authorisation without an identifiable owner is a finding.
2. Free end-user consent can be limited to verified publishers and low-impact permissions, or replaced with the Entra ID admin consent workflow, bearing in mind that consents already granted stay in place.
3. Entra ID audit logs, exported to a SIEM with adequate retention, should raise alerts on operations such as "Add service principal credentials", "Consent to application" or certificate and secret changes logged under "Update application". Such changes ought to be infrequent and have a named owner.
4. Roles that can add credentials to applications, such as Application Administrator and Cloud Application Administrator, should be treated as tier 0 and activated just in time through Privileged Identity Management (PIM). The same applies to owners of applications with high Graph permissions.
5. The revocation procedure has to be tested. Each organisation should know how long it takes to withdraw a consent, delete credentials it does not recognise and disable the affected service principal, bearing in mind that tokens already issued stay valid until they expire.
6. Signing infrastructure should be separated by tier. TRM recommends segregating signing systems and approval paths by chain and wallet category. The corporate equivalent is that one system cannot authorise both treasury operations and directory changes, as the privileged access tiering model proposes.
7. Privileged administration should happen from dedicated workstations. If a DevOps laptop is confirmed as one of the entry points at Binance, the lesson is direct. When identities are administered from the same machine used to read email, that machine is the perimeter of the signing system.
8. Containment contacts should be identified before the incident. Tether froze USDT at 21:01 UTC and Circle froze USDC at 21:04. Both came less than an hour after the theft began. Stablecoin issuers and the Arbitrum Security Council, the body that can intervene in that network in an emergency, between them immobilised about USD 2.7 billion, according to TRM. An entity should have its counterparts at custodians, critical providers, the national CERT and the supervisor identified in advance.

Meanwhile, the attacker rushed to swap stablecoins, which their issuers can freeze, for ETH through market makers and lending protocols. TRM recommends that exchanges, market makers and other intermediaries screen deposits and counterparties against the attacker addresses it has labelled.

What does DORA require after an incident like this?

DORA requires entities to prevent and detect this kind of abuse, report the incident within set deadlines, manage ICT third-party risk and test their resilience. Regulation (EU) 2022/2554 applies to EU financial entities, including crypto-asset service providers authorised under MiCA (Article 2(1)(f)).

Prevention falls under Article 9, which requires limiting logical access and protecting authentication mechanisms and cryptographic keys. Articles 20 and 21 of Delegated Regulation (EU) 2024/1774, on identity management and access control, develop it further.

Do Articles 10 and 11 change what has to be detected?

Articles 10 and 11 indirectly change what has to be detected, because they require entities to detect anomalous activities promptly and to have response and recovery plans. When every operation is cryptographically valid, that means monitoring changes in how authorisation is configured, such as new credentials on applications, recent consents or changes to signing policies.

What are the deadlines for reporting a major incident?

A major ICT-related incident is reported in three steps, under Article 19 and Delegated Regulation (EU) 2025/301. The initial notification must be sent as early as possible, within 4 hours of classifying the incident as major and, as a general rule, no later than 24 hours after becoming aware of it. The intermediate report is due within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report, covering causes, costs and corrective measures.

Classification follows the criteria in Delegated Regulation (EU) 2024/1772, and reports use the templates in Implementing Regulation (EU) 2025/302. In Spain, reports go to the Banco de España, the CNMV or the DGSFP depending on the type of entity, and to the CNMV in the case of MiCA-authorised crypto-asset service providers. Each supervisor can add procedural requirements.

Does anything change in ICT third-party risk?

For ICT third-party risk under Articles 28 to 30, the focus shifts to providers that sign or hold assets on the entity's behalf. An exchange where an entity holds funds is not usually considered an ICT service provider in itself, but custody and signing services can be, such as managed MPC wallets, cloud HSMs or identity platforms.

Article 30 sets the minimum content of those contracts, including the provider's assistance during incidents and, for critical or important functions, its reporting obligations towards the entity. The review question is how long the entity would take to learn through contractual channels, and not from the press, that a critical provider had suffered an incident like this. The question forms part of the third-party risk management that DORA requires.

Should resilience testing cover this vector?

The tests under Articles 24 to 27 should include the abuse of workload identities and the addition of credentials to applications. Entities required to carry out threat-led penetration testing (TLPT) under Article 26 and Delegated Regulation (EU) 2025/1190 should include it in their scenarios. Leaving it out omits what worked at Binance, as our analysis of TLPT and TIBER-ES in Spain explains.

Which questions should management take to the board?

The three questions for the board are which delegated authorisations are live in the directory today and who granted them, how long the organisation takes to revoke them and who gets called in the first hour.

The Binance hack combined a day and a half of preparation, a prior rehearsal and, according to TRM's and Blockaid's hypothesis, the use of the ability to sign instead of stolen keys. The first signal visible on the blockchain was a configuration change, but the authorisations had already been signed inside Binance. Containment depended largely on third parties, the stablecoin issuers and the Arbitrum Security Council.

Hard2bit helps review the inventory of consents and non-human identities, prepare for DORA compliance and design adversary simulation scenarios that include this vector.

Sources and attribution: this analysis is based on public information available on 30 October 2026, chiefly TRM Labs' analysis, Binance's statements as reported by CyberInsider and The Next Web, Blockaid, Forbes, Fortune and Cointelegraph, and the text of DORA and its implementing rules. That the attacker controlled the signing system is TRM's hypothesis, pending Binance's root cause analysis, and the attribution to TraderTraitor is a third-party assessment. References to DORA do not constitute legal advice and should be checked with the competent supervisor.