Technical analysis of Bybit theft incident: Device intrusion may be a key factor

Event Overview

On February 21, 2025, at 02:16:11 pm UTC time, Bybit's Ethereum Cold Wallet (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4[1]) was stolen by funds due to malicious contract upgrades. According to the statement [2] of Bybit CEO Ben Zhou, the attacker tricked cold wallet signatures into mistakenly signing malicious transactions through phishing attacks. He mentioned that the transaction was disguised as a legal operation: the Safe{Wallet} interface shows up as a normal transaction, but the data actually sent to the Ledger device has been tampered with malicious content. The attacker successfully obtained three valid signatures and replaced the implementation contract of Safe multi-sign wallet with a malicious contract, thereby stealing funds. The vulnerability caused approximately US$1.46 billion in losses, making it the largest security incident in Web3.0's history.

Attack transaction history

Upgrade Safe wallet to implement contracts to malicious contracts:

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-Signal Cold Wallet (Victim)[8]
• The attacker's first attack operation address[9]
• Maliciously implementing the contract[10]
• The attack contract used during Safe "delegate call"11

Attack process

1. The attacker deployed two malicious contracts three days before the attack (UTC time on February 18, 2025).

• These contracts include the backdoor function of capital transfer [12]
• And the code used to modify the storage slot to achieve contract upgrade [13]

2. On February 21, 2025, the attacker induced the owner (signer) of three multi-signature wallets to sign a malicious transaction, thereby upgrading the implementation contract of Safe to a malicious contract with a backdoor that was previously deployed [14]: https ://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882

3. The value of the "operation" field in the attack transaction is "1", indicating that the GnosisSafe contract executes "delegatecall", and "0" means "Call".

4. The transaction executes another contract that is delegated to the attacker deployed (0x96221423681a6d52e184d440a8efcebb105c7242[15]). The contract contains a "transfer()" function that modifies the first storage slot of the contract when called "uint256_transfer".

In the GnosisSafe contract, the first storage slot contains the "masterCopy" address, that is, the implementation contract address of the GnosisSafe contract.

By modifying the first storage slot of the Gnosis Safe contract, the attacker can change the implementation contract address (i.e. the "masterCopy" address).

As can be seen from the transaction details, the attacker sets the "masterCopy" address to 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516, which contains the "sweepETH()" and "sweepERC20()" functions described below.

5. The contract upgrade method used by the attacker is unconventional, and it is specially designed to avoid the discovery of the attack intention. From the Bybit signer's perspective, the signed data looks like a simple "transfer(address, uint256)" function call, rather than a "upgrade" function that may cause doubt.

6. The upgraded malicious implementation contract [16] includes the backdoor functions "sweepETH()" and "sweepERC20()". The attacker transferred all assets in the cold wallet by calling these functions, which eventually caused 1.4 billion US dollars of ETH. Stolen.

Vulnerability Analysis

The root 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 escalation allows the attacker to control the cold wallet and transfer all of its funds. At present, the specific planning and implementation methods of phishing attacks are still unclear.

According to the instructions of Bybit CEO Ben Zhou on the X platform live broadcast two hours after the vulnerability occurred, the Bybit team was carrying out the regular asset transfer process from cold wallet to hot wallet when the incident occurred, and he himself was the last signing of Safe's multiple transactions . He clearly pointed out that the transaction was processed in disguise - all the addresses and transaction data seen by the signers on the Safe{Wallet} interface are displayed as correct content, and the URL has 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 verify transaction details on the Ledger device interface. There is no conclusion yet on how an attacker tampers 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 implemented by the LAZARUS hacker organization.

Experience and lessons

The incident is reminiscent of the Radiant Capital vulnerability incident on October 16, 2024 (reference 1[18], reference 2[19]), which resulted in the stolen $50 million. At that time, the attacker invaded the developer's device and tampered with the Safe{Wallet} front-end interface to make it display legitimate transaction data, while the data actually sent to the hardware wallet was malicious content. Such tampering cannot be detected in manual interface review and Tenderly simulation tests. The attacker initially gained access to the device by impersonating a trusted former contractor and sending compressed PDF files containing malware (establishing macOS lasting backdoor) to the target via Telegram messages.

Although the root cause of interface tampering in Bybit events has not been confirmed, device intrusion may be a key factor (similar to the Radiant Capital event). Both incidents revealed two prerequisites for the successful attack: device intrusion and blind signing. Given that such attacks are becoming more frequent, we need to focus on analyzing the following two attack methods and mitigation strategies:

1. The device is hacked:

The spread of malware invasion of victim devices through social engineering remains the main means of large-scale attacks in the Web3.0 field. National hacking organizations such as LAZARUS GROUP often use this method to break through the initial defense line. Equipment intrusion can effectively bypass safety control measures.

Mitigation strategies:

• Strengthen device security: Develop strict endpoint security policies and deploy EDR solutions (such as CrowdStrike).
• Dedicated signature equipment: Use special equipment to execute transaction signatures in an isolated environment to avoid the risk of exposure of multi-purpose equipment.
• Temporary operating system: Configure a non-persistent operating system (such as temporary virtual machines) for critical operations (such as multi-sign transactions) to ensure a clean operating environment.
• Phishing simulation drill: Regularly simulate phishing attacks on high-risk roles (such as crypto asset operators, multi-signature signers) to improve security awareness.
• Red Team Offensive and Defensive Drill: Simulate attacker tactics, evaluate the effectiveness of existing security control measures and strengthen targetedly.

2. Blind sign loopholes:

Blind signature refers to the user signing a transaction without fully verifying the details of the transaction, resulting in the malicious transaction being accidentally authorized. Such unsafe operations are common among DeFi users and are particularly dangerous for Web3.0 institutions that manage high-value assets. The hardware wallet Ledger has recently discussed this issue (reference 1 [20], reference 2 [21]). In the Bybit event, the malicious interface hides the true intention of the transaction, causing the tampered data to be sent to the Ledger device, while the signer fails to verify the details on the device side, which eventually leads to a vulnerability.

Mitigation strategies:

• Avoid unverified Dapps: interact only with trusted platforms; access the official platform through bookmarks to avoid phishing links.
• Secondary verification of hardware wallet: Confirm transaction details (receipt address, amount, function call) item by item on the screen of Ledger and other devices to ensure that they are consistent with expectations.
• Transaction simulation: Before signing, simulate a transaction to observe its results and verify its correctness.
• Using non-visual interfaces: Select Command Line Tools (CLIs) to reduce dependence on third-party graphical interfaces. CLI reduces the risk of UI manipulation and provides a more transparent view of transaction data.
• Exception is termination: If there is an exception in any part of the transaction, immediately terminate the signature process and start the investigation.
• Dual-device verification mechanism: Use a separate device to independently verify transaction data before signing. The device should generate a readable signature verification code that matches the data displayed on the hardware wallet.

Following tens of millions of dollars in losses from Radiant Capital and WazirX222, Bybit became the victim of the largest theft in Web3.0 history. The frequency and complexity of such attacks continue to escalate, exposing major shortcomings in the industry in operation and maintenance security. Attackers are systematically attacking high-value targets. With the improvement of opponent capabilities, centralized exchanges (CEX) and Web3.0 institutions must comprehensively improve their security protection levels and be wary of 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

[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

[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