The $6.3B Binance hack: stop it before the signature

The $6.3B Binance hack: stop it before the signature

Yarin Vaknin

Yarin Vaknin

CTO at Corsa

In short: On October 29, attackers drained about $6.3 billion from Binance hot wallets, the largest crypto theft on record. They didn't break any cryptography and they didn't go through Binance's withdrawal system. They took over the wallets and signed transfers directly, so every check that lived inside the withdrawal pipeline never ran. The lesson for every exchange, custodian and fintech holding crypto: your last line of defense has to sit in front of the signature, and it has to know what normal looks like for each of your wallets.

What happened

Binance's first finding was a compromised DevOps engineer's laptop that gave the attackers access to a service container. Binance said the attack involved more than one person. Chainalysis, Elliptic and TRM Labs tie it to North Korean groups, and TRM links it to the group behind the Bybit hack. Binance hasn't published a final attribution.

The attackers prepared for at least 36 hours. Small withdrawals from Tornado Cash funded an operational wallet, and the code was tested on three wallets first, according to TRM.

Then it moved fast. All times are UTC on October 29:

  • 20:20. One transaction submitted 50 EIP-7702 authorizations for the hot wallet "Binance 14", each with a different nonce. One of them was valid. EIP-7702 lets a wallet delegate its behavior to other code, so that single valid authorization handed control of the wallet to the attacker.

  • 20:24. One transaction moved 167,464 ETH, about 1.6 billion USDT and around 60 other tokens out of that wallet, roughly $2.5 billion, leaving about 1 ETH behind.

  • The next 20 minutes. TRM says most of the funds were gone within 20 minutes. Bitquery counted 17 hot wallets drained across 9 networks, and TRM put the total at $6.36 billion across ten chains: $3.79 billion on Ethereum, $1.47 billion in bitcoin, $628 million on TRON, $296 million in XRP and smaller amounts on Solana, Arbitrum, Optimism, Base, Avalanche and Polygon.

  • The next four hours. Draining continued for hours. The delegation was revoked shortly after midnight.

The laundering started within minutes. The attackers swapped about $729 million of USDT into ETH and TRX through Uniswap, UniswapX, 1inch Fusion and SunSwap, accepting losses of up to 26% to get out of freezable stablecoins quickly. Tether blacklisted 11 wallets, but six were already empty, and one moved 130 million USDT less than a minute before its freeze.

Binance suspended deposits and withdrawals and said customer funds weren't touched. It covered the loss with company funds. Binance says about $3 billion has since been frozen, with Tether, Circle and Arbitrum's Security Council among those freezing funds.

Into DeFi within half an hour

About 34 minutes after the big outflow, an attacker wallet posted 60 million USDT as collateral on a large DeFi lending protocol and borrowed about $44.6 million in WETH. No protocol was exploited: the attacker used a lending market the way any user can. The likely aim was to turn freezable USDT into WETH, which no issuer can freeze.

The DeFi teams involved moved fast. Security teams formed war rooms within minutes, froze affected markets as a precaution and left their protocols with no bad debt. Other lending platforms paused markets until the picture was clear.

The takeaway for compliance teams: stolen funds now hit lending protocols, DEX aggregators and intent markets within half an hour. If you only learn about a hack from the news, the money has already moved.

Why the withdrawal checks didn't help

Most exchanges put their controls inside the withdrawal service: limits, address allowlists, risk scoring, manual review for large amounts. Those controls only run when a withdrawal goes through that service. The Binance attackers didn't use it. They controlled the wallets themselves and signed from there.

That points to three things a control needs to stop an attack like this:

  1. It sits in front of the signature. Nothing gets signed until the control says yes, however the transfer was started.

  2. The attacker can't forge its answer. If the approval key lives in the same environment the attacker owns, they can approve their own transfer.

  3. It knows what normal looks like. A hot wallet that has never sent $2.5 billion in one transaction, never signed an EIP-7702 authorization and never paid that address before should be stopped on any one of those signals.

How Corsa protects your wallets

Corsa is a real-time transaction monitoring and compliance platform for crypto and fintech companies. Here's how it handles each stage of an attack like this one.

Signing Firewall: decisions before the signature

Corsa's Signing Firewall connects to your custody platform's co-signer. It works with Fireblocks and Utila today. Every outgoing transfer from a protected wallet is sent to Corsa before it's signed, including transfers started outside your withdrawal service, from the console or from a compromised machine. Corsa runs your rules and answers in under a second:

  • Approve when nothing fires.

  • Reject when a blocking rule fires. The transfer is never signed.

  • Hold for review while an analyst decides, with the co-signer asking again until they do.

  • Defer to approvers to send it to your own human approval quorum.

Corsa's approval is signed with a key in Corsa's key management service, not in your environment. An attacker who owns your servers, as in the Binance case, can't forge it. If Corsa can't evaluate a transfer, it never approves it: protected transfers fail closed. You choose which wallets are protected and which rules decide, and you can run everything in shadow mode first to see exactly what Corsa would have blocked.

Behavioral monitoring for your own wallets

Most monitoring is built around customers. Corsa also models your hot, omnibus and treasury wallets as house accounts, with their own history and baselines, so every behavioral check works on them too:

  • Hard caps on any single transfer from a hot wallet.

  • Value velocity over 10-minute and 1-hour windows, per wallet and across all your wallets together, counting blocked attempts so an attacker can't slip under the limit by retrying.

  • First-time destinations combined with a large amount. Addresses on your custodian's allowlist count as known.

  • Baseline anomalies: amounts far outside a wallet's 90-day history, sudden velocity spikes, dormant wallets waking up with large transfers, activity at unusual hours and sessions from new devices or VPNs.

In the Binance case, the $2.5 billion transaction trips the hard cap, the baseline and the first-time destination rule at once. The transfers that followed in the next 20 minutes trip velocity across wallets.

Operation controls: block what a hot wallet should never sign

A hot wallet that pays out withdrawals has no reason to sign raw messages, typed data or wallet upgrades. Corsa looks at what's being signed, not only how much is moving, and lets you block:

  • raw signing from protected wallets,

  • typed-message signing,

  • contract calls to anything outside your allowlist of contracts and methods,

  • wallet upgrades and delegations, including EIP-7702 authorizations.

The Binance attack started with an EIP-7702 delegation. With operation controls on, that authorization is never signed, and the drain never starts.

Live address risk at the moment of decision

Corsa checks every destination address against Chainalysis and TRM Labs while it decides, along with sanctions lists such as OFAC's crypto addresses. Addresses linked to hacks, known hacker groups, mixers or sanctioned entities can block or hold a transfer before it's signed. Results are cached, so the check stays inside the decision time.

Watching the controls themselves

A careful attacker tries to switch the guard off first. Corsa watches for that:

  • Policy-change monitoring. New allowlisted addresses, edits to custody policy rules covering protected wallets and attempts to re-point the co-signer callback raise an alert and can be rejected.

  • Bypass detection. If a transfer from a protected wallet completes without passing through Corsa, you get a Sev-1 alert within seconds.

When stolen funds come to you

Most of our customers won't be the next exchange that gets hacked. But after a hack like this, stolen funds spread to exchanges, OTC desks, payment companies and DeFi front ends within minutes. Corsa screens incoming deposits against hacked-funds and known-hacker-group labels and traces them back across several hops, so you can halt a deposit and freeze the account before the funds move on. Corsa also flags customers who send funds into lending pools and DEX routes that attacker-linked wallets are using, like the lending position in this case, so you can act while freezes are still possible.

From alert to action in seconds

Every decision lands in Corsa with the rules that fired, the wallet's history and the address risk. Corsa's AI triage summarizes what happened and escalates to a case, and workflows notify your team on Slack, email or webhook. In the Binance case, roughly 84 minutes passed between the big withdrawal and the first press report, and the drain went on for hours. An alert in the first seconds is the difference between losing one wallet and losing seventeen.

What to do now

  1. Map who can sign. List every way a transfer from your hot wallets can get signed: your withdrawal service, the custody console, API users and admins. Any route without a check is the route an attacker will use.

  2. Put a check in front of the signer. Make sure every route from a hot wallet passes a control that the attacker can't approve from inside your environment.

  3. Block operations you never need. Hot wallets that only pay out shouldn't sign raw data, typed messages, delegations or unknown contract calls.

  4. Set caps and velocity on your own wallets. Treat your house wallets like your riskiest customers.

  5. Watch the policy, not only the transactions. Alert on allowlist changes, policy edits and callback changes.

  6. Screen what comes in. Make sure incoming deposits are checked against hack labels in real time, not in tomorrow's batch.

If you're a Corsa customer using Fireblocks or Utila, your Corsa representative can switch on the Signing Firewall in shadow mode. You'll get a report of what Corsa would have blocked over the last 14 days before you turn on enforcement. If you're not a customer yet, book a demo and we'll walk you through it on your own wallets.

Sources

Go live in less than 2 weeks
Go live in less than 2 weeks

Upgrade your compliance operations instantly, with no technical debt or complex setup.