$6.3 billion out of Binance: a deep dive into the biggest crypto heist ever

1. The theft in one minute

On 29 October 2026, Binance, the world's largest crypto exchange, watched about $6.3 billion leave its own wallets. The theft took about four hours, crossed roughly ten blockchains, and is the largest crypto theft on record.

The attacker did not break any cryptography and did not steal a private key. Binance says it found no sign of a key leak, and the firms that traced the funds agree. Instead, the attacker reached the internal service that signs Binance's outgoing payments and asked it to sign transfers to the attacker. It did, with genuine signatures.

On Ethereum, one of those signatures went further. It handed control of one of Binance's main wallets to a smart contract the attacker owned. From then on, every time the attacker called that contract, it emptied the wallet, including money that arrived later. Pausing withdrawals didn't stop it. Binance only removed the authorization almost four hours after it was granted.

Getting in took five months. In June, an engineer installed a fake copy of a common developer tool. In September, a second engineer ran a "coding assignment" from a fake job interview on his work computer. In October, the attacker used an internal AI tool to reach the computers of two engineers on the wallet team. One of those computers held an access token that could run software inside Binance's infrastructure. The attacker used that token on 29 October.

Where things stand on 12 November:

Binance repaid its customers. Binance covered the stolen assets with its own money and reopened withdrawals on 1 November.
Less than half of the money is frozen. Token issuers and others froze $2.7 billion to $3.0 billion. None of the frozen money has returned to Binance.
About $3 billion is still with the attacker. mostly bitcoin and ether, which nobody can freeze.
The FBI attributes the theft to North Korea. North Korea denies it.
Binance still owes the full explanation. Binance calls its report "initial". It details what happened at several steps, but not how.
Several hundred million dollars is being laundered. The smaller holdings on Tron, Solana and the XRP Ledger have gone through swaps, cross-chain bridges and mixers.
A negligible amount has been cashed out by Elliptic's assessment.
The full story isn't out. Binance calls its report "initial". It describes what happened at several steps, but not how.

This article walks you through how each step was possible, and separates what's known from what isn't public yet.

*The attacker needed five months to get in and four hours to take the money.*

2. Fundamentals before we start

Key concepts to understand what happened.

A wallet checks the signature and nothing else

A private key controls a crypto wallet and anyone who can produce a valid signature with that key can move the money. The blockchain checks that the signature is valid, not who asked for it or why.

Hot wallets hold the money that software can reach

An exchange keeps most customer money in cold wallets. The keys of a cold wallet stay offline. A smaller share sits in hot wallets, which software can reach at any time so withdrawals are fast. At Binance's size, that small share is still billions of dollars. Every wallet that lost money on 29 October was a hot wallet.

A withdrawal passes several checks before anything is signed

A withdrawal request goes through a series of checks first, usually your login, your two-factor code, your account limits, and flags for unusual activity, plus human review in some cases. Only then does a withdrawal service build the transaction and send it to the signing service, which produces the signature.

MPC protects the key, not the request

Binance stated its Ethereum hot wallet used multi-party computation (MPC). With MPC, several servers each hold one share of the private key and compute a signature together. No server ever holds the full key. An attacker who breaks into one server gets one share, and one share is useless.

That makes MPC a strong defense against key theft, but it doesn't decide what gets signed. If a request arrives through a path the servers trust, they sign it.

A different control, called a policy engine, decides what gets signed. A policy engine checks each request against rules: who is asking, where the money goes, how much, and what kind of signature it needs. The policy engine has to run at the signing service itself. A check that runs earlier only covers requests that go through the withdrawal process.

*A typical withdrawal passes every check before the signing service produces a signature.*

An EIP-7702 authorization tells a wallet to run a contract

A smart contract, or simply a contract, is a program stored and run on a blockchain.

Since May 2025, Ethereum's EIP-7702 feature lets an ordinary wallet sign an authorization that names a smart contract (a program stored on the blockchain). From then on, the wallet runs that contract's code whenever anyone calls it, while keeping its address and its money. This is called a delegation.

It's meant to let wallets do more, like bundle several actions into one transaction. The risk is that the contract acts as the wallet with no limits beyond its own code, and the delegation lasts until the wallet signs a new authorization that clears it.

The three engineers that appear in Binance's report

Binance's report identifies three employees by letter. The attacker moved from one to the next.

Engineer A works in Wallet DevOps, the team that runs the wallet infrastructure.
Engineer B is a software engineer. Binance does not place him on the wallet team.
Engineer C is a wallet software engineer.

3. How the attacker got in, from June to October 29

June: Engineer A downloads a fake installer

While setting up a popular AI coding tool, Engineer A downloaded a tampered copy of Homebrew, the standard command-line installer for Mac developers. Binance says he found it through a search engine.

Attackers build lookalike pages, push them up the search results, and swap in their own command. Because the fake page asks for the same action as the real one, nothing looks off. page asks for the same action as the real page, so the developer sees nothing unusual.

Binance's security team detected the problem. The team replaced the computer and changed (or rotated) every related credential. What it couldn't undo was what the attacker had already learned: Engineer A's role and who his colleagues on the wallet infrastructure team were.

Binance labels this a "supply chain attack", a term that usually means a real supplier was compromised. No published source suggests the real Homebrew was altered, and the evidence points to a copy.

September: Engineer B runs a coding test from a fake employer

It's unclear whether the June breach led the attacker to Engineer B. His profile on a legitimate job site mentioned his Binance experience, and a self-described Project Director from a company that didn't exist reached out.

Two more fake identities followed. An "HR representative" interviewed him on live video and, to seem real, shared a social media account full of personal photos and videos. A "CEO" then ran a second interview over a chat app and, near the end, asked him to download a coding assignment onto his work computer.

The assignment was a code repository, and malicious code ran while he set it up. Modern projects run commands automatically when you install dependencies or build them, and some do it as soon as you open the folder in an editor. Binance hasn't specified which of these the repository used.

The malware then replaced pyenv, a trusted tool for managing Python versions, with a malicious version under the same name. That let the attacker's code run from a trusted folder every time the engineer used it, which for a Python developer can be many times a day. No one outside Binance has a copy of the malware, so its other functions are not public. Binance notes that its security software did not detect the malware (which Binance calls a 0-day) and that the attacker wiped the traces.

The FBI has been warning crypto companies about this exact method since September 2024, and its advice comes down to one rule: never run interview code on a company computer.

*Each step of the fake interview looks like a normal hiring process.*

October 20: the attacker used an internal AI tool to reach the wallet team

After about six weeks of silence in Binance's account, the attacker, working from Engineer B's computer, used an internal AI tool to take control of the computers of Engineers A and C.

That's nearly all Binance has said about this step. It hasn't named the tool, described what it does, or explained how a tool used by one employee could control two colleagues' computers. Co-CEO Yi He added one detail in a reply on X written in Chinese: by our translation, the attacker used the tool's permissions through Engineer B, meaning the access Engineer B already had.

On Engineer A's computer, the attacker found a container deployment token.

What a deployment token can do

Companies run their software in containers, packaged programs that a central platform starts and stops on its servers. A container deployment token lets its holder start new ones, and therefore run their own code inside the production network, next to internal services. A token stored on a laptop is only as safe as that laptop.

October 29, 17:15 to 19:56: the attacker deploys a container

Nine days later, the attacker logged on to Engineer C's computer, used Engineer A's stolen credentials to deploy a container, and started a malicious script. Binance places this between 17:15 and 19:56. The first money moved at 20:05, nine minutes later.

Binance explained that the attacker reached "wallet signing operations" and that had unauthorized access to the signing service, but we do not know for sure whether the attacker's container gave that access. How the container could send requests to the signing service is not public.

The attacker also rehearsed on the public blockchain. From 28 October, it funded a new wallet through a mixing service. On 29 October, the attacker tested two versions of a contract on three test wallets. The attacker deployed the final version at 15:59, about four hours before using it on Binance.

*Solid arrows are steps that Binance states, and the dotted arrow is a step that the report only implies.*

4. The four hours of the theft, from 20:05 to 00:10

The attacker emptied wallets on one blockchain after another

Between 20:05 and 20:09, five Binance wallets on the XRP Ledger sent out 233 million XRP, followed by wallets on Solana and Optimism. According to Binance, an internal alert for large transfers fired at this point and its team began investigating.

At 20:20, a Binance hot wallet sent 18,270 bitcoin, about $1.5 billion, in a single transfer. Within two minutes, a Tron wallet sent more than $600 million in the stablecoin USDT.

Each was an ordinary transfer, signed separately by Binance's signing service on the attacker's instructions. The attacker needed a new signature for each transfer. Without access to the signing service, the attacker could make no more transfers.

On Ethereum, the attacker used a method with no such limit.

One authorization hands over Binance 14

At 20:20:59, the attacker sent a single Ethereum transaction carrying 50 EIP-7702 authorizations, all naming the attacker's contract and all signed by one of Binance's best-known hot wallets, publicly labeled Binance 14.

Why 50? Every Ethereum wallet has a counter, the nonce, which increases by one with each transaction, and an authorization only works if it carries the wallet's exact nonce when Ethereum processes it. Binance 14 was sending about ten customer payouts a minute, so its nonce changed every few seconds. The attacker could get signatures but couldn't control when payouts went out, so it collected authorizations for 50 consecutive nonces and sent them together. One matched, and Ethereum ignored the other 49.

From that second on, Binance 14 ran the attacker's sweeper contract. Its only rule: when one specific attacker address calls it, send the wallet's assets wherever the caller chooses.

The attacker called it 3 minutes and 24 seconds later. One transaction moved about 167,000 ether and 63 different tokens out of Binance 14, worth about $2.5 billion. The network fees came to about $15 for the delegation and under $1 for the sweep.

Binance signed nothing for that sweep, or for any of the ones that followed.

*After the delegation, Binance 14 moved money each time the attacker called.*

Why the pause didn't stop the theft

Binance suspended withdrawals and shut down its hot wallet services.

On the other blockchains, each theft needed a fresh signature. Those thefts end when the attacker loses access to the signing service. The time when the attacker lost access is not public. A second group of transfers, on two more blockchains, went out at about 23:05.

For Binance 14, cutting off access wasn't enough, because the sweeps needed no signature from Binance. A withdrawal pause controls Binance's own servers, and the sweeper contract wasn't on them. Ethereum stored the delegation and ran the contract every time the attacker called Binance 14. Binance's report acknowledges this, contradicting its post on the morning of 30 October, which claimed the outflows stopped when withdrawals were paused.

Because the address was still in use, money kept arriving in Binance 14 from customers and from Binance's own systems. The attacker swept it again at 21:04, 21:44, 22:39 and 23:56. The 21:44 sweep alone took about $200 million in USDT that had come in after the first one. At 23:55:47, a deposit of 2,962 ether landed in Binance 14, and the attacker swept it 60 seconds later.

The delegation reached beyond Binance 14's own balance, too. Binance 14 had operating rights over a second Binance account holding USDC, so the attacker, acting as Binance 14, took 823 million USDC from it.

*Loss of access to the signing service ends one kind of theft and does nothing to the other.*

Why clearing the delegation took until 00:10

Only Binance 14 could clear the delegation, by signing a new authorization that names no contract. It did so at 00:10:35, 3 hours and 50 minutes after the delegation began.

Binance blames MPC for the delay:with the key split across several servers, no single machine could sign the new authorization right away, and the team had to build a special procedure.

Yet during the delegation, Binance 14 sent 45 ordinary token transfers, each signed with its own key, to an address Etherscan labels as a Binance cold wallet. The first left at 22:55:35 and the last at 00:07:11, three minutes before the delegation was cleared. Most likely, Binance was moving the remaining tokens to safety. Either way, Binance 14 could sign ordinary transactions for over an hour, so the delay was specific to authorizations, a different kind of message from a transaction.

Whether that came from a limit of the MPC system, as Binance maintains, or from a missing procedure is still unresolved.

Stablecoin issuers can freeze tokens so the attacker moved fast

More than half of the stolen assets were stablecoins, and unlike bitcoin and ether, a stablecoin can be frozen by its issuer

A stablecoin like USDT or USDC is a contract controlled by its issuer, with a built-in blocklist. Once an address is on it, its tokens can't move. Bitcoin, ether and XRP have no issuer and no blocklist.

So the attacker first converted stablecoins into assets nobody can freeze, even at below-market prices, getting about $786 million out before the freezes hit.

Tether froze the main receiving address at 21:01, 37 minutes after the first sweep. Circle froze all the stolen USDC at 21:04, before the attacker swapped any of it. Ripple froze its own token at 22:01, and World Liberty Financial did the same at 22:10. Some issuers also froze their tokens inside Binance 14 itself, so that the sweeper contract had nothing to take.

That night, "freeze" meant three different actions:

A blocklist entry. The issuer adds an address to the blocklist, and the tokens at that address stop moving. Tether, Circle, Ripple, and World Liberty Financial did this.
A market freeze. The lending platform Aave stopped new deposits and new loans. The freeze kept the attacker from using more stolen stablecoins as collateral, but it did not affect a loan that the attacker already had.
A forced transfer. On the Arbitrum network, an elected emergency council changed a core contract for a short time. The change let the council move about $30 million out of the attacker's address without the attacker's key. The council then restored the contract.

*An asset can be frozen only if it has an issuer.*

5. Why the attack was possible

EIP-7702 explains why Binance couldn't stop the theft on Ethereum, but not why it could start. By our estimate from Elliptic's figures, about 40% of the money left through ordinary transfers on other blockchains, and a second Ethereum hot wallet was also drained the ordinary way.

The theft could start because of the gap that section 2 describes. Binance protected the key. The checks at the signing service did not stop these requests, and Binance has not published what those checks were. The requests were not customer withdrawals, and they did not go through the withdrawal process. The signing service signed them. Binance's report says that the attacker started the transactions outside the normal withdrawal process. Co-CEO Richard Teng said that the EIP-7702 step did not pass through Binance's normal approval controls. Binance now says that it is reviewing what its signing policy covers.

*The attacker's requests reached the signing service without the checks of the withdrawal process.*

Ten failures, in order:

The attack needed all ten. Fixing any one would have stopped it.

An engineer ran outside code on a work computer. Two engineers did so, in two different ways.
The June response fixed the computer and not the exposure. The attacker still knew who worked on the wallets.
The September malware stayed undetected for at least six weeks.
An internal AI tool lets one person's access reach other people's computers. How it is not public.
A deployment token for production was stored on a computer, and it worked from a different person's computer.
The attacker's new container could send requests to the signing service, as far as the report shows. How it is not public.
The signing service signed what it received. The requests included transfers to unknown addresses on about ten blockchains and 50 EIP-7702 authorizations.
An alert fired early and did not stop the outflows. The largest transfers came after the alert.
Binance had no prepared way to clear the delegation. The delegation stayed for almost four hours.
Money kept arriving in Binance 14, and the attacker swept it as it arrived.

None of these failures is unusual. Changpeng Zhao, Binance's co-founder, wrote after the theft that serious security failures had occurred, and that some of the details were embarrassing.

*The attack needed ten failures, and a fix at any one of them stops it.*

6. The FBI blames North Korea

On 31 October, two days after the theft, the FBI named North Korea as responsible. It attributes the attack to TraderTraitor, the US government's name for the North Korean unit that targets crypto companies, part of the wider family of groups the security industry calls Lazarus Group.

The FBI's notice lists 628 addresses that hold stolen funds and requests exchanges and other services to block them. The notice does not present evidence.

The public evidence comes from blockchain tracing firms and centers on behavior:

The preparation matched earlier thefts that investigators attribute to the same unit. TRM Labs lists three shared features. The attacker funded a new wallet with small amounts through a mixing service, ran tests shortly before the theft, and collected signatures in advance.
Within hours, the stolen funds mixed with money from the Bitget theft. Chainalysis and the independent investigator ZachXBT both reported it.
The laundering used services seen in earlier North Korean thefts. Elliptic reported it.

Binance hasn't made its own attribution and points to the FBI's.

North Korea rejected the accusation. In a statement carried by state media, Kim Yo Jong, sister of leader Kim Jong Un, called it absurd and a political provocation.

The methods match the unit's track record. The FBI and its partners have documented fake recruiters, coding tests, and attacks on infrastructure engineers as its approach since at least 2022. Binance reports blocking 57 suspected North Korea-linked attempts in 2026 before this one got through.

7. What the theft cost

Binance covered customers from its own funds

Within hours, Binance promised to cover every loss, and it did, drawing on three sources: SAFU, its emergency reserve for users; part of its futures insurance fund; and its corporate treasury. Binance reported replacing about 80% of the stolen assets by 30 October and 98% a few days later. The rest were smaller tokens that are hard to buy in bulk.

Withdrawals reopened on 1 November, on 15 networks at first. In the first hours, customers pulled out about $4.6 billion and deposited about $1 billion.

The bill came out of Binance's reserves. Based on public wallet data, CoinDesk reported that the bitcoin in the SAFU fund dropped by about half. Binance has pledged to refill it but hasn't set a date.

Markets fell that night

Bitcoin dropped 4% to 5%, and Binance's own BNB token fell 6% to 8%. Exchanges automatically closed more than $1.5 billion in leveraged positions, what traders call liquidations.

Less than half of the stolen money is frozen. The laundering is automated and slow. In one method, the attacker creates a worthless token and opens a market for it. Its own wallets buy the token with stolen funds, and a different wallet collects the proceeds, so the market is the only link between buyer and seller.

Frozen isn't recovered. Before frozen funds go anywhere, someone has to establish legal ownership, which can involve several countries. Binance has asked Arbitrum's governance to release the $30 million, a process expected to take about seven weeks. Its request includes a clause handing the money to whichever party a court ultimately names, and with good reason. After a similar freeze on Arbitrum in April, holders of US court judgments against North Korea claimed the funds, arguing that money stolen by North Korea is North Korean property they're entitled to collect.

*Less than half of the money was stopped, and stopped money is not returned money. The split by blockchain follows TRM Labs.*

8. What's still unresolved

The attacker is still moving the money. About $3 billion remains with the attacker. Elliptic expects the attacker to convert the ether to bitcoin in small amounts and to sell it through intermediaries over several months.

The explanation isn´t finished. Binance's 3 November document is an initial report. It promises a fuller account and an independent expert review, but Binance hasn't named the firm doing the review.

Open questions:

What is the internal AI tool, and how did it give control of other people's computers?
Why did the attacker use Engineer C's computer with Engineer A's deployment token?
Did Binance issue that deployment token before June or after? In June, Binance says that it changed all of Engineer A's related credentials.
How could a new container send requests to the signing service?
Could the signing service read what it signed, or did it sign any data that arrived?
When did Binance pause withdrawals, and when did the attacker lose access to the signing service? The transfers at about 23:05 suggest that access lasted late.
Why did Binance need almost four hours to clear the delegation?
What did the attacker do on Engineer B's computer in the six weeks before 20 October, and in the nine days before the theft?

9. What would have stopped the attack

Each of the ten failures in section 5 has a known fix. A system can protect its key completely and still sign requests nobody approved. On 29 October, Binance's signing service did exactly that, on about ten blockchains.

*Each of the ten failures has a known fix.*

10. In the end, it all comes down to OpSec

Every step Binance has described exploited a gap in operational security, or OpSec: how people install software, where they run code from strangers, what internal tools can reach, where credentials live, and what a team does when an alert fires.

Professional attackers go after people first and systems second. That isn't specific to Binance or to crypto. Any organization that holds money or data has the same three exposures:

People. An attacker can find your staff on a job site and contact them with a convincing offer. Staff need clear rules for unknown code and unknown contacts, and a simple way to report both.
Access. A tool or a token gives its holder everything that it can reach. Give each person, tool, and token the least access that the work needs, and make that access expire.
Procedures. A response that nobody has tested is slow when an incident happens. Binance had to develop its procedure to clear the delegation while the theft continued.

The same thinking protects individuals too. Three habits to lower your risk:

Type the address of a software vendor yourself, or use a bookmark. Do not install software from a search result until you have verified the source.
If a recruiter asks you to run code, run it in a disposable environment and never on a work computer. Be careful when the recruiter moves the conversation to a different chat app.
If a wallet app asks you to approve or sign a transaction that you do not fully understand, refuse.