5 Lessons from the $6.3 Billion Binance Hack

On October 29, 2026, attackers drained about $6.3 billion in crypto from Binance hot wallets. It is now the largest crypto theft on record, passing the Bybit hack that held the record before it. Binance says the FBI has attributed it to North Korea.

The theft itself took a few hours. The campaign behind it took months. Binance CEO Richard Teng called it a campaign built over many months, and the details the exchange shared on November 3 back that up: a fake job interview, a tampered developer tool, lateral movement into the wallet team, and finally abuse of an Ethereum feature called EIP-7702.

None of the individual steps were new. What made this work was how they were chained together. Here are five lessons every security team should take from it, whether you run an exchange or not.

1. Recruiting is now an attack channel

The main entry point was a job offer. In September, a Binance software engineer was approached on a legitimate job platform by someone posing as a project director. A fake HR person interviewed him over video and shared a social media account full of personal photos to build trust. A second interview with a supposed CEO ended with a coding assignment to download. He ran it on his work laptop. It carried zero-day malware that got past endpoint security.

The engineer's profile mentioned his work at Binance. That alone made him a visible target. Binance says employees in non-public roles are not supposed to keep LinkedIn profiles at all, and that it had already flagged earlier attempts to target staff on the platform.

What to do:

Treat "take-home test" and "run this repo" requests as a known threat pattern in security awareness training, not an edge case.
Ban running outside code on work machines. Give engineers a disposable VM or sandbox for anything from an unknown source.
Look at what your staff's public profiles reveal. Job titles like "wallet infrastructure" or "payments platform" are a targeting list for attackers.

2. Developer tooling is part of your attack surface

The fake interview was not the first foothold. In June, a different engineer searched for an AI tool, clicked an internet ad, and installed a tampered version of Homebrew instead of getting it from the official source. Binance detected it, removed it, and replaced the device.

But the damage was already done. Before it was caught, the attackers learned about that engineer's role and about the people who managed the company's wallets. That knowledge shaped who they went after next.

Developers install packages, CLIs, extensions, and AI tools all day. Each one runs with the developer's own access. Attackers know search ads and lookalike download pages are an easy way in.

What to do:

Pin approved sources for package managers and dev tools. Block installs from random download pages on machines that touch production.
Keep an allowlist of AI tools and browser extensions for engineering teams.
When you clean up an infected machine, assume the attacker already took notes. Ask what they could have learned about people, roles, and systems, not just whether the malware is gone.

3. One compromised laptop should never reach the wallets

Binance says it detected and blocked 57 North Korea-linked attempts in 2026. Attempt 58 is the one that mattered. Defenders have to win every time.

Here is how the foothold turned into access to money, based on Binance's timeline:

September: the engineer runs the fake coding assignment on his work laptop.
October 20: attackers use that laptop, plus an internal AI tool, to reach the computers of two wallet engineers.
October 29: they use stolen credentials to deploy a container and run a malicious script. Funds start leaving at 20:05 UTC.

The detail worth noticing is the internal AI tool. Tools that can read code, run commands, or reach other systems are a lateral movement path. They often get broad access because that makes them useful.

What to do:

Segment the people and devices that can touch signing or payment systems. A general engineering laptop should not be one hop away from them.
Put internal AI assistants and agents under the same access review as service accounts. Scope what they can reach.
Require hardware-bound credentials and fresh approval for anyone deploying to wallet or signing infrastructure, so stolen credentials alone are not enough.

4. Protecting the key is not the same as controlling what it signs

Binance said it found no evidence that wallet private keys leaked. The attackers did not need them. They got Binance's own signing setup to approve something it should never have approved.

On Ethereum, that something was an EIP-7702 authorization. EIP-7702 went live in May 2025 with the Pectra upgrade. It lets a normal wallet sign a short message that points it at a smart contract, after which the wallet runs that contract's code as its own. The feature was built for things like batched payments and sponsored fees.

CoinDesk's analysis of the onchain data shows how it was used here:

The attacker submitted 50 signed authorizations from the wallet labeled "Binance 14", each covering a different nonce, all pointing to the attacker's sweeper contract. The network accepted the one that matched.
About $2.5 billion in ETH and tokens left that wallet in under four minutes.
The malicious delegation stayed active for nearly four hours. Binance's systems kept routing customer deposits into the wallet, and the attacker swept those out too.
Through the same wallet, the attacker gave orders to a separate Binance smart wallet and pulled out $823 million in USDC, according to TRM Labs.

The key point: an EIP-7702 authorization does not name a recipient or an amount. It hands over control of the wallet's code. Any policy that only checks "where is this money going and how much" will not catch it. And because Binance's hot wallets use multiparty computation (MPC), no single key holder could revoke the delegation quickly.

What to do:

Make your signing policy engine parse every message type, not just transfers. Unknown or high-risk types like EIP-7702 authorizations should be blocked by default for hot wallets that do not need them.
Never let a signer produce batches of pre-signed approvals across future nonces.
Plan and test the revoke path for MPC wallets. Know exactly how long it takes to kill a delegation or freeze a wallet, and get that number down.
Watch new protocol features before they show up in an incident. Within weeks of EIP-7702's launch, Wintermute found most delegations were pointing at copy-paste sweeper scripts.

5. Your response plan decides how bad the day gets

The breach was a failure. The response is the part other companies should copy.

Containment: funds started leaving at 20:05 UTC on October 29. The Ethereum delegation was revoked at 00:10 UTC on October 30.
Halt and resume: Binance paused withdrawals for about 48 hours.
Ecosystem help: Tether, Circle, Ripple and others moved to freeze or restrict stolen assets. Coinbase blocked transfers to compromised wallets. Teng put the frozen total at about $2.85 billion as of November 3.
Making users whole: Binance says it has replenished about 98% of affected tokens with company funds and its SAFU emergency fund.
Disclosure: within a week, Binance published the attack path, apologised publicly, and said independent experts would review the incident.

The freezes only worked because stablecoin issuers and other exchanges could act fast and knew who to talk to. Those relationships are built before an incident, not during one. And four hours is a long time when a wallet is still receiving deposits.

What to do:

Keep an up-to-date contact list for issuers, exchanges, chain analytics firms, and law enforcement, and run drills that use it.
Have a pre-approved "stop everything" switch for deposits, withdrawals, and specific hot wallets, with clear authority on who can pull it.
Hold reserves sized for a worst-case hot wallet loss.
Write the public disclosure plan in advance. Fast, specific updates kept trust here better than silence would have.

The bottom line

This attack did not need a new exploit class. It needed a believable recruiter, a poisoned download, patient lateral movement, and a signing system that approved a message type it did not need to. Each step had a known defense. The gap was in how they connected.

If you only take one thing from this: map the shortest path from any employee laptop to the thing that moves your money, then make it longer.

The full attack path is still under investigation, and Binance has not yet said how the attackers got signatures on non-Ethereum chains. Expect more detail once the independent review is out.

Sources

Binance's $6.3 billion hack began with a fake job interview, CoinDesk, Nov 3, 2026
Here's how an Ethereum upgrade helped drain part of Binance's $6 billion loss, CoinDesk, Oct 30, 2026
North Korea used LinkedIn, fake job interviews to trick Binance engineer, Fortune, Nov 3, 2026
A Binance engineer thought he was interviewing for a job, NPR, Nov 3, 2026
Binance breach puts custody at center of crypto infrastructure trade, CNBC, Nov 3, 2026

5 Lessons from the $6.3 Billion Binance Hack