cryptotradingbook

Case study: the Bybit hack (Feb 2025)

hack history

Case study · ~10 min read

At a glance

  • On 21 Feb 2025, ~$1.5B was drained from Bybit's ETH cold wallet - the largest exchange hack to date.
  • The entry was not Bybit's infrastructure but a compromised Safe{Wallet} UI (supply-chain attack).
  • Bybit covered the loss in full; withdrawals resumed quickly - but only thanks to deep reserves and lender help.
  • Lesson: "cold storage" is only as safe as the software that touches it.
  • What you should check on any exchange: PoR quality, incident history, and how the last incident was handled.

1. What happened

On 21 February 2025, attackers drained roughly $1.5B in ETH and stETH from Bybit's Ethereum cold wallet during a routine multisig transfer. The mechanism: the Safe{Wallet} interface that Bybit used for signing had been compromised weeks earlier - signers saw a legitimate-looking transaction while the underlying data was malicious. It was a supply-chain attack on the signing interface, not on Bybit's servers or keys directly. Attribution was assigned to the Lazarus Group (DPRK).

2. Why "cold wallet" didn't save the funds

Cold storage protects keys from network attacks. But keys are useless without signing software, and signing software is code with an interface - the attack surface moved to the tooling around the keys. The cold/warm distinction assumes the signing process is trustworthy; when the display you check is compromised, "verify the transaction" verifies a lie. Every exchange - and every hardware wallet user - inherits this dependency chain.

3. The response - and what it cost

To their credit, Bybit covered every affected user in full - via reserves, loans and rapid buy-ins - and withdrawals continued within hours. This is the counterfactual to FTX: an exchange with reserves and transparency surviving its worst day. But it should read as luck plus preparation, not as a guarantee: a smaller exchange with the same hack would have become the next FTX. Our profile system records this as hack history with users_reimbursed: true, resolution_status: resolved.

Remember: The lesson is not "exchanges are unsafe". It is "custody chains are deep" - the exchange, its vendors, its signers, their devices. That is why proof of reserves and incident history are core fields in every profile we publish.

4. What this means for you

Three practical rules fall out: (1) size matters - funds beyond what you actively trade belong in self-custody, because even the best exchange runs vendor software; (2) PoR quality matters more than PoR existence - a monthly Merkle report with liabilities beats an annual "trust us"; (3) an exchange's response to its worst day is the best single predictor of the next one. Check our exchange profiles - incident history is a permanent field, with the tag hack history where it applies.

5. When this analysis fails

Post-mortems are incomplete by nature: attribution is uncertain, timelines are contested, and "fully reimbursed" depends on token prices at reporting time. Also, surviving one $1.5B hack does not mean surviving the next. Incident fields age - our profiles carry review dates for exactly this reason.

Risk: The most dangerous reading of this case is "Bybit survived, so hacks are survivable". Bybit had unusual depth. Your exchange is not Bybit - check its reserves and history before it has a bad day.

Knowledge check

  1. Where exactly did the Bybit attack occur? (In the Safe{Wallet} signing interface - a supply-chain compromise, not Bybit's core infrastructure.)
  2. Were users made whole? (Yes, fully - reserves plus lending; withdrawals resumed within hours.)
  3. Which profile fields would have told you about this before depositing? (incidents[] / 'hack history' tag, PoR quality, operational status.)
  4. Why is "cold wallet" not a safety guarantee? (Keys still need signing software and humans - the interface chain is attackable.)
  5. What is the best predictor of how an exchange handles the next incident? (How it handled the last one - reimbursement, transparency, speed.)