Binance loses $6.3 billion: From one engineer's laptop to the largest crypto heist in history
On 29 October 2026, about $6.3 billion in crypto assets was stolen from Binance's hot wallets, the largest crypto theft on record. According to Binance's initial findings, the entry point was a compromised laptop belonging to a DevOps engineer.
Figures and findings reflect public information as of 30 October 2026. The investigation is ongoing and Binance has not yet published its detailed technical post-mortem.
What happened?
The attack began at around 20:05 UTC on 29 October, and most of it was over within about 20 minutes. The attacker withdrew assets from Binance's internet-connected "hot" wallets on ten blockchains at once. Binance put the loss at about $6.3 billion, roughly four times the $1.5 billion Bybit hack of 2025.
| Asset | Amount stolen | Approx. value |
|---|---|---|
| Ethereum and ERC-20 tokens | 200,630 ETH, 1.875 billion USDT, 823 million USDC and others | $3.79 billion |
| Bitcoin | 18,270 BTC | $1.47 billion |
| Tron | 612.7 million USDT and 46.4 million TRX | $628 million |
| XRP | 233.46 million XRP | $296 million |
| Solana and other networks | 970,500 SOL, ARB, AVAX, POL | ~$175 million |
Source: TRM Labs, at prices at the time of each transfer. Binance suspended deposits and withdrawals and said it expects withdrawals to resume within 48 hours.
How did the attack work?
According to Binance's initial findings, the attacker reached a service container in the company's internal systems through a compromised laptop belonging to a DevOps engineer, and used it to submit unauthorised withdrawals. Binance says it has found no evidence that wallet private keys were leaked and that multiple factors contributed. How the laptop was compromised has not been disclosed.
On-chain data is consistent with this picture. The Bitcoin withdrawals carried valid signatures from Binance addresses and looked like ordinary withdrawals. On Ethereum, the attacker used an EIP-7702 delegation to point the hot wallet at a sweeper contract under their control and emptied it in about three minutes. TRM Labs assesses that the most likely explanation is that the attacker was able to get Binance's signing system to sign transactions.
The attack was not rushed. The attacker's wallet was funded through Tornado Cash a day earlier, and the attack code was tested on two separate wallets and rehearsed on a third before it was used.
Who is behind it?
TRM Labs attributes the attack "with high confidence" to North Korea's TraderTraitor unit, which is linked to the Lazarus Group. The same group is held responsible for the 2025 Bybit hack, where the entry point was also a developer's computer. The shared patterns: wallets pre-funded through Tornado Cash, preparation days in advance, and pre-obtained signatures executed in a single burst.
Following the money: what was frozen?
- Frozen: Tether froze about 1.57 billion USDT and Circle about 823 million USDC. Ripple, World Liberty Financial and the Arbitrum Security Council also acted on their own assets. Binance puts the total frozen on-chain at about $3 billion.
- Not frozen: Bitcoin has no central issuer, so the 18,270 BTC cannot be frozen. The attacker split it across 19 wallets; it can only be stopped once it reaches an exchange, an OTC desk or a swap service.
- Laundering: The attacker converted part of the stolen stablecoins to ETH on decentralised exchanges and used them as collateral on lending protocols such as Aave and JustLend.
What should Binance users do?
Binance says customer funds are safe and that it will cover losses from its SAFU fund and company funds. For users, the biggest risk right now is scams:
- Ignore emails, text messages and social media posts asking you to "verify your account", "apply for a refund" or "move funds to a safe wallet".
- Follow updates only through Binance's official app and official accounts, and type the address yourself instead of clicking links.
- Make sure two-factor authentication, withdrawal address whitelisting and the anti-phishing code are enabled on your account.
Lessons for organisations
This attack is not just a crypto exchange problem. The target was not a software vulnerability but the computer of an employee with access to critical systems.
- Keep privileged access on separate machines. Engineers who access production and signing systems should do so from hardened devices used only for that purpose, not from the computer they use for email and browsing.
- No single credential should be able to trigger a critical action on its own. High-value or unusual transactions should pass through an independent approval and signing policy, and limits that allow billions to leave within minutes should be questioned.
- Restrict container and service permissions. Everything a service can reach, an attacker who reaches that service can reach too.
- Detect unusual behaviour within minutes. Most of this attack was over in 20 minutes; monitoring that relies on daily reports will not catch it.
- Developer and DevOps teams are social engineering targets. North Korea-linked groups are known to target engineers with fake job offers, fake code repositories and malicious developer tools. Awareness training should cover these teams specifically.
How Nokta Guard can help
In red team operations we emulate the path a real attacker would take and show how far it is possible to get from an employee's computer towards critical systems. Internal network penetration testing reveals privilege escalation and lateral movement paths, and social engineering testing measures how well your teams resist targeted attacks.
Related services: Red Team, Internal Network Penetration Testing, Social Engineering Testing, Purple Team
Related article: The first 72 hours after a critical vulnerability is disclosed
Sources: TRM Labs · CoinDesk · CoinDesk (BTC) · Al Jazeera · CyberInsider · TechCrunch