Lessons from the Bybit hack: CoinDCX’s Crypto Security

On February 21, 2025, the Bybit exchange suffered a devastating $1.46 billion exploit, making it the largest hack in Web3 history. The attack targeted Bybit’s cold Ethereum wallet, where an attacker manipulated a contract upgrade to gain full control over the wallet and drain its funds.

According to Bybit CEO Ben Zhou, the attackers used a phishing attack to trick wallet signers into approving a malicious transaction. The exploit was further concealed through a “musked” transaction, where signers saw a legitimate-looking request in the Safe{Wallet} UI, while the actual malicious data was sent to Ledger. This deception allowed the attacker to obtain three valid signatures and replace the Safe’s multi-sig implementation contract with a backdoored version, enabling them to transfer all funds.

What Happened?

Bybit relied on a multi-signature (multi-sig) wallet using Gnosis Safe to secure its Ethereum funds. Multi-sig wallets require multiple authorized signers to approve transactions, making them one of the most secure wallet solutions in the industry. However, this incident revealed a critical flaw in how signers interact with transaction data.

Compromise of the Gnosis Safe UI

• The attackers exploited the Gnosis Safe UI, displaying a legitimate-looking transaction to the signers.
• However, the actual transaction data signed using a Ledger device contained a hidden contract upgrade, which was not visible in the UI.
• This led to a blind signature attack, where signers unknowingly authorized a malicious transaction, giving the attacker control over Bybit’s cold wallet.

Gnosis Safe’s Response

• Safe{Wallet} (Gnosis Safe) denied any direct vulnerability in their official frontend but acknowledged the risks associated with blind signing.
• As a precaution, wallet functionalities were temporarily paused to prevent further potential attacks.

This attack highlights the critical need for better signer awareness, enhanced transaction validation tools, and additional security controls to prevent blind signature exploits.

How Did It Happen?

The attack on Bybit’s cold wallet was executed in two stages:

1. Social Engineering to Access the Gnosis Safe Console
2. Hijacking the Cold Wallet Proxy Contract

Stage 1: Social Engineering Attack

As per Safe{Wallet} internal forensics, the attacker gained access to ByBit’s cold wallet Safe{Wallet} account by compromising the developer machine of Safe{Wallet}. Through this, the attacker submitted a malicious transaction that appeared legitimate to ByBit’s signers.

Attack Flow:

1. Social Engineering Campaign:
   • The attacker used phishing techniques to compromise Safe{wallet} developer’s machine 
   • This gave them unauthorized access to the ByBit’s Gnosis Safe account.
2. Initiating a Transaction:
   • The attacker created a transaction that appeared to be a fund movement from the attacker’s wallet to Bybit’s cold wallet.
   • This did not raise suspicion as it looked like a routine operational transfer.
3. Gaining Approvals:
   • Other legitimate signers saw a normal transaction in the Gnosis Safe UI and approved it.
   • Once the required number of signatures were collected, the transaction was executed.
4. Finalizing:
   • The attacker successfully executed a transaction that appeared legitimate to the signers but was actually an approval for smart contract delegation access. This transaction granted the attacker’s contract control over the Gnosis Safe proxy, setting up the next stage of the exploit.

Stage 2: Hijacking Bybit’s Cold Wallet Proxy Contract

With control over the Gnosis Safe console, the attacker executed a second malicious transaction, which hijacked the cold wallet proxy contract.

I. Preparation Phase – Deploying Malicious Contracts (Feb 18, 2025)

Three days before the attack, the attacker pre-deployed two malicious contracts designed to exploit the proxy architecture:

1. Backdoor Contract (0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516)
   1. Contains hidden functions like sweepETH() and sweepERC20(), allowing unauthorized fund withdrawals.
   2. This contract was later set as the new implementation (masterCopy), giving the attacker full control.
2. Storage Manipulation Contract (0x96221423681A6d52E184D440a8eFCEbB105C7242)
   1. Contained a function to modify storage slots, specifically targeting the first slot (0x00), which stores the masterCopy address in the Gnosis Safe proxy contract.
   2. Allowed the attacker to stealthily swap the implementation contract without using a standard upgrade function.

II. Exploit Execution – Social Engineering and Transaction Manipulation (Feb 21, 2025)

The attacker tricked three authorized signers into approving a malicious transaction, unknowingly initiating a proxy contract upgrade to the attacker’s malicious contract.

• The attack transaction was disguised as a normal fund transfer, misleading the signers.
• However, the “operation” field in the transaction was set to 1 (delegatecall) instead of 0 (call), instructing the Gnosis Safe contract to delegate execution to the attacker’s contract.

III. Proxy Contract Hijacking via Storage Slot Manipulation

Once the delegatecall was executed, the attacker exploited the storage structure of the Gnosis Safe contract:

1. Calling transfer() function on the malicious contract (0x96221423681A6d52E184D440a8eFCEbB105C7242)
   • This function was designed to modify the first storage slot (0x00) of the Gnosis Safe proxy.

1. Overwriting the masterCopy Address
   • In a standard Gnosis Safe proxy, the first storage slot (0x00) holds the masterCopy address, which determines which implementation contract the proxy uses.
   • The attacker’s contract overwrote this slot with the address of the backdoor contract (0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516).
   • As a result, all future transactions called through the proxy now executed the attacker’s code instead of the legitimate Safe implementation.
2. Complete Takeover
   • After modifying the masterCopy reference, the attacker gained full control over the Bybit Wallet Safe Proxy.
   • The malicious implementation contract now had the ability to initiate fund transfers without requiring additional approvals.

IV. Draining the Wallet – Execution of sweepETH() and sweepERC20()

With full control over the proxy, the attacker executed the sweepETH() and sweepERC20() functions from the backdoor contract (0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516), resulting in draining of $1.46 billion worth of ETH from Bybit’s cold wallet.

The above image illustrates – sweepETH() This function is designed to transfer all ETH from the ByBit contract to an attacker-controlled wallet.

The above image illustrates – sweepERC20()This function was used to transfer 401,346.77 mETH / 90,375 stETH From Bybit: Cold Wallet to Exploiter Wallet. They were multiple transactions draining funds from Bybit’s cold wallet
The largest single crypto theft in history, achieved through a stealthy contract upgrade.

The above image illustrates – sweepERC20()This function was used to transfer 401,346.77 mETH / 90,375 stETH From Bybit: Cold Wallet to Exploiter Wallet. They were multiple transactions draining funds from Bybit’s cold wallet

The largest single crypto theft in history, achieved through a stealthy contract upgrade.

Could Greater Awareness Have Prevented This?

The $1.46 billion question remains—could greater awareness around past incidents have helped the industry prevent this attack? Consider these cases:

• WazirX Hack (July 18, 2024): Exploited a similar multisig approval trick, but full technical details were never publicly disclosed.
• Phemex Breach (Jan 25, 2025): Involved contract storage manipulation via delegatecall, but findings remained confined to an internal report.

Had these exchanges openly shared post-mortem analyses with the broader crypto community, the Bybit exploit might have been avoided. Industry-wide awareness could have led to:

• Proactive security upgrades by auditing delegatecall usage in multisig workflows.
• Enhanced transaction security through the implementation of transaction simulation tools.
• Improved signer training to inspect raw calldata before approving transactions.

Greater awareness and open discussions in security incidents isn’t just about learning from past mistakes—it’s about fortifying the entire ecosystem against future threats. The question is: will the industry embrace it before another billion-dollar breach occurs?

26th Feb 2025 Update – 

On February 26, 2025, Safe{Wallet} announced on their official X (Twitter) handle that forensic investigations confirmed a targeted attack on Bybit by Lazarus Group. While Safe smart contracts were unaffected, the attack was conducted by compromising a Safe{Wallet} developer’s machine, which affected a Bybit-operated account.

https://t.co/9zhPMCmGbB

— Safe.eth (@safe) February 26, 2025

Attack Sequence

1. February 19, 2025, 15:29:25 UTC: The JavaScript file app.safe.global was replaced with malicious code targeting Bybit’s Ethereum Multisig Cold Wallet (0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4).
2. February 21, 2025, 14:13:35 UTC: The attack was triggered during Bybit’s next transaction.
3. Forensic review findings suggest that Safe.Global’s AWS S3 or CloudFront account/API Key was likely leaked or compromised, allowing the attackers to inject a malicious JavaScript payload.
4. The attackers injected JavaScript into https://app.safe.global/_next/static/chunks/pages/_app-4f0dcee809cce622.js?ref=content.cside.dev, as confirmed by publicly available web history archives.
5. The attackers modified the executeTransaction() method, setting the operation field to 1 (delegatecall), delegating execution to an attacker’s contract.

Key Takeaways from the Analysis:

1. Compromised Safe App JavaScript:
   • Two JavaScript files were found to be modified:
     • _app-52c9031bfa03da47.js
     • 6514.b556851795a4cbaa.js
   • These files contained malicious code that attempted to manipulate Safe transactions.
2. Timestamp Analysis:
   • The malicious script was modified on February 19, 2025, two days before the attack.
   • The same script was changed again on February 21, 2025, at 14:15 UTC, shortly after the fraudulent transaction at 14:13 UTC, indicating the attacker tried to cover their tracks.
3. Evidence from Wayback Machine:
   • Historical snapshots show that the malicious script was already present in the application on Feb 19, 2025.
   • The script’s checksum changed on Feb 22, 2025, possibly due to removal or modification post-incident.
4. Malicious Code Behavior:
   • The JavaScript payload checked wallet addresses and selectively altered transactions.
   • Attackers targeted specific Safe multisig wallets:
     • Whitelist of compromised wallets:
       • “0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4”
       • “0x19c6876e978d9f128147439ac4cd9ea2582cd141”
     • Blacklist of attacker-controlled wallets:
       • “0x828424517f9f04015db02169f4026d57b2b07229”
       • “0x7c1091cf6f36b0140d5e2faf18c3be29fee42d97”
   • If a transaction matched the attacker’s criteria, it was silently altered to send funds to:
     • Destination Wallet: “0x96221423681a6d52e184d440a8efcebb105c7242”
     • Payload Data: “0xa9059cbb…” (likely an ERC-20 transfer)
     • Safe Transaction Gas: 45746
5. Potential Attack Vector:
   • Safe’s CDN (Amazon S3 and CloudFront) may have been compromised.
   • The attack could have been a compromised deployment pipeline, or an exploited web application vulnerability.

Safe{Wallet} Response & Remediation

• Safe{Wallet} has restored its services on the Ethereum mainnet after rebuilding and reconfiguring infrastructure.
• The forensic review found no vulnerabilities in the Safe smart contracts or source code.
• Safe{Wallet} plans to release a full post-mortem following further investigations.

Key Security Concerns Identified

1. Lack of Clarity on Initial Frontend Compromise: The exact entry point for the JavaScript injection remains unclear, highlighting risks related to frontend, APIs, and other client-side vulnerabilities.
2. Challenges in Client-Side Security:
   • Browser sessions are ephemeral, making log retention difficult.
   • Standard server logs do not always capture file modifications.
   • Weak version control and excessive reliance on third-party code introduce risks.

How CoinDCX Ensures Robust Security

• Access to the custody platform is from a dedicated domain with context-aware access controls ensuring access only from trusted systems & devices.
• Signing transactions happens only through dedicated hardened devices, reducing browser-based risks.
• Multi-factor authentication (MFA) is mandatory for all custody-related operations.
• Transaction risk-based quorum dynamically adjusts based on risk scores from transaction monitoring.
• No smart contracts for asset transfers, reducing exposure to JavaScript-based exploits.
• No browser-based signing policy prevents risks from compromised web-based wallets.

Stay Informed, Stay Safe!