Event Overview
On February 21, 2025 at 02:16:11 PM UTC, Bybit’s Ethereum cold wallet (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4[1]) suffered fund theft due to a malicious contract upgrade. According to a statement by Bybit CEO Ben Zhou[2], the attacker tricked the cold wallet signer into mistakenly signing a malicious transaction through a phishing attack. He mentioned that the transaction was disguised as a legitimate operation: the Safe{Wallet} interface showed a normal transaction, but the data actually sent to the Ledger device had been tampered with with malicious content. The attacker successfully obtained three valid signatures and replaced the implementation contract of the Safe multi-signature wallet with a malicious contract, thereby stealing funds. This vulnerability caused a loss of approximately US$1.46 billion, becoming the largest security incident in the history of Web3.0.
Attack transaction records
Upgrade the Safe wallet implementation contract to a malicious contract:
https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
Multiple transactions to transfer funds from Bybit cold wallet:
401,346 ETH[ 3 ]
15,000 cmETH[ 4 ]
8,000 mETH[ 5 ]
90,375 stETH[ 6 ]
90 USDT[ 7 ]
Main Address
Bybit multi-signature cold wallet (victim) [8]
The attackers first attack operation address [9]
Malicious contract implementation[10]
Attack contract used in Safe delegate call process [11]
Attack Process
1. The attacker deployed two malicious contracts three days before the attack (February 18, 2025, UTC time).
These contracts contain backdoor functionality for transferring funds.[12]
and code for modifying storage slots to enable contract upgrades [13]
2. On February 21, 2025, the attacker tricked the owners (signers) of three multi-signature wallets into signing a malicious transaction, thereby upgrading the Safe implementation contract to a previously deployed malicious contract containing a backdoor [14]: https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
3. The “operation” field value in the attack transaction is “1”, instructing the GnosisSafe contract to execute “delegatecall”, while “0” indicates “Call”.
4. The transaction executed a delegate call to another contract deployed by the attacker (0x96221423681a6d52e184d440a8efcebb105c7242[ 15 ]), which contained a “transfer()” function that modified the first storage slot of the contract, “uint 256 _transfer”, when called.
In the GnosisSafe contract, the first storage slot contains the “masterCopy” address, which is the implementation contract address of the GnosisSafe contract.
By modifying the first storage slot of the Gnosis Safe contract, the attacker was able to change the implementation contract address (i.e. the “masterCopy” address).
From the transaction details, we can see that the attacker set the “masterCopy” address to 0x bDd 077 f 651 EBe 7 f 7 b3 cE 16 fe 5 F 2b 025 BE 2969516 , which contains the “sweepETH()” and “sweepERC 20()” functions described below.
5. The contract upgrade method used by the attacker is unconventional and is specifically designed to avoid detection of the attack intent. From the perspective of the Bybit signer, the signed data looks like a simple “transfer(address, uint 256)” function call, rather than an “upgrade” function that might arouse suspicion.
6. The upgraded malicious implementation contract [16] contained the backdoor functions “sweepETH()” and “sweepERC 20()”. By calling these functions, the attacker transferred all assets in the cold wallet, ultimately resulting in the theft of $1.4 billion in ETH.
Vulnerability Analysis
The root cause of this vulnerability is a successful phishing attack. The attacker tricked the wallet signer into signing malicious transaction data, which eventually led to a malicious contract upgrade. This upgrade allowed the attacker to control the cold wallet and transfer all its funds. At present, the specific planning and implementation of the phishing attack is still unclear.
According to Bybit CEO Ben Zhou’s explanation in a live broadcast on the X platform two hours after the vulnerability occurred, the Bybit team was executing the regular asset transfer process from cold wallet to hot wallet when the incident occurred, and he was the last signatory of the Safe multi-signature transaction. He clearly pointed out that the transaction was disguised - the address and transaction data seen by all signatories on the Safe{Wallet} interface were displayed as correct content, and the URL had been officially verified by Safe{Wallet}. However, when the transaction data was sent to the Ledger hardware wallet for signing, the actual content had been tampered with. Ben Zhou also mentioned that he did not double-check the transaction details on the Ledger device interface. There is no conclusion yet on how the attacker tampered with the Safe{Wallet} interface. According to information disclosed by Arkham[17], on-chain analyst @zachxbt has submitted conclusive evidence that the attack was planned and carried out by the LAZARUS hacker group.
Lessons Learned
This incident is reminiscent of the Radiant Capital breach on October 16, 2024 (reference 1 [18], reference 2 [19]), which resulted in the theft of approximately $50 million. At the time, the attacker compromised the developers device and tampered with the Safe{Wallet} front-end interface to display legitimate transaction data, while the data actually sent to the hardware wallet was malicious content. Such tampering could not be detected in manual interface review or Tenderly simulation testing. The attacker initially gained access to the device by posing as a trusted former contractor and sending a compressed PDF file containing malware (creating a persistent backdoor in macOS) to the target via Telegram messages.
Although the root cause of the interface tampering in the Bybit incident has not been confirmed, device intrusion may be a key factor (similar to the Radiant Capital incident). Both incidents reveal two prerequisites for the success of the attack: device intrusion and blind signing behavior. Given the increasing frequency of such attacks, we need to focus on analyzing the following two attack methods and mitigation strategies:
1. The device is hacked:
Spreading malware through social engineering to invade victim devices is still the main means of large-scale attacks in the Web3.0 field. National hacker groups (such as LAZARUS GROUP) often use this method to break through the initial defense line. Device intrusion can effectively bypass security control measures.
Mitigation strategies:
Strengthen device security: Develop a strict endpoint security policy and deploy an EDR solution such as CrowdStrike.
Dedicated signing device : Use dedicated devices in an isolated environment to perform transaction signing, avoiding the risk of multi-purpose devices being exposed.
Temporary operating system: Configure a non-persistent operating system (such as a temporary virtual machine) for critical operations (such as multi-signature transactions) to ensure a clean operating environment.
Phishing simulation drills: Regularly conduct phishing attack simulations on high-risk roles (such as crypto asset operators and multi-signature signers) to enhance security awareness.
Red Team Attack and Defense Drills: Simulate attacker tactics to evaluate the effectiveness of existing security controls and strengthen them accordingly.
2. Blind Signature Vulnerability:
Blind signature means that the user signs a transaction without fully verifying the transaction details, which results in malicious transactions being accidentally authorized. This type of unsafe operation is common among DeFi users and is particularly dangerous for Web3.0 institutions that manage high-value assets. Hardware wallet Ledger has recently discussed this issue (reference 1 [20], reference 2 [21]). In the Bybit incident, the malicious interface concealed the true intention of the transaction, resulting in tampered data being sent to the Ledger device, and the signer did not verify the details on the device, which ultimately caused the vulnerability.
Mitigation strategies:
Avoid unverified Dapps: Only interact with trusted platforms; access official platforms through bookmarks and avoid phishing links.
Second verification of hardware wallet: Confirm the transaction details (receiving address, amount, function call) item by item on the screen of the Ledger or other device to ensure that they are consistent with expectations.
Transaction simulation: Before signing, simulate the transaction to observe its results and verify its correctness.
Use a non-visual interface: Choose a command line tool (CLI) to reduce reliance on third-party graphical interfaces. CLI reduces the risk of UI manipulation and provides a more transparent view of transaction data.
Abnormal termination: If there is any abnormality in any part of the transaction, the signing process will be terminated immediately and an investigation will be initiated.
Dual-device verification mechanism: Before signing, use a separate device to independently verify the transaction data. The device should generate a readable signature verification code that matches the data displayed on the hardware wallet.
Following the tens of millions of dollars lost by Radiant Capital and WazirX 2 [22], Bybit became the victim of the largest theft in the history of Web3.0. The frequency and complexity of such attacks continue to escalate, exposing major flaws in the industrys operational security. Attackers are systematically targeting high-value targets. As adversaries capabilities increase, centralized exchanges (CEX) and Web3.0 institutions must comprehensively improve their security protection levels and be vigilant to the iterative evolution of external threats.
