#2 Bybit Incident: A Web2 Breach Enables the Largest Crypto Hack in History

On February 21, 2025, Bybit lost approximately $1.5 billion after an attacker compromised a Safe{Wallet} developer's machine through social engineering. The attacker injected malicious JavaScript into Safe{Wallet}'s AWS S3 bucket, targeting Bybit's transactions specifically. The injected code altered transaction content during the signing process: the Safe{Wallet} UI displayed a legitimate transaction, while the actual payload sent to the signers' Ledger devices upgraded Bybit's Safe contract to a malicious implementation, giving the attacker full control. Once signed and executed, the attacker drained all assets from the contract. A detailed technical breakdown is available in our earlier report [1].

Background

Safe{Wallet} (a.k.a. GnosisSafe) is a multisig wallet infrastructure using an n-of-m model: executing a transaction requires at least n signatures from m total signers.

Each Safe wallet is deployed as a proxy contract. Two storage variables are central to this incident:

masterCopy (slot 0): the address of the implementation contract. This contract contains all execution logic, including signature verification and upgrade mechanisms. The proxy delegates all calls to masterCopy via delegatecall.
threshold (slot 4): the minimum number of signatures (n) required. For Bybit's Safe, this was 3.

Because the proxy uses delegatecall, any function called on masterCopy executes in the proxy's storage context. This means a delegatecall target can directly overwrite masterCopy at slot 0, replacing the entire implementation in a single transaction.

Vulnerability Analysis

The attack path traversed three layers of the system, each presenting a structural condition that the attacker leveraged:

Frontend serving model. The Safe{Wallet} frontend JavaScript was served from an AWS S3 bucket. In this architecture, anyone with write access to the bucket can modify the code that constructs transactions for signers. Integrity verification mechanisms such as subresource integrity (SRI) hashes or code signing can mitigate this risk, but they are not yet standard practice for most dApp frontends. The attacker gained write access through the compromised developer machine and silently modified the served JavaScript.

Gap between UI display and signing payload. The injected JavaScript displayed a legitimate-looking transaction on the Safe{Wallet} UI while sending a different payload to the Ledger hardware wallets. The transaction details shown on the Ledger screen would have differed from the UI, but interpreting raw transaction data on a hardware wallet screen is not straightforward, especially for complex multisig operations. This gap allowed the attacker to collect three valid signatures for the malicious payload.

Proxy upgrade model. As described in Background, delegatecall executes the target's code in the proxy's storage context. The Safe proxy architecture routes all calls through a single masterCopy pointer at slot 0. Overwriting this pointer redirects the proxy to an entirely different implementation, including its signature verification logic, in a single transaction. The n-of-m model governs who can initiate a transaction, but once a transaction is approved and executed, it can alter the implementation itself. If the new implementation removes signature verification, the multisig protection is effectively gone for all subsequent transactions.

Attack Analysis

The attack proceeded in three steps: Malicious Code Injection, Implementation Replacement, and Asset Theft.

Step 1: Malicious Code Injection

The attacker compromised a Safe{Wallet} developer's machine and injected malicious JavaScript into the AWS S3 bucket serving the frontend. The injected code specifically targeted transactions from Bybit's Safe address. According to Bybit CEO Ben Zhou [2], the Safe{Wallet} UI displayed a legitimate transaction, while a different payload was sent to the signers' Ledger devices. The signers approved the transaction as presented in the UI, giving the attacker three valid signatures for the malicious payload.

Step 2: Implementation Replacement

The attacker submitted the malicious transaction with the three collected signatures. The Safe proxy delegated the call to masterCopy, whose execTransaction() validated the signatures and then executed the transaction payload: a delegatecall to the attacker's contract (0x962214...5c7242). Because this delegatecall runs in the proxy's storage context, the attacker's transfer() function overwrote the value of masterCopy at slot 0 with a malicious implementation address (0xbDd077...9516). From this point on, all calls to the Safe contract were delegated to the attacker's code.

Step 3: Asset Theft

With masterCopy now pointing to the attacker's implementation, the multisig requirement no longer applied. The attacker called SweepERC20() and SweepETH() directly on the Safe contract. These functions, defined in the attacker's implementation contract, transferred all held assets without any signature verification. Five drain transactions were executed, totaling approximately $1.5 billion in losses.

Type	Description	Address / Hash
Contract	Bybit's Safe contract	0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4
Contract	The original masterCopy contract	0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F
Contract	The malicious masterCopy contract	0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516
Contract	The attacker's contract (i.e., transfer())	0x96221423681A6d52E184D440a8eFCEbB105C7242
Transaction	Tx replaced the masterCopy contract	0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
Transaction	Tx drained 15,000 cmETH	0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647
Transaction	Tx drained 90,375 stETH	0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0
Transaction	Tx drained 8,000 mETH	0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20
Transaction	Tx drained 401,346 ETH	0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c
Transaction	Tx drained 90 USDT	0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9

Summary

This incident demonstrated how a compromise of off-chain infrastructure can cascade into catastrophic on-chain losses. The attacker chained a Web2 breach, a frontend manipulation, and a proxy upgrade into a single attack path that bypassed multisig protection without exploiting any on-chain vulnerability.

Key lessons:

Frontend integrity deserves the same attention as on-chain security. The attack chain began at the frontend serving layer. As dApps increasingly mediate high-value transactions, protecting frontend code with integrity verification (SRI, code signing, reproducible builds) and monitoring for unauthorized changes becomes a baseline requirement.
Hardware wallet verification remains difficult in practice. Hardware wallets can display the actual signing payload, but interpreting complex multisig transaction data on a small screen is a known usability challenge. Improving the readability of on-device transaction summaries is an open problem for the wallet ecosystem.
Proxy upgrade mechanisms are high-leverage targets. The Safe proxy architecture routes all logic through a single upgradeable pointer. Any mechanism that allows a one-step implementation replacement concentrates risk. Adding a timelock, a secondary confirmation step, or an independent guardian for upgrades can reduce the impact of a single compromised transaction.

Reference

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.