How Was Bybit Hacked? Inside the $1.5 Billion Lazarus Group Attack
Brian Cubellis | Chief Strategy Officer
May 23, 2026
On February 21, 2025, Lazarus Group attackers stole approximately $1.4 to $1.5 billion in ETH and staking derivatives from Bybit in the largest single-day cryptocurrency theft in history. The attack succeeded despite Bybit having monthly Hacken-audited Merkle-tree Proof of Reserves with reserve ratios above 100%, with the most recent attestation published less than 24 hours before the hack. Attackers had compromised a Safe{Wallet} developer machine weeks earlier and injected malicious JavaScript into the signing interface. Bybit's signers approved what their UI displayed as a routine cold-to-warm transfer. The Proof of Reserves was true the day it was published and meaningless the moment the malicious transaction was signed. Onramp's Multi-Institution Custody is built around a signing architecture that addresses exactly this class of vulnerability.
This is what actually happened, why the architecture failed, and what would have been required to prevent it.
The headline facts
- Date: February 21, 2025
- Loss: ~$1.4 to $1.5 billion in ETH and liquid staking derivatives
- Attribution: Lazarus Group (North Korean state-sponsored), confirmed by the FBI in a public service announcement on February 26, 2025
- Significance: Largest single-day cryptocurrency theft in history; exceeded the prior record (Ronin Bridge, 2022) by more than 2x
- Last Proof of Reserves before the hack: Hacken-audited Merkle-tree PoR, reserve ratios above 100%, published less than 24 hours before the transaction
- Time from attack start to broadcast: Approximately 30 days from initial developer machine compromise to transaction signing
- Time from broadcast to malicious code removal: Approximately 2 minutes
The setup: Bybit's custody architecture before the hack
In the months preceding the hack, Bybit had implemented what was widely considered a best-in-class custody program for a centralized exchange:
- Monthly Proof of Reserves since June 2024, audited by Hacken using a Merkle-tree of customer liabilities and on-chain reserve attestations. The most recent PoR before the hack was published in February 2025 with all asset categories showing reserve ratios at or above 100%.
- Multi-signature cold storage using Safe{Wallet} (formerly Gnosis Safe), one of the most widely deployed multi-signature platforms in crypto.
- A multi-signer approval flow requiring multiple senior personnel to sign large transactions, with the intent of preventing any single individual from moving funds unilaterally.
By the standards the industry had set after FTX's collapse in November 2022, Bybit was doing more than most. None of it stopped the loss.
The attack vector: Safe{Wallet} supply-chain compromise
The attackers did not break Bybit's cryptography. They did not steal a private key. They did not exploit a smart contract bug in the Safe{Wallet} contract itself. The attack vector was upstream of all of those: the developer environment that produced the user interface Bybit's signers used.
According to subsequent forensic reports from Chainalysis, Elliptic, and Bybit's own post-mortem:
- Early February 2025: Lazarus Group attackers compromised a developer workstation belonging to a Safe{Wallet} engineer. This was likely achieved through social engineering, phishing, or a combination, consistent with Lazarus's documented pattern in earlier attacks.
- February 19, 2025: Attackers used the developer's access to inject malicious JavaScript code into the Safe{Wallet} front-end. The malicious code was conditional: it only activated for specific target wallet addresses, including Bybit's cold storage multi-sig.
- February 21, 2025: Bybit initiated what its signers believed was a routine internal transfer from a cold wallet to a warm wallet. As each signer reviewed the transaction in the Safe{Wallet} interface, the malicious code intercepted the rendering layer, displaying a benign-looking destination address while substituting a Lazarus-controlled address in the actual transaction payload.
- Each signer approved. The transaction was signed by the required quorum. From each signer's perspective, they were approving the transaction the UI showed them. The hardware wallets confirmed signing on the data the malicious code had constructed.
- The transaction broadcast. Funds moved to the attacker-controlled address. Within hours, the assets were being laundered through mixers and cross-chain bridges using Lazarus's established playbook.
- Approximately 2 minutes after broadcast: The malicious JavaScript was removed from the attacker's S3 bucket, eliminating forensic evidence and ensuring no other Safe{Wallet} user encountered the compromised code path.
The defense-in-depth that everyone had assumed protected Bybit was, in retrospect, a single point of failure presented to multiple signers. The signers were all looking at the same compromised interface. They all approved what the interface showed them. The cryptography worked exactly as designed; it just signed the wrong thing.
The aftermath
In the 48 hours following the hack:
- Bybit acknowledged the breach within hours and committed to making customers whole.
- Emergency funding was extended to Bybit by Galaxy, FalconX, Wintermute, and other counterparties to preserve withdrawal liquidity.
- Hacken published a post-hack PoR on February 23, 2025, demonstrating that Bybit's reserve ratios still exceeded liabilities once emergency funding was included. Reserve ratios remained at or above 100% during and after the incident.
- The FBI's February 26 public service announcement attributed the attack to Lazarus and identified Ethereum addresses associated with the laundering operation.
- Chainalysis and Elliptic published detailed forensic analyses identifying the Safe{Wallet} developer compromise as the proximate vector.
Notably, Bybit's Proof of Reserves never showed a reserve shortfall. The first PoR after the hack, on February 23, showed reserves at or above 100% of liabilities, because emergency funding had backfilled the loss before the next attestation cycle. From a snapshot-based reserve-attestation perspective, nothing had ever gone wrong.
Why Proof of Reserves did not detect the hack
This is the architectural point that matters for every other custodian that uses the same model:
Proof of Reserves attests to the state of reserves at a snapshot in time. It does not monitor reserves in real time. It does not detect transactions in flight. It does not test whether the signers are seeing what they think they are signing. It does not verify that multi-signature approvals are functioning as defense-in-depth rather than as a single shared interface presented to multiple humans.
The four structural blind spots that allowed the hack:
- Snapshot blindness. The February PoR was true the day it was published. The hack occurred less than 24 hours later. By the time the next attestation cycle ran, emergency funding had restored reserves to 100%+ of liabilities.
- No cross-institutional quorum. All the signers were Bybit personnel. All were using the same Safe{Wallet} interface. All saw the same malicious display. A signing flow requiring independent verification from a wholly separate institution, with its own infrastructure, its own interface, and its own out-of-band confirmation of the destination address, would have caught the substitution.
- No client-dependent verification step. In a Multi-Institution Custody architecture, large withdrawals require the client to independently appear at a second institution and verify the destination through a separate channel. Bybit's signers were all employees of the same operating entity, dependent on the same compromised interface.
- The attestation was about the wrong thing. Proof of Reserves asks "do they have the coins right now?" The question that mattered was "can anyone move the coins through a single compromised interface without independent verification?" PoR has no mechanism for answering the second question.
What would have prevented it
A defense that would have caught the Bybit hack architecturally, not retrospectively:
- Cross-institutional 2-of-N signing. Require at least one of the required signatures to come from a separate, independent institution that runs its own infrastructure, its own interface, and its own verification process. The malicious JavaScript injection in Safe{Wallet} would have affected Bybit's signing experience but not the independent institution's. The required signature from the independent institution would not have materialized for a substituted destination.
- Client-dependent verification for large transfers. Require the client to independently appear at the second institution and verify the destination address through a separate channel, video call, voice confirmation against a known list, or both. This breaks the single-interface dependency.
- No unilateral control by any single party. No individual at Bybit, and no single party in the signing flow, should be able to push a transaction through without an independent review by a party that does not share their interface, their infrastructure, or their organizational reporting line.
This is the standard the Proof of Ownership framework describes: distributed key control across independent institutions, structured so that no single party can move assets unilaterally and no compromised interface affects the full signing quorum.
The broader lesson
Bybit had Proof of Reserves. Bybit had multi-signature. Bybit had a multi-signer approval flow. All three were doing exactly what they were designed to do. None of them addressed the actual failure mode: a compromised interface presented identically to every signer.
The lesson is not that any one of those controls was bad. PoR remains useful for what it does. Multi-signature is genuinely better than single-key. Internal review processes are genuinely better than rubber stamps. The lesson is that all three of them, stacked together, sit inside a structure where a single architectural assumption, that the interface the signers see is the interface they think they see, was load-bearing.
Custody assurance has to test that assumption. Proof of Reserves does not. An architecture that distributes the signing flow across institutions with independent infrastructure does. This is what the full report (The Proof of Reserves Illusion) examines across every major Bitcoin custodial failure since 2011, and what it proposes as the framework for the next industry standard.
If you're evaluating Bitcoin custody for a position size that warrants institutional-grade safekeeping, schedule a consultation with Onramp to discuss the Proof of Ownership standard and how Multi-Institution Custody addresses the architectural blind spots that Proof of Reserves cannot. To open an account, sign up here.