An analysis of the 29 October 2026 Binance hot wallet compromise, the EIP-7702 persistence technique used on Ethereum, and what custodians should change.
STATUS This analysis reflects open sources and Ethereum mainnet data as of 30 October 2026, 15:00 UTC. Binance has not yet published its technical post-mortem, so figures and attribution may change. |
At 20:05 UTC on 29 October, five Binance wallets on the XRP Ledger sent out 233 million XRP. Over the next twenty minutes, hot wallets on Bitcoin, Tron, Solana, Optimism and Ethereum followed. By the next morning Binance put the estimated impact at around $6.3 billion. That is more than four times the $1.46 billion taken from Bybit in February 2025, and the largest crypto theft on record.
According to Binance, no private key leaked. The attacker got Binance’s own signing infrastructure to sign the attacker’s transactions. On Ethereum, the attacker then used EIP-7702, the account delegation feature that shipped with the Pectra upgrade in May 2025, to keep control of an exchange hot wallet for almost four hours. As far as we know, that technique had not been used against an exchange before.
Some early coverage called this a “Binance data breach”. We found no evidence that customer data or KYC records were exposed. Every primary source describes a theft of funds.
# | Judgment | Confidence | Basis |
|---|---|---|---|
1 | Between 20:05 and 23:56 UTC on 29 October, roughly $6.3B was moved out of 17 Binance hot wallets across 10 blockchains. | Confirmed | Binance statement; on-chain data; TRM, Elliptic |
2 | The attacker did not need Binance’s private keys. Binance’s signing infrastructure signed the attacker’s transactions after a compromise that started on a DevOps engineer’s laptop. | High | Binance statement; 50 pre-signed authorizations; TRM, Elliptic |
3 | The operation is attributed to TraderTraitor, a cluster under North Korea’s Lazarus umbrella. We consider this plausible; no government has confirmed it. | Moderate–high | TRM (high), Chainalysis (likely), Elliptic (moderate) |
4 | On Ethereum, an EIP-7702 delegation kept the “Binance 14” hot wallet under attacker control for 3 h 50 min and allowed six further withdrawals without any new signature. | High | Blocks 26300753 and 26301896, verified by ThreatMon |
5 | There is no evidence of customer data or KYC exposure. | High | All reporting covers funds only |
Figure 1. Incident timeline in three phases, with the response latencies that matter for defenders.
Preparation started at least 36 hours before the theft. According to TRM Labs, the attacker’s operator wallet (0x7C86…5CA0) was funded on the morning of 28 October with three 0.1 ETH withdrawals from Tornado Cash. The same wallet deployed the sweeper contract at about 15:59 UTC on 29 October, more than four hours before the first outflow. The infrastructure for the Ethereum leg sat on a public blockchain all afternoon.
The outflows began on the XRP Ledger at 20:05. At 20:20 a single hot wallet sent 18,270 BTC, and in the same minute a type-4 transaction carrying 50 authorizations landed on Ethereum. The Tron hot wallet lost 612.7 million USDT and 46.4 million TRX within two minutes of the Bitcoin transfer. By TRM’s count, most of the value moved in about 20 minutes. A second wave hit Avalanche and Polygon at 23:05.
The fastest defensive action came from stablecoin issuers. Tether froze 971 million USDT at 21:01 and Circle froze 823 million USDC at 21:04, roughly 40 minutes after the stablecoins reached the attacker. Reports place Binance’s withdrawal pause between 22:15 and 22:33, more than two hours after the first outflow. The Ethereum delegation stayed live until 00:10 on 30 October.
Figure 2. Binance’s first official account of the incident, posted on X at about 02:25 UTC on 30 October. The “DevOps laptop → service container → unauthorized withdrawals” chain comes from this statement. Source: x.com/binance
Six hours later Binance widened that account. Its investigation had “uncovered additional points of breach”, and CEO Richard Teng said the attacker “did not simply use one engineer’s permissions” and that this “was not a single ‘one-click’ action.” The internal half of the attack chain below is therefore still a partial picture.
Figure 3. The Binance attack chain across four trust zones. Each stage carries its ATT&CK mapping and a chip for the evidence behind it.
Stages 1–2: from a DevOps laptop to a service container
The only official detail on initial access is that a DevOps engineer’s laptop was compromised. How it was compromised has not been disclosed. TraderTraitor’s recent operations offer strong precedents: fake recruiters and “pre-employment” coding tests (DMM Bitcoin via Ginco, 2024), a trojanized Docker and Python project on a developer’s Mac (Safe{Wallet}, then Bybit, 2025), and an archive AirDropped onto a corporate Mac followed by persistence in Kubernetes pods (the UNC4899 case in Google’s H1 2026 Threat Horizons report). We do not know which of these, if any, was used against Binance. The target profile, an engineer with a path into production infrastructure, fits the pattern exactly.
Stages 3–4: a trusted path to the signer
The compromised container could submit withdrawal transactions, and the signing infrastructure signed them. Binance says it found no evidence that a private key leaked, and the on-chain picture is consistent with that. Bitquery noted that the attacker’s transactions were built differently from Binance’s normal templates; on Bitcoin, for example, fees were about twice the usual level. In our assessment, that points to transactions assembled by the attacker’s own tooling and pushed through Binance’s signing path, rather than Binance’s withdrawal pipeline being tricked into building them.
Binance has not said whether the signer is MPC- or HSM-based, which is why our diagram labels it “type not disclosed”. Several early write-ups state one or the other as fact; we found no primary source for either.
Stages 5–7: exit
On nine of the ten chains, funds left through ordinary, validly signed transfers. On Ethereum the attacker did something different.
EIP-7702 went live on Ethereum mainnet with the Pectra upgrade on 7 May 2025. It lets an ordinary account (an EOA) sign an “authorization” that writes a pointer to a contract into the account’s code. From then on, any call to the account runs that contract’s code in the account’s own context. The delegation persists until the account signs a new authorization pointing to the zero address.
The feature was designed for batching and gas sponsorship. Within weeks of launch, criminals were also using it to attach automated “sweeper” contracts to wallets with leaked keys; Wintermute found that 97% of early delegations pointed to copies of one such contract, nicknamed CrimeEnjoyor. At Binance, the attacker applied the same idea to an exchange hot wallet. A single type-4 transaction sent by the operator wallet carried 50 authorizations for the address labelled “Binance 14” (0x28C6…1d60).
Figure 4. Authorization list of type-4 transaction 0xad99…298b on Blockscout. All 50 tuples carry Binance 14’s signature and point to the sweeper contract 0x63e8…6fAe; only nonce 18,914,809 was valid. Blockscout shows “any” in the Chain column, but the raw transaction data, which we pulled over RPC, has chain_id = 1 in all 50 tuples. The delegation was valid on Ethereum mainnet only.
Why fifty? Binance 14 kept sending routine transactions during the attack, and each one moved its nonce forward. An authorization only takes effect if its nonce equals the account’s current nonce. By obtaining a signature for every nonce from 18,914,775 to 18,914,824, the attacker made sure one would match whenever the transaction landed. The valid nonce was 35th in the range, which suggests the signatures were collected some time before they were used. TRM adds that the batching may mean signing access was time-limited, or that signatures had to be requested through a system. The second reading fits Binance’s “service container” account.
DETECTION NOTE A signing service being asked for 50 EIP-7702 authorizations for one account across consecutive nonces does not happen in normal operations. It is a high-fidelity indicator of compromise. Refusing that request would have stopped the Ethereum leg in this form. |
Three and a half minutes after the delegation took effect, at 20:24:23, the operator wallet called sweep() on Binance 14 with a list of 65 token addresses. In one call, 1.615 billion USDT, 62.6 million RLUSD, 29,934 WBETH, 11,372 XAUT and dozens of other tokens went to 0x5227…2f8c, together with 167,464 ETH. Elliptic values that single sweep at about $2.53 billion. The “$2.5 billion” figure that circulated early on comes largely from this transaction and from Binance’s first frozen-funds figure of $2.54 billion. It is not the total.
Figure 5. Token transfers in transaction 0x53bd…e2f3: the operator wallet calls sweep on “Binance: Hot Wallet” and every balance flows to 0x52…2f8c. First rows shown. Source: Blockscout.
The sweeper’s source code has not been published. In the bytecode the operator address is hard-coded, and every function checks that msg.sender is that address. The contract does three things: sweep moves the full balance of each listed token, the withdraw functions pull single assets, and callExecute forwards a call to another contract.
The last one matters. Binance 14 was the executor of a Binance smart account known as “Hot Wallet 34” (0xEe7a…4055). By taking over Binance 14, the attacker inherited that authority too, and used it at 20:41 to pull 780 million USDC out of the smart account, then another 43 million later. The delegation exposed more than the EOA’s own balance: it exposed every contract that trusted the EOA.
A note on sources: Blockscout now shows the sweeper as “verified”, but that code is a third-party, AI-assisted reconstruction from bytecode, and its header says so. It should not be cited as the attacker’s original source.
Figure 6. How Binance 14 was turned into a sweeper, and the seven withdrawals made while the delegation was live.
Once the delegation was in place, assets that arrived in the wallet later could be swept without any new signature. Balances that kept flowing into Binance 14 were taken again at 20:59, 21:04, 21:44, 22:39 and 23:56; the 21:44 sweep alone took 200 million USDT and 13 tokens that had arrived after the first one. Rotating keys or pausing withdrawals does not remove delegated code. The only fix is a new authorization to the zero address, signed by the same key. Binance sent it at 00:10:35 UTC on 30 October, in block 26301896.
Figure 7. Revocation transaction 0xafbf…7209: Binance 14 delegates its own code to the zero address. When we queried the address over RPC, eth_getCode returned an empty result (0x).
The 3 hours and 50 minutes between the first authorization and the revocation is the clearest operational lesson of this incident. Unexpected code on a treasury wallet can be detected with a single RPC call (eth_getCode). Getting revocation down to minutes requires a runbook that is written, assigned and rehearsed before it is needed.
Figure 8. Losses by chain (TRM Labs) and the current status of the stolen funds (Elliptic).
Ethereum accounts for about 60% of the loss. Much of it was held in stablecoins, which is also why freezes worked best there. Tether froze about 1.77 billion USDT in total and Circle about 823 million USDC. Ripple, World Liberty Financial, Paxos and First Digital froze their own tokens. At 00:08 on 30 October the Arbitrum Security Council forcibly moved 8,426 ETH and 74.6 million ARB out of the attacker’s address. As of Elliptic’s update at 13:10 UTC on 30 October, 44% of the stolen value ($2.84 billion) is frozen.
The rest is harder to reach. Before the freezes landed, the attacker converted stablecoins into native assets as fast as possible and almost regardless of price. Elliptic counts 434 million USDT swapped into 160,451 ETH via Uniswap, 1inch and market-maker RFQ quotes at a 12–26% loss. On Aave, 60 million USDT was posted as collateral to borrow 19,762 WETH. On Tron, 300 million USDT went into JustLend, and 234 million USDT was swapped for TRX on SunSwap and split across five addresses. The 18,270 BTC was peeled into 19 addresses, most holding 1,000 BTC, and has not yet reached a service. About $438 million in XRP, SOL and NEAR had not moved at all as of Elliptic’s latest update.
Dumping freezable assets for unfreezable ones at any price is typical of DPRK operations. Elliptic adds a caveat: the relatively slow pace of the stablecoin conversion in this case is unusual for DPRK.
Source | Assessment | Basis |
|---|---|---|
TRM Labs | TraderTraitor, high confidence | On- and off-chain intelligence; same playbook as Bybit (Feb 2025) and KelpDAO (Apr 2026): Tornado Cash funding, early staging, pre-obtained signatures used in one burst |
Chainalysis | Likely TraderTraitor | Stolen funds mixed in real time with proceeds of the Bitget theft (Sep 2026), also linked to DPRK |
Elliptic | DPRK likely, moderate confidence | Long preparation, staff targeting, abuse of the victim’s own signing systems, shared address with Bitget proceeds. Caveats: the overlap is small; slow stablecoin conversion is atypical |
ZachXBT, Blockaid | Likely Lazarus / DPRK | On-chain links |
Binance | No attribution | “Our investigation has not attributed responsibility to any individual.” |
FBI / US DoJ | No statement yet | For Bybit, the FBI attributed within five days |
THREATMON ASSESSMENT We consider the TraderTraitor attribution plausible, with moderate-to-high confidence. Three independent analytics firms working from different data point to the same cluster; the attack chain matches the “take the signing path, not the key” pattern TraderTraitor has repeated since 2024; and the laundering overlaps with proceeds of the Bitget theft. Three things keep us from “high”: the initial access vector is unknown, the Bitget link rests on what Elliptic itself calls a small overlap (laundering services can serve several clients), and no government has made an attribution. |
“Lazarus” is used in two ways. In the press it means North Korea’s whole offensive cyber apparatus. In MITRE ATT&CK (G0032) and in Microsoft’s naming (Diamond Sleet) it means a narrower espionage cluster. When the US Treasury sanctioned Lazarus Group in 2019, it listed two subgroups with it, Bluenoroff and Andariel, and tied all three to the Reconnaissance General Bureau (RGB), North Korea’s main foreign intelligence agency.
Figure 9. The clusters behind DPRK crypto theft, with vendor names, MITRE IDs and who made each attribution.
Crypto theft is spread across several of these clusters. BlueNoroff (APT38) built the playbook with SWIFT fraud, including the $81 million Bangladesh Bank theft in 2016, and moved into crypto with the $620 million Ronin bridge theft in 2022. AppleJeus, which Mandiant tracks as UNC4736, works through trojanized trading apps and supply-chain compromises such as 3CX; Drift Protocol attributed its April 2026 loss to the same actor. TraderTraitor is the cluster behind the largest single thefts. The FBI named it for DMM Bitcoin ($308 million, 2024) and Bybit ($1.46 billion, 2025), and LayerZero and TRM tied KelpDAO ($292 million, April 2026) to it.
Vendor names do not line up neatly. Microsoft calls TraderTraitor Jade Sleet, Mandiant calls it UNC4899, Unit 42 Slow Pisces, and CrowdStrike, since splitting its LABYRINTH CHOLLIMA umbrella into three in January 2026, PRESSURE CHOLLIMA. Mandiant describes the alignment of these groups to RGB units as “fluid” and assesses that TraderTraitor may include former APT38 operators. MITRE has no separate group entry for TraderTraitor. When a report says “Lazarus did it”, it is worth asking which cluster it means.
The group’s tooling is built for exactly the kind of target Binance described. CISA has documented since 2022 how TraderTraitor approaches system administrators and DevOps staff at crypto firms with well-paid job offers. Unit 42’s 2025 research describes “coding challenges” sent through GitHub that abuse PyYAML deserialization to deliver RN Loader and RN Stealer. RN Stealer collects the macOS keychain, SSH keys and AWS, Kubernetes and GCP configuration, which is what sits on a DevOps engineer’s laptop.
In the ThreatMon platform
ThreatMon’s Threat Actor Monitoring module tracks Lazarus Group as G0032 and lists TraderTraitor among its associated groups, together with APT37, Operation Sharpshooter and Stardust Chollima. The profile covers the sponsor, motivations, targeted sectors and countries, related CVEs and tooling, and links through to MITRE techniques, campaigns and IOCs.
Figure 10. Lazarus Group profile in ThreatMon’s Threat Actor Monitoring module (last modified 30 September 2026). TraderTraitor is listed under associated groups.
Threat Actor Monitoring: threatmon.io/solutions/threat-actor-monitoring
The interest in trusted infrastructure is not limited to crypto. In September we analyzed a DPRK-linked Linux toolkit found at two South Korean organizations, where the backdoor was compiled directly into a production HAProxy load balancer. That activity is not attributed to a specific cluster, and we do not link it to Binance. What the two cases share is the choice of target: a component other systems trust by default, where malicious activity blends into legitimate traffic.
Read: The Load Balancer as a Backdoor: Investigating DPRK-Linked Tradecraft Inside HAProxy
Figure 11. The largest DPRK-attributed thefts and yearly totals. Binance is larger than the previous four years combined.
Chainalysis puts DPRK-linked theft at $1.7 billion in 2022, $660 million in 2023, $1.34 billion in 2024 and a record $2.02 billion in 2025. Elliptic counted more than $1 billion in 2026 before Binance. If the Binance attribution holds, the 2026 total passes $7 billion, more than the previous four years together. None of the 2026 thefts, Binance included, has a government attribution yet.
The laundering playbook has moved with enforcement. After Treasury sanctioned the Blender and Sinbad mixers, and Tornado Cash until its 2025 delisting, DPRK proceeds shifted to cross-chain swaps through THORChain and no-KYC swappers such as eXch, as with Bybit, and then to Chinese-language OTC and guarantee networks. FinCEN cut Huione Group off from the US financial system in October 2025, calling it a critical node for laundering DPRK heist proceeds. Chainalysis describes a laundering cycle of roughly 45 days. In our assessment, that makes the coming weeks the main window for tracing and freezing the ETH and BTC that are still in the attacker’s hands.
DMM Bitcoin (via Ginco) | May 2024, ≈ $305M | Fake recruiter and Python test sent to a Ginco employee | A manipulated legitimate transaction request | FBI: TraderTraitor |
Bybit (via Safe{Wallet}) | Feb 2025, ≈ $1.46B | Safe developer’s Mac, trojanized Docker project | A transaction altered by JavaScript injected into the Safe UI | FBI: TraderTraitor |
KelpDAO / LayerZero | Apr 2026, ≈ $292M | Code injected into RPC nodes on two Kubernetes clusters | A forged cross-chain message | Reported: Lazarus / TraderTraitor |
Bitget | Sep 2026, ≈ $352–388M | Zero-day in third-party security appliances | Withdrawals approved against spoofed data | DPRK likely (Elliptic); TRM low–moderate |
Binance | Oct 2026, ≈ $6.3B | DevOps laptop → service container | Unauthorized withdrawals signed by Binance’s own signer | TRM, Chainalysis: TraderTraitor |
In none of these cases did the attacker steal a key from cold storage. Each time, the victim’s own approval or signing mechanism signed a request that arrived through a trusted channel. “Our keys are in an HSM” or “we use MPC” is not a security guarantee on its own. The question to ask is who, or what, decides what the signer signs, and on what basis.
Tactic | Technique | In the Binance incident | Evidence |
|---|---|---|---|
Resource Development | T1587 Develop Capabilities | Sweeper contract written and deployed four hours early; operator wallet funded via Tornado Cash | On-chain |
Initial Access | T1566.003 Spearphishing via Service, or T1195 Supply Chain Compromise | DevOps engineer’s laptop compromised; method not disclosed | Event confirmed, technique assessed |
Lateral Movement | T1550 Use Alternate Authentication Material; T1078.004 Cloud Accounts | Access from the laptop to a service container | Binance statement |
Execution | T1609 Container Administration Command | Unauthorized withdrawal requests submitted from the container | Binance statement |
Persistence | T1098 Account Manipulation (closest fit) | EIP-7702 delegation writes the sweeper into Binance 14’s code | On-chain |
Impact | T1657 Financial Theft | ≈ $6.3B moved out across 10 chains | On-chain |
ATT&CK has no technique for EIP-7702 delegation abuse; T1098 is the nearest equivalent.
Signing service
On-chain monitoring
Developer and DevOps endpoints
Response readiness
Type | Value | Role |
|---|---|---|
ETH address | 0x7C8601d4645b93cea45F71e118A729332e6B5CA0 | Operator: deployed the sweeper, sent the type-4 tx and all sweep calls |
ETH contract | 0x63e842B054Bd624a465454D533C33F573e9c6fAe | Sweeper (EIP-7702 delegation target) |
EVM address | 0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c | Main collection address (Ethereum, Optimism, Arbitrum, Avalanche) |
ETH address | 0x8532FA14ACAf483729C449b8458aedDb900543D4 | ETH consolidation (≈ 195,460 ETH) |
Tron address | TPBkSjkCMn2ckrMuAP8n2J1jdjbw76bKN4 | Elliptic blocklist |
Tron address | TG5iBMQPrDzJJAUM8GMVBf1hRaJ1wvzsGi | Elliptic blocklist |
XRP address | rK21t6nGLy4MNDqhvy3pGwcLFy25qgfzMx | Elliptic blocklist |
Solana (likely) | AffzFDKZbyMiU11zmVBoAqD25ugpr7xoWWyRyGigBEaU | Elliptic blocklist |
Solana (likely) | 9SkjwUs5pRRQQo5a6g4m5cciy1xLdDeFnaov24htTjdQ | Elliptic blocklist |
ETH tx | 0x97408e7562eb2b28efcd24ba01609607b5749bc89448d007fa8b50ecf290329c | Sweeper deployment, block 26299449 |
ETH tx | 0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b | Type-4 tx, 50 authorizations (20:20:59) |
ETH tx | 0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3 | First sweep (20:24:23) |
ETH tx | 0x51f263fa50966df6bbd7f8c6e6e99e3791c94444f7c4343b2fef1ee2d62fd39f | Binance 16 sends 28,005.6 ETH directly to 0x5227… (20:24:47) |
ETH tx | 0xdc102dd89dded5a83f1008906883ffb7c81ff3b7d7965d8c7277d170b5e17481 | callExecute, 780M USDC from Hot Wallet 34 (20:41:23) |
ETH tx | 0x55ba4dabc41b468e580751373ad31acdee6f5ba398682df2c93e5a8340870556 | Second sweep (21:44:11) |
ETH tx | 0xafbf94c92a8d749988411669fa14d4f8866d9b4420b4ebd299f28e958dac7209 | Binance revocation (30 Oct 00:10:35) |
Behavioral | EIP-7702 authorizations for one account across nonces 18,914,775–18,914,824 | Signing-pipeline compromise pattern |
All Ethereum transactions above were checked against mainnet by ThreatMon. The following are Binance’s own addresses and should not be blocked: Binance 14 0x28C6c06298d514Db089934071355E5743bf21d60, Binance 16 0xDFd5293D8e347dFe59E90eFd55b2956a1343963d, Hot Wallet 34 0xEe7aE85f2Fe2239E27D9c1E23fFFe168D63b4055. Elliptic’s full blocklist (45 entries) is at data-cdn.elliptic.co/blocklists/binance-hack-blocklist.csv.
We will update this post as new findings come in.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
