GuShiio.com Although the root cause of interface tampering in the Bybit incident has not been confirmed, device intrusion may be a key factor.
event summary
At 02:16:11 pm UTC time on February 21, 2025, Bybit’s Ethereum cold wallet (0x1db92e2eebc8e0c075a02bea49a2935 bcd2dfcf 4[1]) was stolen due to a malicious contract upgrade. According to a statement by Bybit CEO Ben Zhou [2], attackers used phishing attacks to trick cold wallet signers into mistakenly signing malicious transactions. He mentioned that the transaction was disguised as a legal operation: the Safe{Wallet} interface showed a normal transaction, but the data actually sent to the Ledger device had been tampered with into malicious content. The attacker successfully obtained three valid signatures and replaced the implementation contract of Safe Multisign Wallet with a malicious contract, thereby stealing funds. The breach caused approximately US$1.46 billion in losses, making it the largest security incident in Web 3.0 history.
Attack transaction records
Upgrade Safe Wallet Implementation Contract to 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]
primary address
- Bybit multi-signed cold wallet (victim)[8]
- Address of attacker’s first attack operation [9]
- Malicious implementation of contract [10]
- Attack contract used during Safe “delegate call”[11]
attack flow
1. The attacker deployed two malicious contracts three days before the attack (February 18, 2025, UTC time).
- These contracts include backdoor functions for fund transfers [12]
- and code to modify storage slots to implement contract upgrades [13]
2. On February 21, 2025, the attacker induced the owners (signers) of three multi-signature wallets to sign malicious transactions, thereby upgrading Safe’s implementation contract to the previously deployed malicious contract containing backdoors [14]: etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882
3. The “operation” field value in the attack transaction is “1”, indicating that the GnosisSafe contract executes “delegatecall”, and “0” means “Call”.
4. The transaction executed a delegation call to another contract deployed by the attacker (0x96221423681a6d52e184d440a8efcebb105c7242 [15]), which contains a “transfer()” function that modifies the contract’s first storage slot “uint256_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, an attacker can change the implementation contract address (i.e., the “masterCopy” address).
As can be seen from the transaction details, the attacker set the “masterCopy” address to 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516, which contains the “sweetETH ()” and “sweetERC20 ()” functions described below.
5. The contract upgrade method used by attackers is unconventional and is specially designed to prevent attack intentions from being discovered. From the Bybit signer’s perspective, the signed data appears to be a simple “transfer(address, uint256)” function call, rather than an “upgrade” function that might arouse suspicion.
6. The upgraded malicious implementation contract [16] contains backdoor functions “sweetETH ()” and “sweetERC20 ()”. By calling these functions, the attacker transferred all assets in the cold wallet, ultimately causing the theft of US$1.4 billion in ETH.
vulnerability analysis
The root cause of this vulnerability lies in a successful phishing attack. The attacker tricked the wallet signer into signing malicious transaction data, which eventually led to the contract being maliciously upgraded. The upgrade allows attackers to control cold wallets and transfer all of their funds. At present, the specific planning and execution methods of phishing attacks are still unclear.
According to Bybit CEO Ben Zhou’s explanation in a live broadcast on the X platform two hours after the breach occurred, Bybit’s team was performing a regular asset transfer process from cold wallet to hot wallet when the incident occurred, and he himself was the last signer of the Safe multi-sign transaction. He made it clear that the transaction had been disguised-all addresses and transaction data seen by the signer 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 is sent to the Ledger hardware wallet for signature, the actual content has been tampered with. Ben Zhou also mentioned that he did not re-verify transaction details on the Ledger device interface. There is currently no final conclusion on how attackers tampered with the Safe {Wallet} interface. According to information disclosed by Arkham [17], online analyst@zachxbt has submitted conclusive evidence that the attack was planned and carried out by the LAZARUS hacking group.
experience and lessons
This incident is reminiscent of the Radiant Capital vulnerability incident on October 16, 2024 (Ref 1[18], Ref 2[19]), which resulted in the theft of approximately US$50 million. At that time, the attacker hacked into the developer’s device and tampered with the Safe{Wallet} front-end interface to make it display legal transaction data, while the data actually sent to the hardware wallet was malicious content. Such tampering cannot be detected in manual interface review or Tenderly simulation testing. The attacker initially gained device access by posing as a trusted former contractor and sending a compressed PDF file containing malware (creating a macOS persistent backdoor) to the target via Telegram messages.
Although the root cause of 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 revealed two prerequisites for a successful attack: device intrusion and blind signing. In view of the increasing frequency of such attacks, we need to focus on analyzing the following two attack methods and mitigation strategies:
1. Equipment hacked:
Spreading malware through social engineering to invade victim devices remains the main means of large-scale attacks in the Web 3.0 field. National hacker organizations (such as LAZARUS GROUP) often use this method to break through initial defenses. Device intrusion can effectively bypass security controls.
Mitigation strategies:
- Strengthen device security: Develop strict endpoint security policies and deploy EDR solutions such as CrowdStrike.
- Dedicated signature device: Use dedicated devices to perform transaction signatures in an isolated environment to avoid exposure to multi-purpose devices.
- Temporary operating system: Configure non-persistent operating systems (such as temporary virtual machines) for critical operations (such as multi-signed transactions) to ensure a clean operating environment.
- Phishing simulation drills: Regularly simulate phishing attacks on high-risk characters (such as cryptographic asset operators and multi-signers) to improve security awareness.
- Red Team Attack and Defense Exercise: Simulate attacker tactics, evaluate the effectiveness of existing security control measures and strengthen them in a targeted manner.
2. Blind signing loopholes:
Blind signature means that a user signs a transaction without fully verifying the transaction details, resulting in the malicious transaction being accidentally authorized. Such unsafe operations are common among DeFi users and are particularly dangerous to Web 3.0 organizations that manage high 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, causing the tampered data to be sent to the Ledger device, but the signer did not verify the details on the device side, ultimately causing the vulnerability.
Mitigation strategies:
- Avoid unverified Dapps: Only interact with trusted platforms; access official platforms through bookmarks and avoid phishing links.
- Secondary verification of hardware wallet: Confirm the transaction details (collection address, amount, function call) item by item on the screen of Ledger and other equipment to ensure that they are consistent with expectations.
- Transaction simulation: Before signing, simulate a transaction to observe the results and verify their correctness.
- Use a non-visual interface: Select the 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.
- Termination if there is an exception: If there is an exception in any part of the transaction, the signing process is terminated immediately and an investigation is initiated.
- Dual-device verification mechanism: A separate device is used to independently verify transaction data before signing. The device should generate a readable signature Captcha that matches the data displayed on the hardware wallet.
Following tens of millions of dollars in losses from Radiant Capital and WazirX2 [22], Bybit became the victim of the largest theft in Web 3.0 history. The frequency and complexity of such attacks continue to escalate, exposing major flaws in the industry’s operation and maintenance security. Attackers are systematically targeting high-value targets. As the capabilities of opponents improve, centralized exchanges (CEX) and Web 3.0 institutions must comprehensively improve their security protection levels and be alert to the iterative evolution of external threats.
[1] :https://etherscan.io/address/0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4
[2] :https://x.com/Bybit_Official/status/1892986507113439328
[3] :https://etherscan.io/tx/0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c
[4] :https://etherscan.io/tx/0x847b8403e8a4816a4de1e63db321705cdb6f998fb01ab58f653b863fda988647
[5] :https://etherscan.io/tx/0xbcf316f5835362b7f1586215173cc8b294f5499c60c029a3de6318bf25ca7b20
[6] :https://etherscan.io/tx/0xa284a1bc4c7e0379c924c73fcea1067068635507254b03ebbbd3f4e222c1fae0
[7] :https://etherscan.io/tx/0x25800d105db4f21908d646a7a3db849343737c5fba0bc5701f782bf0e75217c9
[8] :https://etherscan.io/address/0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4
[9] :https://etherscan.io/address/0x0fa09c3a328792253f8dee7116848723b72a6d2e
[10] :https://etherscan.io/address/0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516
[11]:https://etherscan.io/address/0x96221423681A6d52E184D440a8eFCEbB105C7242#code
[12] :https://etherscan.io/address/0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516
[13] :https://etherscan.io/address/0x96221423681A6d52E184D440a8eFCEbB105C7242#code
[14] :https://etherscan.io/address/0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516
[15] :https://etherscan.io/address/0x96221423681A6d52E184D440a8eFCEbB105C7242
[16] :https://etherscan.io/address/0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516
[17]:https://x.com/arkham/status/1893033424224411885
[18] :https://medium.com/@RadiantCapital/radiant-post-mortem-fecd6cd38081
[19] :https://medium.com/@RadiantCapital/radiant-capital-incident-update-e56d8c23829e
[20] :https://www.ledger.com/academy/topics/ledgersolutions/what-is-clear-signing
[21] :https://www.youtube.com/watch? v=-O7aX6vUvs8
[22]:https://wazirx.com/blog/wazirx-cyber-attack-key-insights-and-learnings
