# Technical Analysis Report: Bybit Exchange Security Breach - Principles, Process, and Recommendations

## Introduction

On February 21, 2025, the cryptocurrency exchange Bybit experienced a security breach, resulting in the loss of approximately $1.5 billion in ETH, potentially making it the largest cryptocurrency theft in history. The attack compromised Bybit's ETH multi-signature cold wallet during a routine transfer, exploiting a front-end vulnerability in *Safe Wallet* (formerly *Gnosis Safe*). Malicious code altered transaction data, ultimately draining funds from the multi-signature cold wallet. This report analyzes the technical principles and process behind the attack and provides recommendations for improving system design and security.

## Technical Principles and Process of the Attack

### Multi-Signature Wallet

*Safe Wallet* is a widely adopted multi-signature wallet implementation, a smart contract design that requires multiple private key signatures to execute transactions. It enhances security through distributed authorization, supports various blockchain networks, and provides an intuitive front-end interface for user operations. The normal multi-signature transaction signing process is as follows:

1. **Transaction Proposal**: A signer creates and proposes a transaction via the *Safe Wallet* front-end.
2. **Transaction Review**: The transaction data is broadcast to all signers for review through the front-end.
3. **Signature Verification**: Signers use their respective private keys (e.g., hot wallets such as *Metamask* or cold wallets such as *Ledger*) to sign the transaction.
4. **Transaction Execution**: Once sufficient signatures are collected, the transaction is submitted to the blockchain for execution.

### Attack Vector

The attack hinged on a combination of a supply chain attack and blind signing. The specific process unfolded as follows:

1. **Front-End Supply Chain Attack**:

* The attacker exploited a supply chain vulnerability in the *Safe Wallet* front-end, injecting malicious code through social engineering (e.g., phishing) or compromised third-party dependencies, thereby altering the displayed transaction data.
* Signers, using the tampered front-end, saw falsified transaction details and signed what they believed to be legitimate operations. For example, they might have seen a valid "transfer 10 ETH to a hot wallet" transaction, while actually approving a "replace the contract implementation with a malicious contract" operation.

2. **Transaction Tampering and Blind Signing**:

* Malicious code altered the transaction data displayed on the *Safe Wallet* front-end while simultaneously transmitting the actual malicious data to the signers' hardware wallets.
* Hardware wallets typically display simplified transaction data rather than full contract execution details, which leads signers to unknowingly approve malicious transactions. This was especially problematic with complex, encoded contract calls that hardware wallets could not fully interpret, thus deceiving the signers.

3. **Malicious Contract Deployment and Execution**:

*Safe Wallet*'s smart contract employs an upgradeable architecture, consisting of a proxy contract and an implementation contract, which makes contract upgrades a prime target. The attacker manipulated the proxy contract using the `delegatecall` function, tampering with `callData` to replace the legitimate implementation with a malicious one. Specifically, the forged transaction data might have mimicked a `transfer(address, uint256)` interface while actually executing contract upgrade logic, updating the implementation to a malicious version. Once updated, the backdoor functions in the malicious contract (`sweepETH()` & `sweepERC20()`) were triggered, enabling the transfer of funds. Analysis indicates that `callData` tampering was the key factor in the attack's success, further aggravated by hardware wallets' inability to fully display `callData`, thereby worsening the blind signing issue.

The wallet accounts, smart contracts, and executed transactions involved in this incident are as follows:

* Victim Bybit multi-signature cold wallet: [0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4](https://etherscan.io/address/0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4)
* Attacker's malicious contract with backdoor functions: [0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516](https://etherscan.io/address/0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516)
* Contract used by the attacker to update to the malicious contract: [0x96221423681A6d52E184D440a8eFCEbB105C7242](https://etherscan.io/address/0x96221423681A6d52E184D440a8eFCEbB105C7242)
* Contract used by the attacker to initiate the attack: [0x0fa09c3a328792253f8dee7116848723b72a6d2e](https://etherscan.io/address/0x0fa09c3a328792253f8dee7116848723b72a6d2e)
* Transaction in which the attacker replaced the *Safe Wallet* implementation with a malicious contract, authorized by the signatures of three signers: [0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882](https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68ad7882)
* Transaction in which about 401,000 ETH was transferred to the attacker's address: [0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c](https://etherscan.io/tx/0xb61413c495fdad6114a7aa863a00b2e3c28945979a10885b12b30316ea9f072c)



### Irregular Contract Update

In *Safe Wallet*'s design, the proxy contract uses a state variable named `masterCopy` to store the address of the implementation contract, as a key factor of the upgrade functionality. This means the contract logic can be replaced. Normally, updating `masterCopy` requires authorization from multiple signers and a formal process (e.g., calling `upgradeTo(address)`).

However, in the Bybit hack, the attacker circumvented this formal process. By exploiting a front-end supply chain attack and `callData` tampering, they manipulated transaction data to deceive signers into approving what appeared to be legitimate transfers or routine operations. In reality, the malicious `callData` contained a pre-deployed malicious contract address. This method bypassed *Safe Wallet*'s standard upgrade process by directly modifying `masterCopy`, exploiting `delegatecall` to alter its storage slot during proxy contract execution.


## Transaction Signing Process

### Normal Signing Process

The normal multi-signature signing process highlights the secure operation of a multi-signature wallet. The proposer (`Proposer`) creates a transaction and broadcasts its data to multiple signers (`Signer1`, `Signer2`, `Signer3`) via the front-end. Each signer reviews and signs the transaction using their hardware wallet (e.g., *Ledger*). Once enough signatures are collected (e.g., three required), the system submits them to the wallet contract (`WalletContract`) for transaction execution. This ensures multi-layer authorization and transparency, preventing unilateral actions.


### Compromised Signing Process

The compromised signing process reveals the attack's operations. The attacker injects malicious code into the wallet front-end (`WalletFrontend`), altering the displayed transaction data. The proposer (`Proposer`) creates a legitimate transaction and broadcasts it, but the signers (`Signer1`, `Signer2`, `Signer3`) see tampered data that appears valid. Due to hardware wallets' blind signing limitations (inability to display full `callData`), signers approve the transaction unknowingly. Once submitted, the wallet contract (`WalletContract`) executes the malicious transaction. This exposes the severe risks of supply chain attacks and UI deception.


## System Design Recommendations

To prevent such attacks, developers and operators should integrate the following measures into multi-signature wallet systems:

### 1. Secure Software Development and Distribution

* **Supply Chain Security**: Regularly audit front-end and third-party dependencies, using content integrity checks to prevent code tampering.
* **Version Control**: Ensure all signers use the latest official front-end versions, and avoid unverified mirror sites.

### 2. Multi-Layer Verification Mechanisms

* **Pre-Execution Checks**: Simulate transaction effects in a local sandbox, compare state changes, generate readable reports, and integrate threat detection engines for pattern recognition.
* **Independent Verifications**: Signers should verify transaction details using blockchain explorers (e.g., Etherscan) or independent tools (e.g., transaction simulators) to ensure independent review before execution and prevent unauthorized upgrades.
* **Execution Delay Mechanism**: Implement a timelock in smart contracts (e.g., a 72-hour delay) to allow teams sufficient time to review transactions and detect anomalies.
* **Detailed Transaction Display**: Use hardware wallets that support full transaction data and details to avoid blind signing.

### 3. `HSM` and `FIDO2` Integration

* **Hardware Security Module (`HSM`)**:

* An `HSM` is a dedicated cryptographic device designed for secure private key storage and signing, which is commonly used in enterprise environments. Enterprise-level multi-signature systems can integrate an `HSM` to ensure private keys never leave the device.
* In multi-signature wallets, signers can use `HSM` to store private keys and sign transactions, reducing the risk of approving malicious operations.

* **Fast Identity Online (`FIDO`)**:

* `FIDO2` provides passwordless authentication using security keys or biometrics, which restricts signing interface access. Only `FIDO2`-authenticated users can operate the front-end, which prevents unauthorized access.
* Combining `HSM` and `FIDO2` creates a dual-layer security framework, thereby enhancing protection.

### 4. Signing Policies and Restrictions

* **Policy Enforcement**: Implement back-end signing policies (e.g., limiting single transfer amounts or prohibiting upgrades) to block malicious transactions, even if the front-end is compromised.
* **Real-Time Monitoring**: Deploy anomaly detection systems to monitor signing behavior and transaction patterns, which can promptly intercept suspicious operations.

### 5. Regular Security Assessments and Training

* **Penetration Testing**: Conduct regular audits, assessments, and simulated attacks to identify potential vulnerabilities.
* **Staff Training**: Educate signers on phishing risks and emphasize the importance of verifying transaction data.

## Institutional-Level Security Recommendations

To strengthen the security of institutional multi-signature wallet systems — especially in light of the Bybit hack, which exposed vulnerabilities such as front-end supply chain attacks, blind signing, and unauthorized contract upgrades — the following advanced techniques and strategies are recommended:

### 1. Enhance Physical Isolation (`HSM` and `FIDO2` Integration)

* **Offline Signing Environment**: Perform transaction signing in physically isolated environments to avoid network-based remote attacks (e.g., front-end UI infiltration). Use dedicated `HSM` devices for key storage and signing, ensuring keys remain offline.
* **FIDO2 Authentication**: Combine `FIDO2` passwordless authentication with security keys or biometrics to ensure that only authorized users access the signing interface. The `FIDO2` challenge-response mechanism prevents replay attacks, thereby enhancing access security.

### 2. Enhance Technical Architecture (Multi-Signature Mechanism Design)

* **Sharded Private Key Management**: Adopt sharded key management (Shamir Secret Sharing) by splitting a single key into multiple fragments (e.g., *n* fragments, requiring *k* to sign, where `k ≤ n`) and storing them in HSM devices across different locations to prevent single-point failures or physical breaches.
* **Context-Aware Signing**: Implement context-aware signing to account for transaction context (e.g., `callData` integrity) and prevent the accidental approval of malicious transactions. Back-end validation of `callData` against formal interfaces ensures consistency. Embed contextual parameters like timestamps, asset types, and whitelisted addresses, making signatures valid only under predefined conditions.

### 3. Enhance Monitoring System (On-Chain Detection and Analysis)

* **AI Monitoring and Anomaly Detection**: Use AI to monitor transaction patterns in real-time and identify anomalies such as unusual `callData`, frequent upgrades, large asset transfers, or interactions with high-risk addresses.
* **On-Chain Behavior Analysis Engine**: Deploy an on-chain analysis engine with threat intelligence databases and address scoring to assess transaction risks and trigger alerts (e.g., to pre-detect malicious contract deployments).

### 4. Enhance Operational Workflow (Improved Signing Verification)

* **Semantic Visualization**: Develop tools to convert `callData` into natural language descriptions, highlighting key parameters such as contract address changes or permission modifications to aid signers in understanding transactions and avoiding UI deception.
* **Cross-Chain Feature Matching**: Automatically compare current transactions with historical patterns to detect anomalies (e.g., new cross-chain bridge addresses or unauthorized contracts) and to prevent attacks involving newly deployed malicious contracts.
* **Environmental Risk Scoring**: Integrate global threat intelligence to dynamically adjust signing risk levels based on network conditions and trigger additional precautions in high-risk scenarios.

### 5. Enhance Verification Architecture (Hybrid-Layered Verification)

* **Application Layer**:

* Conduct formal verification of smart contracts to ensure that the logic is secure and perform semantic analysis of `callData` to prevent upgrade manipulations.
* Deploy detection engine to identify supply chain attacks and UI deception.

* **Physical Layer**:

* Use `HSM` hardware signing to ensure device integrity through regular checks and tamper-proof encapsulation, thereby preventing physical attacks.
* Leverage `FIDO2` device authentication and challenge-response mechanisms for multi-layer verification, blocking unauthorized access.
* Integrate `HSM` with `FIDO2` to require dual-layer authentication, reducing social engineering risks.

## Conclusion

The Bybit hack exposed the fragility of multi-signature wallet systems to supply chain attacks and blind signing, making digital asset security an industry priority. By adopting multi-layer verification, `HSM` and `FIDO2` integration, and robust software security practices, developers and operators can significantly mitigate such risks. The blockchain industry must learn from this incident and advance secure system designs and operational standards to counter evolving threats. Moreover, adopting advanced prevention techniques — shifting assumptions from "preventing key leaks" to "assuming signing processes are susceptible to compromise" — is crucial to addressing complex attacks.

SecuX, a Web3 security solutions provider, is dedicated to developing and delivering advanced `HSM` solutions and `FIDO2` authentication technologies, offering enterprise-level cryptographic solutions to help clients counter these threats. SecuX's `HSM` products provide secure key storage and management, while its `FIDO2` solution leverages security key technology for passwordless authentication, ensuring Web3 security and operational integrity for digital asset management.

## References
- [Bybit Incident Technical Analysis](https://www.certik.com/resources/blog/3wI26AFKF1UtSDjJEXNEDM-bybit-incident-technical-analysis)
- [How to Prevent the Next $1.5B Bybit Hack: A Strategic Approach to Solving Blind Signing](https://www.blockaid.io/blog/how-to-prevent-the-next-15b-bybit-hack-a-strategic-approach-to-solving-blind-signing)
- [Crypto's biggest hacks and heists after $1.5 billion theft from Bybit](https://www.reuters.com/technology/cybersecurity/cryptos-biggest-hacks-heists-after-15-billion-theft-bybit-2025-02-24/)
- [The Largest Theft in History - Following the Money Trail from the Bybit Hack](https://www.elliptic.co/blog/bybit-hack-largest-in-history)
- [Collaboration in the Wake of Record-Breaking Bybit Theft](https://www.chainalysis.com/blog/bybit-exchange-hack-february-2025-crypto-security-dprk/)
- [Bybit hack - the difference between theft of digital securities versus crypto](https://www.ledgerinsights.com/bybit-hack-the-difference-between-theft-of-digital-securities-versus-crypto/)
- [Bybit Hit by Crypto's Worst Hack With Almost $1.5 Billion Stolen](https://www.bloomberg.com/news/articles/2025-02-21/bybit-says-exchange-wallet-hacked-1-5-billion-estimated-loss)
- [Bybit Hack by the Numbers](https://research.kaiko.com/insights/bybit-hack-by-the-numbers)
- [Hackers steal $1.5 billion from exchange Bybit in biggest-ever crypto heist](https://www.cnbc.com/2025/02/21/hackers-steal-1point5-billion-from-exchange-bybit-biggest-crypto-heist.html)
- [Bybit Hack Traced to Safe Wallet Supply Chain Attack Exploited by North Korean Hackers](https://thehackernews.com/2025/02/bybit-hack-traced-to-safewallet-supply.html)
- [Chainalysis reveals how Bybit hackers stole $1.4 billion in crypto](https://cointelegraph.com/news/chainalysis-bybit-hack-breakdown-1-4-billion)
- [The Bybit Incident: When Research Meets Reality](https://research.checkpoint.com/2025/the-bybit-incident-when-research-meets-reality/)
- [Analysis of the Bybit hack: is the hack method similar to Radiant Capital's hack?](https://abmedia.io/bybit-similar-to-radiant-capital-hack)