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

avatar
PANews
02-25
This article is machine translated
Show original

Event Overview

On February 21, 2025 at 2:16:11 PM UTC, Bybit's Ethereum cold wallet (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4[1]) was drained of funds due to a malicious contract upgrade. According to a statement by Bybit CEO Ben Zhou[2], the attacker used a phishing attack to trick the cold wallet signers into erroneously signing a malicious transaction. He mentioned that the transaction was disguised as a legitimate operation: the Safe{Wallet} interface showed a normal transaction, but the data sent to the Ledger device had been tampered with to contain malicious content. The attacker obtained three valid signatures, replaced the implementation contract of the Safe multi-sig wallet with a malicious contract, and stole the funds. This vulnerability resulted in a loss of approximately $1.46 billion, making it the largest security incident in the history of Web3.0.

Attack Transaction Records

Upgrading the Safe wallet implementation contract to a malicious contract:

https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882

Multiple transactions transferring funds from the 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-sig cold wallet (victim)[8]
  • Attacker's initial attack operation address[9]
  • Malicious implementation contract[10]
  • Attack contract used during the Safe "delegate call" process[11]

Attack Procedure

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

  • These contracts contained backdoor functions for fund transfers[12]
  • And code to modify storage slots to enable contract upgrades[13]

2. On February 21, 2025, the attacker tricked the three multi-sig wallet owners (signers) into signing a malicious transaction, thereby upgrading the Safe's implementation contract to the previously deployed malicious contract with a backdoor[14]: https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882

3. The "operation" field value in the attack transaction was "1", indicating that the GnosisSafe contract should execute a "delegatecall", while "0" would indicate a "Call".

Bybit被盗事件技术分析:设备入侵可能是关键因素

4. The transaction executed a delegatecall to another contract (0x96221423681a6d52e184d440a8efcebb105c7242[15]) deployed by the attacker, which contained a "transfer()" function that modified the first storage slot "uint256 _transfer" of the contract.

Bybit被盗事件技术分析:设备入侵可能是关键因素

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

Bybit被盗事件技术分析:设备入侵可能是关键因素

Bybit被盗事件技术分析:设备入侵可能是关键因素

By modifying the first storage slot of the Gnosis Safe contract, the attacker was able to change the implementation contract address (the "masterCopy" address).

Bybit被盗事件技术分析:设备入侵可能是关键因素

Bybit被盗事件技术分析:设备入侵可能是关键因素

From the transaction details, we can see that the attacker set the "masterCopy" address to 0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516, which contained the "sweepETH()" and "sweepERC20()" functions described below.

Bybit被盗事件技术分析:设备入侵可能是关键因素

5. The contract upgrade method used by the attacker was highly unconventional, as it was specifically designed to avoid detection of the malicious intent. From the perspective of the Bybit signers, the signed data appeared to be a simple "transfer(address, uint256)" function call, rather than a suspicious "upgrade" function.

6. The upgraded malicious implementation contract[16] contained the backdoor functions "sweepETH()" and "sweepERC20()", which the attacker used to transfer all the assets from the cold wallet, ultimately resulting in the theft of $1.4 billion worth of ETH.

Bybit被盗事件技术分析:设备入侵可能是关键因素

Vulnerability Analysis

The root cause of this vulnerability was a successful phishing attack. The attacker tricked the wallet signers into signing malicious transaction data, ultimately leading to the contract being maliciously upgraded. This upgrade allowed the attacker to gain control of the cold wallet and transfer all its assets. The specific planning and implementation details of the phishing attack are still unclear.

According to Bybit CEO Ben Zhou's explanation during a live stream on X platform two hours after the incident, the Bybit team was executing a routine asset transfer from the cold wallet to the hot wallet when the event occurred, and he was the last signer of the Safe multi-sig transaction. He explicitly stated that the transaction had been disguised - all signers saw the correct address and transaction data 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 tampered with. Ben Zhou also mentioned that he did not re-verify the transaction details on the Ledger device interface. There is currently no definitive conclusion 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 indicating that this attack was planned and executed by the LAZARUS hacker group.

Lessons Learned

This incident is reminiscent of the Radiant Capital vulnerability incident on October 16, 2024 (reference 1[18], reference 2[19]), which resulted in the theft of approximately $50 million. In that case, the attacker gained access to the developer's device, tampered with the Safe{Wallet} front-end interface to display legitimate transaction data, while the data actually sent to the hardware wallet was malicious. This type of tampering could not be detected during manual interface review or Tenderly simulation testing. The attacker initially gained access by impersonating a trusted contractor, sending a compressed PDF file containing malware (establishing a macOS persistent backdoor) to the target via Telegram messages.

Although the root cause of the interface tampering 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 prerequisites for successful attacks: 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:

Spreading malware through social engineering to compromise the victim's device is still a major means of large-scale attacks in the Web3.0 domain. Nation-state hacker groups (such as the LAZARUS GROUP) often use this method to breach the initial defense line. Device compromise can effectively bypass security controls.

Mitigation Strategies:

  • Strengthen device security: Implement strict endpoint security policies and deploy EDR solutions (such as CrowdStrike).
  • Dedicated signing devices: Use dedicated devices in an isolated environment to perform transaction signing, avoiding the risks of multi-purpose devices.
  • Temporary operating systems: Configure non-persistent operating systems (such as temporary virtual machines) for critical operations (like multi-sig 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-sig signers) to raise security awareness.
  • Red team exercises: Simulate attacker tactics to evaluate the effectiveness of existing security controls and strengthen them accordingly.

2. Blind Signing Vulnerability:

Blind signing refers to users signing transactions without fully verifying the transaction details, leading to malicious transactions being accidentally authorized. Such unsafe operations are common among DeFi users and are particularly dangerous for Web3.0 institutions managing large assets. The hardware wallet Ledger has recently started discussing this issue (see reference 1[20], reference 2[21]). In the Bybit incident, a malicious interface hid the true intent of the transaction, causing the modified data to be sent to the Ledger device, and the signer did not verify the details on the device, ultimately leading to the vulnerability.

Mitigation strategies:

  • Avoid unverified Dapps: Interact only with trusted platforms; access official platforms via bookmarks to avoid phishing links.
  • Hardware wallet secondary verification: Confirm transaction details (recipient address, amount, function call) item by item on the Ledger or similar device screen to ensure they match your expectations.
  • Transaction simulation: Simulate the transaction before signing to observe the result and verify its correctness.
  • Use non-visual interfaces: Choose command-line tools (CLI) to reduce reliance on third-party graphical interfaces, as CLI reduces the risk of UI manipulation and provides a more transparent view of transaction data.
  • Abort on anomaly: If any part of the transaction is anomalous, immediately terminate the signing process and initiate an investigation.
  • Dual-device verification mechanism: Before signing, use a separate device to independently verify the transaction data. This device should generate a readable signature verification code that matches the data displayed on the hardware wallet.

Following the multi-million dollar losses at Radiant Capital and WazirX2[22], Bybit has become the largest victim of theft in Web3.0 history. The frequency and complexity of such attacks are continuously escalating, exposing significant operational security flaws in the industry. Attackers are systematically targeting high-value targets. As the adversary's capabilities improve, centralized exchanges (CEX) and Web3.0 institutions must comprehensively enhance their security defenses and be vigilant against the evolving 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

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
Add to Favorites
Comments
Followin logo