Incident Overview
On February 21, 2025, at 02:16:11 UTC, Bybit's Ethereum cold wallet (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4[1]) was compromised due to a malicious contract upgrade, resulting in the theft of funds. According to Bybit CEO Ben Zhou's statement[2], the attacker tricked the cold wallet signers 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 appeared as a normal transaction, but the data sent to the Ledger device had been altered to malicious content. The attacker successfully obtained three valid signatures, replacing the implementation contract of the Safe multi-signature wallet with a malicious contract, thereby stealing funds. This vulnerability resulted in a loss of approximately $1.46 billion, marking it as the largest security incident in Web3.0 history.
Attack Transaction Records
Upgrade Safe wallet implementation contract to malicious contract:
https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
Multiple transactions transferring funds from Bybit cold wallet:
401,346 ETH[3]
15,000 cmETH[4]
8,000 mETH[5]
90,375 stETH[6]
90 USDT[7]
Key Addresses
Bybit multi-signature cold wallet (victim)[8]
Attacker's initial attack operation address[9]
Malicious implementation contract[10]
Attack contract used during Safe "delegate call" process[11]
Attack Process
- The attacker deployed two malicious contracts three days before the attack (February 18, 2025, UTC).
These contracts contained backdoor functions for fund transfers[12]
And code to modify storage slots for contract upgrades[13]
On February 21, 2025, the attacker lured the owners (signers) of three multi-signature wallets to sign a malicious transaction, upgrading the Safe implementation contract to the previously deployed malicious contract with backdoors[14]: https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
The "operation" field value in the attack transaction was "1", indicating that the GnosisSafe contract executed a "delegatecall", while "0" indicated "Call".
- 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 "uint256 _transfer" upon invocation.
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, it can be seen that the attacker set the "masterCopy" address to 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516, which contains the "sweepETH()" and "sweepERC20()" functions described below. 
The contract upgrade method used by the attacker was unconventional, specifically designed to avoid detection of malicious intent. From the perspective of Bybit signers, the signed data appeared to be a simple "transfer(address, uint256)" function call, rather than a potentially suspicious "upgrade" function.
The upgraded malicious implementation contract[16] contained backdoor functions "sweepETH()" and "sweepERC20()", which the attacker called to transfer all assets from the cold wallet, ultimately resulting in $1.4 billion worth of ETH being stolen.
Vulnerability Analysis
The root cause of this vulnerability lies in a successful phishing attack. The attacker tricked the wallet signers into signing malicious transaction data, ultimately leading to the malicious upgrade of the contract. This upgrade allowed the attacker to control the cold wallet and transfer all its funds. The specific planning and execution methods of the phishing attack remain unclear.
According to Bybit CEO Ben Zhou's explanation during a live broadcast on the X platform two hours after the vulnerability occurred, the Bybit team was executing a routine asset transfer process from cold wallet to hot wallet at the time of the incident, and he himself was the last signer of the Safe multi-signature transaction. He explicitly stated that the transaction was disguised— all signers saw the address and transaction data displayed correctly on the Safe{Wallet} interface, and the URL had been verified by the official Safe{Wallet}. However, when the transaction data was sent to the Ledger hardware wallet for signing, the actual content had been altered. Ben Zhou also mentioned that he did not verify the transaction details a second time on the Ledger device interface. There is currently no conclusion on how the attacker altered the Safe{Wallet} interface. According to information disclosed by Arkham[17], on-chain analyst @zachxbt has submitted conclusive evidence indicating that the attack was orchestrated by the LAZARUS hacker group.
Lessons Learned
This incident recalls the Radiant Capital vulnerability incident on October 16, 2024 (Reference 1[18], Reference 2[19]), which resulted in approximately $50 million being stolen. At that time, the attacker compromised the developer's device, altering the Safe{Wallet} front-end interface to display legitimate transaction data, while the actual data sent to the hardware wallet was malicious content. Such alterations could not be detected during manual interface reviews and Tenderly simulation tests. The attacker initially impersonated a trusted contractor, sending a compressed PDF file containing malware (establishing a macOS persistent backdoor) via Telegram messages to gain access to the device.
Although the root cause of the interface alteration in the Bybit incident has not been confirmed, device compromise may be a key factor (similar to the Radiant Capital incident). Both incidents reveal two major prerequisites for the success of the attack: device compromise 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. Device Compromise:
The spread of malware through social engineering to compromise victim devices remains a primary method for large-scale attacks in the Web3.0 space. Nation-state hacker groups (such as the LAZARUS GROUP) often utilize this method to breach initial defenses. Device compromise can effectively bypass security controls.
Mitigation Strategies:
Enhance Device Security: Establish strict endpoint security policies and deploy EDR solutions (such as CrowdStrike).
Dedicated Signing Devices: Use dedicated devices in isolated environments for transaction signing to avoid risks associated with multi-purpose devices.
Temporary Operating Systems: Configure non-persistent operating systems (such as temporary virtual machines) for critical operations (like multi-signature transactions) to ensure a clean operating environment.
Phishing Simulation Drills: Regularly conduct phishing attack simulations for high-risk roles (such as crypto asset operators and multi-signature signers) to enhance security awareness.
Red Team Exercises: Simulate attacker tactics to assess the effectiveness of existing security controls and strengthen them accordingly.
2. Blind Signing Vulnerability:
Blind signing refers to the act of users signing transactions without fully verifying the transaction details, leading to the accidental authorization of malicious transactions. Such unsafe practices are common among DeFi users and are particularly dangerous for Web3.0 institutions managing high-value assets. The hardware wallet Ledger has recently initiated discussions on this issue (Reference 1[20], Reference 2[21]). In the Bybit incident, the malicious interface concealed the true intent of the transaction, resulting in altered data being sent to the Ledger device, while the signers did not verify the details on the device, ultimately triggering the vulnerability.
Mitigation Strategies:
Avoid Unverified Dapps: Only interact with trusted platforms; access official platforms through bookmarks to avoid phishing links.
Secondary Verification on Hardware Wallets: Confirm transaction details (recipient address, amount, function call) item by item on the screen of devices like Ledger to ensure they match expectations.
Transaction Simulation: Simulate the transaction before signing to observe its outcome and verify its correctness.
Use Non-Visual Interfaces: Choose command-line tools (CLI) to reduce reliance on third-party graphical interfaces. CLI lowers the risk of UI manipulation and can provide a more transparent view of transaction data.
Terminate on Anomalies: If any part of the transaction appears abnormal, immediately terminate the signing process and initiate an investigation.
Dual Device Verification Mechanism: Use a separate device to independently verify transaction data before signing. This 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 in the Radiant Capital and WazirX2[22] incidents, Bybit has become the victim of the largest theft in Web3.0 history. The frequency and complexity of such attacks continue to escalate, exposing significant flaws in the industry's operational security. Attackers are systematically targeting high-value objectives. As adversaries' capabilities improve, centralized exchanges (CEX) and Web3.0 institutions must comprehensively enhance their security measures and remain vigilant against the iterative evolution of external threats.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
