The key was never stolen. The machine that signs was.
On 29 October 2026, Binance's hot wallets were emptied across ten blockchains in about 20 minutes. Binance says it may have started with one engineer's laptop.
Pick one. You'll get a security check made for you, right here.
This hack didn't use your password. The next one might.
Binance says user balances are safe and losses will be covered from its SAFU fund and company funds. Your real risk starts now: after every big hack, scammers go after people who are worried about their money.
Your 10-step security check
Messages you'll see in the coming days
- "Your account was affected by the hack, click to verify"
- "Move your funds to this safe wallet"
- "Binance Support" accounts messaging you on Telegram or X
- "Recovery agents" who promise to get your money back for a fee
All of these are fake. Binance will never ask for your password, 2FA code or seed phrase, and will never tell you to move funds. Get updates only inside the app or on the official site you type in yourself.
If your account is compromised: the first 10 minutes
- Don't click links in messages and don't install anything a caller tells you to.
- From a clean device, open the official app or type the address yourself. Ask them to lock your account and withdrawals.
- Change your email password first, then your exchange password. Log out every session.
- Check API keys, connected apps and whitelisted addresses.
- Save screenshots, transaction IDs (TXID), wallet addresses and times.
- Report to your bank and the authorities if needed. Never pay anyone who says they can "recover" your crypto.
How to spot a fake login alert
A real alert just informs you. A fake one rushes you: "Verify within 15 minutes or your account will be closed."
Look at the sender address, the domain the link points to, and spelling mistakes. If you're unsure, touch nothing in the message. Open the app yourself and check the device management page.
The rule is simple: any message that rushes you is suspicious.
A laptop should never be able to become signing power.
Binance's finding shows that keeping keys in a vault isn't enough. If the path that tells the vault to sign is taken over, money leaves without the key ever leaking. Start by checking where you stand.
Your 8-point security check
No laptop, account, CI runner or service should be able to both create and approve a high-value withdrawal on its own.
Each gate runs on a separate system with separate identities. When one falls, the others hold. A request that fails policy never reaches the signer; it's held for review.
01Vault and signingThe link that broke in this incident. Highest priority.
- End blind signing. HSM and MPC nodes must decode every transaction: which chain, which asset, where to, how much, what type.
- Reject EIP-7702 authorizations by default. A hot wallet should never be able to delegate its code without governance approval.
- Destination allowlists, per-transaction and hourly caps, waiting periods for new addresses.
- Keep only daily operating liquidity in hot wallets, and cap automatic refills. Binance 14 was drained three times because it kept being refilled.
- Make signers truly independent: different identity provider, devices and locations.
- Simulate each transaction before signing and compare the result with what was expected.
02Engineer laptopsAssume every developer device can be compromised.
- EDR/XDR with tamper protection and tested one-click network isolation.
- Full-disk encryption (FileVault, BitLocker, LUKS), auto-lock, managed updates.
- Separate accounts for daily work and admin tasks. No standing local admin.
- Production and custody systems reachable only from a separate, hardened Privileged Access Workstation (PAW).
- Audit browser extensions, SSH agents, package managers and remote-access tools.
03Identity and accessA stolen session cookie should be useless.
- Phishing-resistant MFA: FIDO2 hardware keys or passkeys. No TOTP or SMS on privileged accounts.
- Bind session tokens to the device (DPoP, RFC 9449) so they can't be replayed elsewhere.
- Just-in-time access: production rights are requested, approved, last about an hour, and are recorded.
- No cloud token without a device compliance check.
- Keep cloud admin, CI/CD, source control and wallet approval identities separate.
- Test mass session revocation before you need it.
04Network separationA developer VPN must not be a hallway to the signing tier.
- Separate zones for user devices, CI runners, the Kubernetes control plane, production workloads, databases and custody.
- Default deny; allow only the service-to-service traffic that's explicitly needed.
- Admin interfaces behind device-aware ZTNA.
- Monitor DNS, proxies, east-west traffic and egress.
05Cloud and KubernetesA container is isolation, not a trust boundary by itself.
- No engineer holds standing kubectl exec or SSH rights.
- Each service gets its own narrow identity with short-lived, audience-bound tokens.
- Non-root user, read-only filesystem, all Linux capabilities dropped, seccomp on.
- Only signed, scanned images may run (admission control).
- If an interactive shell spawns in a financial container, kill the pod automatically (Falco, Tetragon).
Example: hardened pod settings (educational)
# Educational example, not a complete production manifest. # Add network policies, RBAC and image verification separately. apiVersion: v1 kind: Pod metadata: name: withdrawal-worker namespace: payments spec: serviceAccountName: withdrawal-worker-minimal automountServiceAccountToken: false # no token to steal from inside the pod securityContext: runAsNonRoot: true runAsUser: 10001 seccompProfile: { type: RuntimeDefault } containers: - name: worker image: registry.example.invalid/worker@sha256:<APPROVED_DIGEST> securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true # can't drop and run binaries capabilities: { drop: ["ALL"] }
06CI/CD pipelineDon't park keys in repos. Use short-lived identity.
- Protected branches, required code review, CODEOWNERS for sensitive paths.
- Cloud access through OIDC federation, scoped to repository, branch and environment. No long-lived API keys.
- Pin third-party actions to full commit SHAs. Run dependency and secret scanning.
- Sign every build artifact and verify the signature at deploy time.
- Deploy to production only from a separately approved environment.
07Monitoring and circuit breakersIf billions leave across 10 chains in 20 minutes, the system should stop itself.
- Correlate endpoint, identity, cloud, Kubernetes, CI, signer and on-chain events in one place.
- Store logs outside the system being watched, in tamper-proof form.
- Pause withdrawals automatically when asset, chain or velocity deviates from normal.
- Set up emergency contacts with Tether, Circle, L2 security councils and analytics firms in advance. Here, the first freeze came after 37 minutes.
08Incident response planAligned with NIST SP 800-61 Rev. 3, with hour-by-hour targets.
FIRST 15 MINUTES
- Declare the incident, name a lead
- Isolate the suspect device via EDR
- Pause affected withdrawal and signing routes
- Revoke risky sessions and tokens
FIRST HOUR
- Preserve all logs
- Scope it: which identities, devices, services
- Coordinate freezes with issuers and L2s
- Brief legal and law enforcement
FIRST 24 HOURS
- Take forensic images before wiping
- Hunt for persistence, role changes, new workloads
- Rotate secrets using a dependency map
- Give users an honest update
FIRST 7 DAYS
- Retire hot wallet addresses
- Rebuild clusters from verified code
- Get an independent audit
- Run a blameless root-cause review
| Situation | What should happen |
|---|---|
| New destination address | Waiting period, owner notified, high-value withdrawals blocked |
| Limit exceeded | Held, separate risk team approval |
| Unusual asset, chain or velocity | Automation pauses, manual review |
| Signer policy change | High-risk withdrawals frozen, multi-party approval |
| Code delegation (EIP-7702) | Rejected by default, governance approval |
NIST CSF 2.0
The skeleton of your whole security program: Govern, Identify, Protect, Detect, Respond, Recover.
NIST SP 800-207
Zero Trust. Being on the network is never a reason to trust; every access decision checks identity, device and context.
CIS Controls v8.1 · CCSS v9.0
CIS gives a prioritized, measurable start for small teams. CCSS covers crypto-specific key management and custody.
Pick an answer above to open your security check. Everyone can read how the hack happened below.
From one laptop to the vault
Binance's first statement is short: a DevOps engineer's laptop was compromised, the attacker used it to reach a "service container", and from there submitted unauthorized withdrawal transactions. No evidence was found that wallet private keys leaked.
Picture a bank. The thief doesn't steal the vault key. He breaks into the office computer that sends the vault its "pay this customer" orders. The vault trusts where the order came from, so it hands over the money itself.
The engineer's laptop
Compromised. How hasn't been disclosed yet.
Sessions and credentials
Login sessions, cloud and system access tokens on the laptop may have been taken.
Service container
An internal piece of software on Binance's servers that can send withdrawal requests.
Signing system
Treated the request as legitimate and produced valid signatures. The key never left.
Funds out
Signed, "valid" transfers on Bitcoin, TRON, Ethereum and other networks.
Binance co-CEO Richard Teng later added that this wasn't a one-click action using one engineer's permissions. It was a more complex process, and additional points of breach were found. Binance has not blamed any individual.
A factory robot with one job
Big companies don't run their software as one giant program. They split it into small pieces, each living in a "container" and doing one task: one calculates balances, one sends notifications, one forwards withdrawal requests to the signing system.
The problem: the piece that forwards withdrawals is a trusted internal voice to the signing system. Once an attacker can speak with that voice, fake requests look exactly like real customer payouts.
Turning a wallet into a vacuum
EIP-7702 arrived with Ethereum's Pectra upgrade in 2025. It's a signed "permission note" that lets a normal wallet run a smart contract's code as if it were its own.
The attacker deployed a sweeper contract hours earlier. At 20:20 they sent one transaction to Binance's busiest hot wallet, Binance 14, carrying 50 authorizations. One of them was valid. ON-CHAIN
That note had been signed by Binance's own signing system. The wallet effectively gave itself permission to run the attacker's code.
The wallet became a vacuum the attacker controlled. 167,464 ETH and 1.615B USDT left in one transaction. As Binance's systems kept refilling the wallet, it was drained again. ANALYSIS
Blockchain analytics firms TRM Labs and Chainalysis attribute the attack with high confidence to TraderTraitor, a North Korean state-linked unit also tied to the 2025 Bybit hack. INDEPENDENT ANALYSIS
Binance and law enforcement haven't named anyone officially. Analysts say the attacker's operating wallets were funded through Tornado Cash the day before.
Stablecoin issuers have a "freeze" button. ETH and BTC don't. That's why almost everything frozen is stablecoins.
About $2.7B per Bitquery and TRM. Binance's verified total on the morning of 30 Oct was ~$3B. The figure climbed through the night: 1.8 → 2.4 → 2.54 → 2.7 → 3 billion.
Timeline, 28–30 October
All times UTC. Sources differ by a few minutes in places; this follows the most widely confirmed order.
- 28 October
The attacker's operating wallet is funded with Tornado Cash withdrawals. ANALYSIS
- 29 October
The sweeper contract is deployed from the attacker's address, four hours before the drain. ON-CHAIN
Large outflows from Binance hot wallets begin across many chains. ON-CHAIN
TRON and Bitcoin drains. In the same minute, a transaction with 50 EIP-7702 authorizations lands on Binance 14. ON-CHAIN
Biggest Ethereum sweep: 167,464 ETH, 1.615B USDT and 60+ other tokens in a single transaction. ON-CHAIN
Tether's first freeze: 971.1M USDT. ANALYSIS
Circle freezes 823M USDC.
Binance founder CZ writes on X that it does look like a hack.
Tether's CEO says more than 1.567B USDT is frozen.
Binance pauses withdrawals (sources disagree on the exact time). STATEMENT
- 30 October
Arbitrum's Security Council moves the attacker's 8,426 ETH and 74.6M ARB on its network into a locked wallet.
Binance cancels the EIP-7702 delegation on its wallet. ON-CHAIN
Binance publishes its first findings: DevOps laptop → service container → unauthorized withdrawals. No private-key leak evidence. Impact ~$6.3B, ~$3B frozen, losses covered by SAFU and company funds. STATEMENT
Update: additional breach points found, multi-stage attack. Deposits normal, withdrawals expected back within 48 hours. TRM Labs and Chainalysis attribute the attack to TraderTraitor. STATEMENT
Different attacks, the same mistakes
These incidents aren't identical. What's worth comparing isn't the dollar amount but which trust boundary broke.
| Incident | Loss | What broke | Lesson |
|---|---|---|---|
| Binance Oct 2026 | ~$6.3B | DevOps laptop → service container → signing system (preliminary) | The vault can empty without a key leaking. Separate the request from the power to sign. |
| Bybit Feb 2025 | ~$1.5B | A Safe developer's credentials were compromised; signers were tricked into approving a malicious transaction. FBI: North Korea. | Is what's on screen what's being signed? Verify independently. |
| WazirX Jul 2024 | ~$230M | A multisig wallet's interface showed different data from the actual transaction. The parties dispute who was at fault. | Don't rely on one interface or one vendor. |
| Ronin Bridge Mar 2022 | 173,600 ETH + 25.5M USDC | 5 of 9 validator signing keys were compromised. | Multisig fails if the signers aren't truly independent. |
| Poly Network Aug 2021 | $600M+ | A cross-chain function was abused to change a privileged role. | Role changes need timelocks and strict validation. |
| Mt. Gox 2011–2014 | ~647K BTC | Per a U.S. indictment, years of unauthorized access to servers and keys. | Detect long-running anomalous transfers and reconcile independently. |
What we still don't know
Binance says a full technical post-mortem will follow once facts are verified. Until then, these stay open. Hover or tap a line to read it. Anyone speaking about them with certainty is guessing.
- Initial access: how exactly the laptop was compromised, phishing, malware or supply chain
- Credentials: which operating system, and what kind of credentials were stolen
- The container: what it was allowed to do, and how the attacker reached it
- Other breaches: what the "additional points of breach" are, and how many systems
- Other chains: whether signatures on Bitcoin and TRON came through the same path
- Attribution: an official name from law enforcement, beyond analytics firms
- Final loss: impact, frozen and recovered are three different numbers
- Withdrawals: exactly when they fully return to normal
Every claim has a source
- BleepingComputer: Binance links $6.3B theft to DevOps laptopNews · 30 Oct 2026 · Teng's "not one-click" statement
- CNBC: Biggest-ever crypto hack impacts $6.3 billionNews · 29–30 Oct 2026 · SAFU, freeze figures
- Bitquery: on-chain investigationIndependent analytics · 30 Oct 2026 · minute-by-minute flows
- crypto.news: Blockaid's 50 EIP-7702 authorizations findingNews · 30 Oct 2026
- TRM Labs attribution to TraderTraitor (Grafa)News · 30 Oct 2026
- The Crypto Times: How $6.3B was drained in 20 minutesAnalysis · 30 Oct 2026 · how freeze figures evolved
- FinanceFeeds: contract deployment and 20:20 delegationNews · 29–30 Oct 2026
- CryptoNewsBytes: freezes by issuerNews · 30 Oct 2026 · Arbitrum, Ripple, WLFI
- AFP (Yahoo Finance): Binance confirms $6.3bn hackWire report · 30 Oct 2026
- FBI: Bybit hack attributed to North KoreaOfficial notice · 26 Feb 2025
- NIST SP 800-207: Zero Trust ArchitectureOfficial standard · 2020
- NIST SP 800-61 Rev. 3: Incident ResponseOfficial standard · 2025
- NIST Cybersecurity Framework 2.0Official framework · 2024
- Kubernetes Security ChecklistOfficial docs
- MITRE ATT&CKAdversary technique knowledge base
- EIP-7702 specificationEthereum Improvement Proposal