Incident teardown · Exchange thefts 2024 to 2026

Nobody stole the keys

Four exchange thefts, about $8.4 billion between them. In at least three, the attackers never took a private key. They got the exchange's own signing process to approve their transactions.

4 November 2026. Binance's findings are preliminary and it has not published a full post-mortem. WazirX and its custody provider dispute each other's account.

The short version

The way in was a person's computer. At Safe (in the Bybit theft) and at Binance, the entry point was a developer's or engineer's machine.
The prize was the path to the signer, not the key. A wallet interface, a backend that feeds approvals, a signing service: each was made to present the attacker's transaction as a legitimate one.
The attackers spent weeks inside and minutes stealing. Safe's intruders spent 19 days on the operation. Binance's campaign ran for months, and the money left in about 20 minutes.

Four cases side by side

Exchange	Date	Lost	How they got in	What approved the theft	Keys stolen?
WazirX	18 Jul 2024	~$230M	Disputed between WazirX and Liminal	The 4-of-6 multisig's own signers (3 WazirX, 1 Liminal)	Disputed
Bybit	21 Feb 2025	~$1.5B	A Safe developer's laptop, then AWS session tokens	Bybit's signers, shown a tampered Safe{Wallet} interface	No
Bitget	24 to 25 Sep 2026	~$387.5M	Reportedly compromised third-party security software	Bitget's own approval process, fed spoofed transaction data	No, per CEO
Binance	29 Oct 2026	~$6.3B	A DevOps engineer's laptop, then a container deployment token	An internal wallet signing service, called outside the normal withdrawal flow	No evidence, per Binance

a person's machine→infrastructure credentials→the path to the signer→a valid signature→funds out in minutes

What happened in each

WazirX, July 2024

About $230 million left a multisig wallet that needed three WazirX signatures and a final approval from its custody provider, Liminal. WazirX said a discrepancy between what Liminal's interface showed and what was actually signed caused the loss. Liminal said WazirX's own machines were compromised. Attribution to North Korea's Lazarus Group has been widely reported.

Where it broke: between what the signers saw and what they signed. Which side's systems failed is still disputed.

Bybit, February 2025

According to the post-mortem Safe published with Mandiant, attackers compromised a Safe developer's Mac and used it to take over active AWS session tokens. Earlier attempts to register their own MFA device had failed. With the tokens, they changed the JavaScript that Safe{Wallet} served from an S3 bucket. The injected code activated only for Bybit's cold-wallet addresses. Bybit's signers approved what looked like a routine transfer, and about $1.5 billion was gone. Forensic reports by Sygnia and Verichains found that Bybit's own infrastructure was not the entry point.

Where it broke: the interface the signers trusted, served from a cloud bucket the attackers could write to.

Bitget, September 2026

Bitget's CEO said attackers broke into a backend system in its wallet infrastructure and spoofed transaction data, so the exchange's own approval process signed the withdrawals. He said no cold, warm or hot wallet keys were taken. Mandiant and SlowMist reportedly traced the access to compromised third-party security software. Elliptic assessed North Korea as the likely actor. Losses were first put at $351.6 million and revised to $387.5 million, and Bitget says its protection fund covers them.

Where it broke: the data feeding the approval process. The approvers checked what they were given, and what they were given was false.

Binance, October 2026

Binance's preliminary findings, published 3 November, describe a months-long campaign against its engineers, which reportedly included a fake job interview. The attackers ended up with a DevOps engineer's credentials, including a container deployment token. On 29 October they deployed a container that reached an internal wallet signing service and started transactions outside the normal withdrawal process. They used the signing service to set up EIP-7702 delegations, letting a malicious contract move funds out of hot wallets. TRM Labs counts about $6.36 billion across ten chains, most of it in about 20 minutes from 20:05 UTC. Binance says it found no evidence a private key leaked. About $3 billion has been frozen on-chain, and Binance says it will cover user losses. TRM and Chainalysis attribute the attack to North Korea's TraderTraitor unit, and the FBI has confirmed North Korean involvement.

Where it broke: a signing service that would sign for anyone who could reach it.

What defenders can take from this

The window to act is the weeks inside, not the minutes of the drain. Twenty minutes is too fast for a human to notice and respond. The intrusion that came before it, a new MFA device attempt, session tokens used from a new place, a container deployed by an unusual identity, is where detection and response still have time.
Treat developer machines and deploy tokens as part of the custody perimeter. In two of these cases the keys were safe and a laptop was not. Short-lived, narrowly scoped credentials and alerts on how they're used belong in the same threat model as the HSM.
Every approver needs an independent view of what is being signed. If the signer, the approval engine and the interface all read the same upstream data, compromising that data compromises all of them. Decode the transaction on a separate system, and flag operation types that hand over control: delegatecall, proxy upgrades and EIP-7702 delegations.
A signing service should refuse work that didn't come through the front door. Binance's signer accepted transactions started outside the normal withdrawal flow. Requests should carry proof of the path they came through, and the signer should check it.
Cap how fast a hot wallet can empty. Velocity limits that need a fresh human approval to raise turn a 20-minute drain into a page.

If you sign with a hardware wallet or a Safe

The same lesson applies at small scale. The screen you're signing from can lie, and so can the website behind it.

Read the transaction on the hardware wallet's own screen. If the device can only show raw data you can't read (blind signing), stop and decode it somewhere else first.
For a Safe, check the operation type as well as the amount. A transfer that turns out to be a delegatecall or a change to the contract itself is the warning sign.
Have co-signers verify on their own devices, from their own source of truth, not from a screenshot or link the first signer sends.

Written by the author of Kronagent, which triages cloud intrusion findings and contains them with a person's approval. It never holds or signs funds, and nothing here claims it would have stopped any of these thefts. If you run wallet infrastructure on AWS and want a second pair of eyes on the intrusion stage, request access.