The Binance Hack: 6 Security Questions Every Bank Should Ask

By Oded Blatman. Updated November 1 2026.

When I was CISO of a large bank, our risk appetite was managed and minimal, and it was never zero, because zero does not exist in our business. The question was always how much one failure could cost us, and at what speed? Today that question is harder to answer. AI is making attackers faster, and blockchain infrastructure adds paths to a signature that bank controls were never designed for. 

In brief

• What happened. About $6.3 billion was drained from Binance's hot wallets on October 29. Binance says the attackers used an Ethereum delegation to bypass its normal approval procedures and that it found no evidence a private key leaked. The FBI attributes the theft to North Korea.
• Why it matters to banks. The failure was the path to a valid signature. A bank's first impact from a venue hack is liquidity and counterparty exposure, not a breach.
• What to do. Ask the six questions below to your team and your vendors this week.

What happened

On October 29, attackers drained about $6.3 billion out of Binance's hot wallets (internet-connected wallets kept online for withdrawals) across ten blockchains, most of it in about 20 minutes from 20:05 UTC (TRM Labs). Binance has said it found no evidence that a private key leaked, and that the attackers used an Ethereum delegation to bypass its normal approval procedures. It has not published a root cause, and no cryptographic break has been reported. The failure was the approval layer, the point where a transaction gets signed off. On October 31 the FBI attributed the theft to North Korea's TraderTraitor unit, the same unit behind the Bybit hack.

What is known of the sequence:

1. Entry. Binance's early finding is a compromised DevOps engineer's laptop that reached a service container able to submit withdrawals. It has since found additional points of breach and says the attackers used a self-destruct mechanism to erase evidence. We do not yet know the full extent of what was compromised.
2. Staging, visible for about 36 hours. The attackers began preparing at least a day before the theft, using funds withdrawn from Tornado Cash to finance their operations and testing their attack code on wallets.
3. One signed message turns a hot wallet into the attacker's. On Ethereum, the attacker submitted 50 pre-signed permissions that let a Binance hot wallet run the attacker's code, and one of them worked. On the other nine blockchains, Binance wallets simply sent funds out through ordinary signed transfers. TRM Labs reads this as a compromise of Binance's signing system. Binance says no key leaked, so the signing path is the likely weak point, though it is not confirmed.
4. A race against the freezes. Issuers froze about $2.8 to $3 billion (Chainalysis), but bitcoin and ether cannot be frozen. The Ethereum delegation stayed active until 00:10 UTC on October 30, almost four hours after the first sweep, and deposits reportedly kept being swept.
5. Response. Binance set aside $6.34 billion and began reopening withdrawals in phases on November 1, saying about 95% of the impacted amount is covered.

In the 2025 Bybit attack, attackers manipulated what approvers saw before signing. At Binance, the available evidence points to attackers exploiting an automated signing process. (FBI).

Six questions for banks to ask

1. Can one compromised workstation or credential ever reach signing?

The weak point appears to have been the path from an engineer's endpoint to the authority that moves funds. 

Map every route from a developer laptop, build pipeline, service account or vendor tool to anything that can request, approve or submit a signature, including security tools with reach to signing hosts. 

No single machine or credential should reach signing infrastructure on its own. Engineers who can modify signing or deployment systems should be treated as as tier-0: privileged-access workstations, short-lived credentials. Credentials should require two-person approval, while build, deplyment and signing environments remain seperate. 

2. How much sits in hot wallets, and what stops the refills?

The amount held in hot wallets determines how much could be lost in a single incident. Set that exposure according to your institution's risk appetite.Refill it in limited tranches, with velocity limits and a circuit breaker that halts the top-ups too: the compromised Ethereum wallet stayed delegated for almost four hours, and new deposits were reportedly swept again. Keep the bulk cold, put warm wallets behind delays and multi-party approval, and isolate infrastructure per chain and tier so one breach cannot sign everywhere. At Binance, one breach reached ten chains in minutes.

3. What can your signer be asked to sign, and who checks it?

Signing rules belong in a policy engine on isolated infrastructure, such as an HSM (a tamper-resistant device that checks rules before it signs) or the protected environment of an MPC node. The decision that a transaction is allowed must never come from outside it. This does not depend on HSM versus MPC. 

Four critical points :

• Deterministic checks. Parse each payload and refuse non-standard ones by default (delegations, raw and typed-message signing, unlimited approvals). Refuse nonces far ahead of the account's. Enforce a destination allowlist with a delay on changes, and hard caps.
• Simulation. Decode and simulate every request, so approvers see who gets what, not a hash.
• Independent approval. For large transactions, new destinations, unusual transaction requests and policy changes, a quorum confirms decoded details on a device the upstream stack cannot draw on (Clear Signing). Policy changes need the same quorum plus a delay.
• Your own addresses. Confirm none of your EVM addresses carries code or a delegation, and alert if that changes. Minimise the roles they hold in other contracts, because a permission can cost more than a balance.

What this will not stop. A within-policy request to an allowlisted address. Plain transfers on other chains, which the allowlist, caps and quorum stop, not payload parsing. A coerced quorum. And a policy is only as good as its parser, which needs its own testing.

4. How fast can you see and stop it?

Most of the stolen funds left within about half an hour. The first unauthorised transfers were visible on-chain from 20:05 UTC, while signs of preparation had appeared roughly 36 hours earlier. This highlights why detection needs to work at mutiple levels. 

The first layer is deterministic: the signing infrastructure should enforce strict checks on transaction type, nonce, destination, size and velocity. At Binance, only one of 50 authorizations matched the nonce, a signal no model is needed to catch. 

The second layer uses those signals to identify more complex patterns of suspicious activity. Baseline each signer and wallet, then use machine learning to flag combinations fixed thresholds miss, such as a first-time destination at an unusual hour or a contract hours old and funded through a mixer. AI can also help assess suspicious wallet and smart-contract behaviour and identify discrepancies between a transaction request and the underlying business instruction. Use them to escalate, never to approve what policy forbids.

• Reconcile every outbound transfer against an authorised order within minutes, and treat an unmatched transfer as an incident.
• Watch for staging signals: a fresh mixer-funded wallet deploying a contract, one transaction carrying many authorizations, code appearing on a plain wallet.
• Keep a kill switch measured in minutes, one that does not depend on systems that might be compromised, with out-of-hours authority and tested freeze channels to issuers, intelligence firms and law enforcement. Run detection on a plane separate from custody, and treat any monitoring vendor with reach to signing as tier-0.

5. Who will attackers target, and how do you protect them?

State-level actors go after engineers with social engineering and malicious code, such as fake recruiters, coding tests and poisoned packages. Privileged staff need hardened dedicated workstations, phishing-resistant multi-factor authentication and tight control of CI/CD and secrets, and reports of suspicious approaches should carry no blame. Then test it. Replay the whole chain in an assume-breach exercise from an assumed laptop foothold, measure time to detect and time to halt against the 20 to 30 minutes this attacker needed, and plant honeytokens, a decoy signing endpoint and a canary wallet where an intruder would look.

6. How much of your value sits at venues, and could you survive a multi-day freeze?

You cannot stop an exchange from being hacked. You can control how much of your value sits there and what you do next. Binance set aside more than $6.34 billion to make users whole, yet withdrawals were paused from 22:33 UTC on 29 October and phased reopening began on November 1. Anyone who needed those assets in that window had a liquidity problem, not a loss.

• Minimise. Prefer settlement where assets stay with your own or a qualified custodian and the exchange extends credit against them. Where prefunding is unavoidable, size to the trading need, sweep back often, and set hard per-venue limits.
• Plan for a freeze. Diversify venues and keep a tested multi-day playbook: client communication, hedging, collateral calls and regulatory notification.
• Ask for evidence, not questionnaires: where policy is enforced, the hot, warm and cold split and caps, how engineers' access is controlled, the last independent red-team and its findings, proof of reserves including liabilities, segregation, insurance and incident history.
• Contract for it: incident notice within hours, loss allocation, audit rights, and termination rights after a material incident.

What are we watching next?

• Binance's technical post-mortem: the root cause, how the laptop was compromised, how valid signatures were obtained, and which controls failed.
• Binance's updated proof of reserves.
• Where the unfrozen funds go, and whether more freezes or law-enforcement actions follow.

Where does Ledger Enterprise fit?

Ledger Enterprise is built around the approval layer. For banks, the design claim is this: approval and policy sit in hardware the institution controls, outside any application stack an attacker could reach. Keys live in HSMs, with per-account policy enforced inside them. Approvers confirm decoded details on a Ledger Stax with Clear Signing, and policy changes need a quorum of your own administrators. 

With HSM On-Premise, the signing HSM and seed stay in your own data center, with governance operated by Ledger in its own HSMs. TradeLink keeps assets under a pledge model until settlement, with exchanges on its network.

How Ledger Enterprise can help you bound the next incident

The Binance attackers needed one thing: a valid signature that no one with authority had approved. 

Ledger Enterprise is designed so that, for accounts whose policy requires approval, a compromised laptop, credential or service cannot produce a signature the HSM-enforced policy forbids, and cannot change that policy without a quorum of your own administrators. It cannot make a policy-compliant request safe, so limits, allowlists, monitoring and reconciliation still matter, and questions 4 and 5 stay with your security team or custodian. The objective is to limit potential losses to the thresholds your institution has defined.

No vendor closes all six questions alone, so we start by answering them with you, with evidence: an architecture review, current certification status, independent audit and red-team results, and a clear map of what Ledger owns and what you own. The question for your risk committee is no longer whether a signing path can be attacked. It is how much one compromised path can reach.

Existing customers can contact their Customer Success Manager or Technical Account Manager. Want to become a Ledger Enterprise customer? Talk to our team. For a closer look at a signing-path attack, read Learning From The Bybit/Safe Attack.

Ledger Enterprise is a technology provider, not a regulated financial institution, custodian or Crypto Asset Service Provider (CASP).