Bybit Hack Investigation: The Biggest Crypto Heist In History

Lazarus Strikes Again: A Flaw in EVM, Smart Contracts, Multisig or Safe {Wallet}? Can Web3 Ever Be Truly Secure? Exclusive Research by Hacken.

The recent ByBit hack—where the Lazarus group drained $1.5 billion in ETH and stETH from a multisig cold wallet—has once again exposed critical vulnerabilities in even the most trusted crypto security setups.

This incident was not caused by a flaw in the smart contract code; instead, the attackers exploited human and operational layers. Lazarus manipulated the signing interface during a routine transfer from cold to hot wallet.

Although the signing UI appeared legitimate, it had been covertly modified via malicious JavaScript injected into resources served by Safe{Wallet}’s AWS S3 bucket 2 days before the attack was executed. This “blind signing” exploit misled authorized signers into approving a transaction that altered the wallet’s logic, ultimately allowing the attacker to redirect funds to a wallet under their control.

Both hardware and software signers must move away from the "blind signing" approach and instead clearly display what is being signed.

While communication interfaces remain a potential attack vector, hardware devices add a crucial layer of defense, significantly increasing the difficulty of such exploits. To further strengthen security, Hacken proposes a multi-layered approach to multisig protection, integrating automated transaction monitoring, human-verified alerts, and a Safe Lock mechanism to detect and block malicious activity before it executes.

Let’s Uncover The Biggest Hack In Crypto History

Root cause

Forensic analysis revealed that malicious JavaScript code had been injected into resources served from Safe{Wallet}’s AWS S3 bucket. The injection was likely performed directly into the S3 bucket—as evidenced by resource modification times and web history archives. The malicious code was injected 2 days prior to the exploit.

The injected code was designed to modify the transaction details during the signing process. It altered the data displayed on the signing interface so that the signers unknowingly approved a transaction that would execute a delegatecall to an attacker-controlled contract.

Two minutes after the malicious transaction was executed, new versions of the JavaScript resources were uploaded to the S3 bucket, removing the injected code. This suggests the attacker anticipated forensic detection and attempted to cover their tracks quickly.

Malicious JavaScript code snippet (only two targets are configured - ByBit’s ColdWallet and Attackers’ Test Multisig):

Hacken's Cloud Penetration Testing detects malicious JavaScript injection and other cloud security risks across AWS, Azure, Google Cloud, and more. Don’t be the next target – get a quote today.

Breakdown of the malicious transaction

The Gnosis Multisig is a proxy contract that stores its logic contract address (the “masterCopy”) in slot zero. Whenever someone calls the proxy, the call is delegated to the masterCopy.

In this exploit, the attacker prepared a malicious transaction that tricked the signers into approving a delegatecall to an attacker-controlled contract. Under the hood, this contract executed an SSTORE operation to overwrite slot zero with the attacker’s own implementation address.

After slot zero was changed, all subsequent calls to the multisig were routed to the attacker’s code, allowing them to drain the funds.

Bybit Hack Timeline

How The Bybit Hack Unfolded

Stage 1: Preparation

Hacker’s funding: Bybit hacker was funded from a Binance wallet: 0x0a...cdecf5

Malicious contract deployed: Attackers created a malicious Gnosis Proxy implementation contract.

• Hacker’s EOA who have created malicious implementation for Gnosis’s Proxy upgrade: 0x0f...a6d2e.
• The same malicious implementation (tx: 0xa1...eb35a) during the testing phase was used in the real attack three days later.

Testing on Gnosis Proxy: The testing phase of the exploit was made by attackers 3 days prior to attack, the flow of operations is identical to the real attack which they executed later. Hacker created three Gnosis Proxy for testing, including one, which was then injected as a target contract in malicious JS code: 0x19...cd141

The screenshot below shows the test of the exploit sequence by attackers just 30 minutes before they inject malicious JS code to Safe’s codebase:

Malicious code injection: 2 days before the exploit, after testing attack flow, attackers managed to inject malicious JavaScript code to Safe’s codebase. “Last-modified” field is Wed, 19 Feb 2025 15:29:43 GMT

In injected malicious code, rogue transaction was prepared with upgrading ByBit’s Proxy Multisig with malicious implementation which was deployed 19 hours prior to code injection to Safe’s codebase:

Stage 2: Attack

Masked attack: Attackers disguised the exploit as a routine cold-to-hot wallet transfer, executing the malicious proxy upgrade during a standard ETH transfer from Bybit’s cold wallet to its hot wallet.

According to Bybit, “Transaction was manipulated by a sophisticated attack that altered the smart contract logic and masked the signing interface, enabling the attacker to gain control of the ETH Cold Wallet [0x1d...dfcf4].”

Control overtake: Proxy implementation was upgraded, giving attackers full control over Bybit’s cold wallet. In this operation (0x46...7882), the attackers upgraded the proxy implementation to the malicious contract. After this transaction, attackers gained control over the Bybit Cold Wallet and transferred all funds in several transactions.

Stage 3: Extraction

Funds draining: Unauthorized proxy modifications led to full wallet control, allowing attackers to drain funds. All the draining transactions are delegating calls to the malicious hacker’s implementation.

Draining Bybit’s Cold Wallet:

• 401,346 ETH: 0xb6...072c
• 90,375 stETH: 0xa2...fae0
• 15,000 cmETH: 0x84...8647
• 8,000 mETH: 0xbc...7b20

Crypto laundering: How do you liquidate $1.5 billion in stolen assets when the whole world is watching? That’s the challenge Lazarus faces. Their approach: a layered laundering strategy, systematically dispersing funds across thousands of wallets, leveraging DEXs, cross-chain bridges, and mixers to obscure asset flows—all while maintaining a structured and methodical transaction pattern.

• Primary receiver is 0x47...86e2, distributing funds to ~50 EOAs (10K ETH each) as a first phase in the money-laudering scheme.
• Systematic transfers from EOAs to new wallets (~7,600 identified, 5,400 on Ethereum).
• ~2-3 transactions per minute, pausing every 45 minutes for 15 minutes
• DEXs, cross-chain bridges, and centralized mixers (e.g., eXch). Over $100M converted to BTC via Chainflip.
• ~20% of initial 50 EOAs’ funds already redistributed.

Bybit’s Response

Bounty Program For Tracking & Freezing

Following the incident, Bybit launched the Lazarus Hack Bounty Program, offering a $140 million bounty to track and freeze stolen funds. The program rewards those who successfully contribute to fund recovery, with 10% of the recovered funds distributed among entities that freeze the funds and those who aid in tracing.

Bybit continues to work with industry experts and relevant authorities, urging exchanges, mixers, and bridges to cooperate in freezing stolen assets. So far, 3.03% of the stolen funds have been frozen, while 90.23% remain under active tracking.

Bounty rewards for fund recovery are a positive step, but this is also a good opportunity to remind the industry that proactive security is far more cost-effective than reactive measures. Bybit follows the standard 10% bounty model, but having a proactive bounty program in place typically costs much less. For example, HackenProof’s bug bounty helped NEAR prevent a $40M exploit with just a $1M reward (2.5%)—five times cheaper than the standard post-hack fee.

Proof of Reserves

Bybit has fully restored its 1:1 solvency, with reserves exceeding liabilities across all tokens. Hacken started monthly Proof of Reserves (PoR) audits for Bybit from June 2024, independently verifying its financial health. Our role is strictly limited to PoR audits, and we do not conduct security assessments for Bybit.

In response to the recent security incident, we conducted an ad hoc PoR audit on February 23, 2025, confirming that Bybit maintains a reserve ratio above 100%. While ETH reserves were impacted, the exchange’s diversified asset holdings and strong financial position ensured full solvency and stability. See full report here.

Bybit’s hack could have easily ended like FTX—losing $1.5B overnight can trigger a snowball effect of withdrawals, eroding trust and shaking the market. However, Bybit has been conducting PoR audits with Hacken since June 2024—long before the incident—demonstrating that this was not just a reactive measure but a responsible, ongoing effort to maintain trust. This made a huge difference, preventing market panic and upholding trustl. Indeed, Proof of Reserves is critical for transparency, providing verifiable proof that an exchange holds enough assets to cover liabilities. Hacken, the unanimous leader in PoR verification, provides stakeholders with clear, verifiable insights into asset holdings and liabilities. Explore our methodology here to see how we uphold transparency at every step.

We remain in contact with the Bybit team and continue tracking the laundering of stolen funds.

NOTE: PoR audits strictly assess solvency and do not involve security evaluations. Hacken has not provided security services for Bybit but remains ready to support crypto exchanges in strengthening Web3 security.

How To Make Web3 More Secure?