The Binance Breach Wasn’t a Crypto Failure: It Was a Trust Failure | Harness Blog

Terms in plain language

• Hot wallet: a crypto wallet connected to the internet, which exchanges use to process withdrawals quickly.
• Private key: the secret code that proves you own crypto and lets you move it.
• Signing: approving a crypto transaction with a private key. Binance's "signing system" is the software that does this for withdrawals.
• Mixer (such as Tornado Cash): a service that hides where crypto came from. The attackers used one to fund their wallet.
• Frozen funds: crypto that a stablecoin company or blockchain network has blocked from moving.
• SAFU: Binance's emergency fund, set aside to cover user losses.
• Seed phrase: the list of words that can restore a wallet. Anyone who has it controls the wallet.

What happened

The theft began late on Thursday, October 29. Within minutes, users were reporting drained wallets. Binance first said only that it was investigating a potential security issue and that customer funds were safe. Later that night it confirmed that assets had been affected, paused all deposits and withdrawals, and promised to cover every loss.

The picture filled in over the next three days. On October 30, Binance named a compromised engineer's laptop as a possible entry point, and investigators traced the money across ten blockchains. On October 31, the FBI named North Korea. On November 1, Binance began reopening withdrawals in phases.

Are my funds safe?

Binance says user funds are safe and that it, not its customers, will absorb the loss. It says it has replaced about 95% of the stolen amount from its own money, including SAFU (an emergency fund it keeps for users), and it plans to publish a new proof of its reserves on November 3. About $3 billion of the stolen crypto has also been frozen by stablecoin issuers and blockchain networks, which stops it from being moved.

Withdrawals are scheduled to reopen in phases from November 1, so some coins may become available before others. These are Binance's own statements, and we have not independently verified them. One analyst quoted by CNBC does not see a meaningful risk to Binance's ability to stay solvent.

How the attack likely worked

The most likely path, based on what Binance, TRM Labs and Chainalysis have said, is a developer-endpoint compromise that reached the infrastructure that authorizes withdrawals, followed by a rehearsed, pre-signed theft. The reported sequence:

1. Initial access (timing unknown). Binance says a DevOps engineer's laptop may have given an attacker access to a service container tied to withdrawals, and that investigators found additional points of breach.
2. Preparation (from October 28). The attacker's operator wallet was funded with a Token Mixer using small Tornado Cash withdrawals at least 36 hours before the theft.
3. Rehearsal (October 29). The attacker tested its code on test wallets, with a final rehearsal about four hours before the main attack.
4. Control of signing. The attacker gained the ability to make Binance's hot-wallet signing system approve transactions of its choosing, across chains with different key types and signing schemes.
5. Execution. The money left fast. Funds went out on ten blockchains in about 20 minutes, which gave Binance and its partners very little time to react. Signatures obtained in advance were used in one burst across ten chains.

An attacker who controls the signing and withdrawal layer can move funds without ever extracting a key. That is why we treat the signing layer, not the key material, as the primary suspect.

On EIP-7702: TRM Labs and Chainalysis both describe it as the Ethereum-side mechanism. The attacker prepared 50 signed authorizations to cover uncertainty about the wallet's nonce at execution time, and they pointed a Binance hot wallet at a sweeper contract that only the attacker's wallet could operate. It does not explain the other nine chains: wallets there, using different key types and signing schemes, sent funds to the attacker within the same half hour. That is why the signing and withdrawal layer remains the primary suspect.

On attribution: the FBI said on October 31 that North Korea was responsible. TRM Labs attributes the attack to TraderTraitor with high confidence, citing on-chain and off-chain intelligence and a match with the Bybit and KelpDAO tradecraft. Chainalysis saw stolen Binance funds mix on-chain with proceeds of last month's Bitget theft, which was attributed to North Korea. We treat attribution as well supported. Defensive priorities are the same whoever the actor is.

The attack was rehearsed before it was executed

The attackers did not improvise. Investigators at TRM Labs traced their preparation to the morning of October 28, at least 36 hours before the theft. They funded a wallet through a service that hides where money comes from, practiced their code on test wallets, and ran a final dry run about four hours before the real thing. 

The money moved in minutes, but the groundwork took more than a day and a half.

Source: TRM Labs analysis

What we do not yet know is how long the attacker had access to Binance's systems before that rehearsal began. That is the key unanswered question, and Binance has not said.

Why it matters. Rehearsal creates a window in which a defender might notice something, such as a mixer-funded wallet, a new contract or test-sized transfers. That only helps if someone is already looking for those signals, and if the controls that follow can act within hours.

Who was behind it, and can the money be recovered?

The FBI said on October 31 that North Korea was responsible. Two blockchain-analysis firms, TRM Labs and Chainalysis, attribute the attack to a North Korean hacking group called TraderTraitor, the same group the FBI blamed for the Bybit theft. Chainalysis also saw some of the stolen Binance money mix with funds from another theft last month, at the exchange Bitget, which was attributed to North Korea.

Freezing crypto stops it moving, but it is not the same as getting it back. Returning frozen money requires a separate legal process, according to a TRM Labs executive quoted by CNBC. TRM says the attacker holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion in assets that no issuer can freeze. That is the part that matters for recovery, and investigators are racing to track it as it’s laundered.

Not everything can be frozen. Companies like Tether and Circle can freeze their own stablecoins, but no company controls bitcoin, ether, solana or most other coins, so those can only be stopped if exchanges and other services refuse to handle them. The FBI has asked the industry to block the attacker's addresses.

The attacker is still moving the money. Reporting from November 1 shows it swapping stolen coins, for example solana into bitcoin, and passing funds through automated chains of wallets around the clock, often through swap services that work across blockchains. TRM estimated about $2.4 billion beyond any company's reach as of October 30, and Elliptic now estimates about $3.3 billion. Investigators are racing to track it as it is turned into cash.

The red path is the one investigators worry about: once stablecoins become ether, no company can block them, which is why speed matters in freezes.

Does this mean exchanges are unsafe?

The breach is being read as an argument against centralized exchanges. We think the evidence is narrower: it shows how much value can sit behind one operational path, not that self-custody is safer.

• Concentration is the core risk. A custodial exchange pools value behind a few signing and withdrawal systems, so one compromised identity can move billions in minutes. Bybit and KelpDAO fit the same pattern.
• Decentralized systems share the weakness. Bridges, multisig signer sets, admin keys and upgrade permissions often depend on a handful of people and laptops, so the same path, a developer endpoint reaching signing infrastructure, applies to many of them.
• Custody gave users recourse this time. Binance pledged to cover losses, and Circle, Tether and Ripple froze funds on the day of the theft. A self-custody user whose wallet is drained usually has no equivalent. Those freezes also depend on centralized stablecoin issuers.
• Self-custody moves the risk to the user. Phishing, seed-phrase handling and malicious approvals are the same scams we expect over the coming days.

Our view: neither model removes trust; each relocates it. The more useful question for any platform is whether one compromised person or service can act alone, and whether outflows have limits and independent approval. We take no position on which model is better overall, since that depends on how users weigh convenience, recourse and sovereignty.

Recommendations

The most useful steps this week are for individuals to avoid scams, and for engineering teams to test whether one compromised engineer can reach anything that moves value. This is security guidance, not financial advice.

For individual users

• Distrust every message about the hack. Expect fake emails, texts, direct messages and ads offering compensation, refunds, "wallet verification" or news that withdrawals are back. Open only the official Binance app or an address you bookmarked yourself, never a link in a message.
• Never share your seed phrase or a 2FA code. No real refund or recovery needs either one.
• Never connect your wallet or approve a transaction on a site that promises a refund.
• Strengthen your sign-in. Use a passkey or hardware security key if your account offers one, set an anti-phishing code and a withdrawal address allowlist if available, and delete API keys you no longer use.
• Check your account. Look at recent logins, signed-in devices and saved withdrawal addresses now, and again when withdrawals reopen.
• Think about how much you keep with any single company. Even when losses are later covered, as Binance says they will be here, you can be locked out for days.

If you build or run software

The route used here, from one employee's laptop to a system that can move money, exists in many companies. If you lead engineering or security, ask this week: could one compromised engineer reach anything that moves value, and would anyone else have to approve it? 

For engineering and security teams (short term)

• List every engineer and service account that can reach production, signing, payment or release systems from a laptop.
• Rotate long-lived secrets and tokens that live on developer machines or in build containers.
• Confirm that no single person or service can approve and execute a high-value action alone.
• Brief staff on lures aimed at developers, such as fake recruiter tests and malicious packages. 

For engineering and security teams (long term)

• Run a tabletop exercise: a developer laptop is compromised and the attacker reaches a production container. What can they sign, deploy or withdraw, and how fast would you know?
• Add outflow or change-rate limits and an automatic circuit breaker to any system that moves money or ships to production.
• Move deploy and signing permissions to short-lived, scoped credentials and policy-gated pipelines with audit trails.
• Add detection for long-dormant access and for staging activity that precedes a burst of actions.