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 

🚨 New PoR Audit for @Bybit_Official on Feb 23 Confirms Fund Solvency

We conduct monthly PoR audits for Bybit, with the latest released just before the incident on Feb 20. Due to the situation, we issued an ad hoc audit on Feb 23.

— Hacken🇺🇦 | ETHDenver ✈️ (@hackenclub) February 24, 2025

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?

At Hacken, we believe this kind of attack can be stopped with a multilayered security model built on safe multisig monitoring. Our approach combines automated transaction monitoring, human verification of alerts, and a Safe Lock feature. Here’s how it works.

Level One: Automated Monitoring for Real-Time Detection

The foundation of our model is automated transaction monitoring, powered by the Hacken Extractor app. This system tracks on-chain and off-chain activities in real time, scanning for anomalies that could signal trouble. With AI-driven behavior analysis, the app can detect suspicious patterns, such as a mismatch between the UI’s display and the actual transaction payload. In Bybit’s case, the signers were fooled by a spoofed interface they thought was safe. Our automated monitoring would have flagged that discrepancy early, before the transaction was fully signed, giving the system or human a chance to intervene.

Level Two: Human Verification of Alerts

Automation alone isn’t enough—human judgment is critical when the stakes are this high. That’s why our second layer involves human verification of alerts generated by the Extractor or another real-time transaction monitoring system. 

The Bybit attackers bypassed multisig protections by compromising signer workflows or devices. To address this, an independent check should be implemented: trained personnel cross-reference the raw transaction data against what’s shown in the UI.

Additionally, to make it easier for human verification, the system, like Hacken Extractor,  that monitors off-chain and on-chain signatures, verifies them and ensures the payload is consistent across all signers should be implemented. Alerts are delivered to all signers, not just those meeting the threshold limit. The payload is displayed in a human-readable format, augmented with AI-generated comments in plain language. This ensures everyone in the multisig vault can clearly see and match intentions, significantly reducing the risk of exploitation.

This step could have caught the blind signing exploit that slipped past Bybit’s team. Timing and expertise are key here—verification must be swift to stop a live exploit, and our humans are trained to spot the subtle signs of masked attacks. It’s about closing the gap between what signers see and what they’re actually signing.

Level Three: Safe Lock as the Ultimate Safeguard

The third and final piece of the preventive model is the Safe Lock functionality. Safe Lock can pause or block the signing of a malicious transaction—triggered either by the app’s detection or human input. Here, the real time monitoring system generates Alerts that threshold was reached, there is pending on-chain Transaction.

It will show in human readable format that it is pending and the team will have a time window to reject the transaction. In Bybit’s case, the attack succeeded because the malicious transaction was signed and executed before anyone could react, with $1.5 billion gone in under 47 minutes. Safe Lock could have frozen the approval process the moment something seemed off, giving Bybit’s security team the time they needed to investigate and respond. Those 47 minutes of detection were too late—Safe Lock makes them count.

Additionally, protocol should implement internal guards (circuit breakers) for very risky transaction patterns, like very large transfers, large TVL changes. For Example Hacken Extractor already has external monitoring for such activities and will be bringing a Firewall (contract level) circuit breaker for such flows. 

Why Does This Approach Work?

This multi-layered approach directly addresses the core weaknesses exposed in the Bybit hack: the disconnect between perception and reality in signing, the over-reliance on human diligence under pressure, and the absence of a real-time intervention tool. Automated monitoring brings speed, human verification adds judgment, and Safe Lock delivers control. Together, they form a seamless defense that can scale across major blockchains like Ethereum, making it a potential game-changer for exchanges and institutions managing large crypto assets.

Inherent Flaw in Ethereum?

The Bybit hack has sparked a debate between Bitcoin and Ethereum advocates, with Adam Back blaming EVM complexity as the root cause. Back criticizes the EVM for being fragile, complex, and difficult to secure on hardware wallets, asserting that Bitcoin is free from such risks.

While we respect Adam Back’s viewpoint and the wider conversation it ignites about blockchain security, Hacken doesn’t fully agree that the issues highlighted by the Bybit hack are exclusive to Ethereum or the EVM. 

Multisig vulnerabilities and operational complexities—like those that led to the $1.5 billion loss at Bybit—are not confined to one blockchain. They’re a shared challenge across ecosystems, including Bitcoin. Even Bitcoin’s multisig setups, though simpler by design, remain susceptible to risks such as human error, phishing, or advanced attacks targeting signer devices and workflows. 

For instance, blind signing exploits or supply chain attacks—as seen in the Bybit incident, which stemmed from a supply chain compromise rather than issues with multisig contracts or EVM vulnerabilities—could similarly threaten Bitcoin-based projects if comparable oversights occur.

At Hacken, we tackle these universal risks with a multi-layered approach: real-time monitoring to catch threats as they emerge, human analysis and verification through security audits including CCSS Audit, penetration testing to ensure deep scrutiny, and automated preventive measures to stop attacks before they succeed. These solutions work across all blockchains, reflecting our belief that the crypto ecosystem’s credibility hinges on addressing these common vulnerabilities, not attributing them to a single platform. 

Follow @hackenclub on 𝕏 (Twitter)

A Note on Broader Security

One lesson from Bybit is that attackers can strike beyond the app—compromising supply chains or signer devices. While focusing on transaction-level protection, we recognize the need to secure endpoints too. Using air-gapped devices or isolated systems for signers could complement security, ensuring no weak link undermines the chain. It’s not a gap in our approach, but an acknowledgment of how sophisticated these threats are becoming.