The $1.5B Bybit Hack Explained: A Technical Breakdown

The recent Bybit $1.5B hack has captured widespread attention across the blockchain security landscape.

While most discussions have emphasized the importance of not blindly signing transactions, few have explored the technical mechanics behind this sophisticated attack.

Here’s how it happened.

Understanding the foundation: Smart contract proxies

Before diving into the attack itself, it's crucial to understand that Bybit's cold wallet used a proxy contract architecture - a common pattern in blockchain development.

In this setup:

• The main contract (proxy) delegates calls to an implementation contract
• The implementation contract's address is stored in a specific storage slot (slot 0)
• This address, known as the masterCopy, determines which code actually executes when the wallet is used

Think of it like a mail forwarding service: the proxy is your permanent address, but it forwards all "mail" (transactions) to wherever you currently live (the implementation contract).

If someone can change your forwarding address without permission, they can redirect your mail wherever they want.

The attack sequence: A step-by-step breakdown

1. The initial transaction

The attack began with what appeared to be a routine transaction: an execTransaction call from Bybit's Safe multisig wallet. However, this transaction contained the seeds of the exploit:

// Simplified representation of the critical storage change
Storage[0] = 0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516 // Malicious contract
// Previously: 0x34cfac646f301356faa8b21e94227e3583fe3f5f // Legitimate GnosisSafe

2. The proxy manipulation

The attackers exploited the proxy architecture by:

• Creating a malicious implementation contract
• Using a specially crafted transaction to update the masterCopy pointer
• Replacing the legitimate GnosisSafe implementation with their malicious version

This change was like replacing the entire security system of a vault while maintaining the same external appearance. It effectively gave the attackers control over all future wallet operations.

3. The spoofing contract

The attackers deployed what we'll call a "Spoofing Contract" at 0x96221423681A6d52E184D440a8eFCEbB105C7242.

This contract included a deceptively simple Transfer function that served one purpose: modifying storage slot 0.

4. The delegatecall exploit

A crucial detail of the attack was the use of delegatecall to set the Operation parameter to 1 in the execTransaction function.

This parameter accepts an enum that dictates whether the transaction is executed as a call or a delegatecall.

Doing this ensured their code would execute in the context of the target contract, allowing them to modify its storage directly.

5. The asset drain

The final stage utilized a "Draining Contract" with two straightforward but devastating functions.

The first function, sweepETH(address receiver), performs two essential actions:

1. It verifies that the caller is a specific, authorized address, failing otherwise.
2. It transfers all ETH held by the contract to the designated receiver.

sweepERC20(address token, address to), operates in a similar manner:

1. It verifies that the caller is a specific, authorized address and fails if not.
2. It transfers all tokens of the specified token type held by the contract to the provided to address.

After performing the proxy switch, the attacker called the sweepETH and sweepERC20 functions alternatively to fully drain the Bybit Cold Wallet.

Key lessons for blockchain security

This incident highlights several critical security considerations:

Smart contract architecture risks

Proxy patterns, while powerful, introduce additional attack vectors. Teams must implement robust access controls and verification mechanisms for implementation updates.

Transaction verification importance

The attack succeeded because a transaction was signed without a full understanding of its implications. Teams handling large assets should:

• Implement multi-layer verification processes
• Use simulation tools to preview transaction outcomes
• Have dedicated security teams review high-value operations
• Add a final check like Blockaid’s Cosigner module that blocks malicious transactions even when devices have been compromised

Storage slot manipulation detection

Onchain security systems (like Blockaid) should be configured to specifically watch for:

• Changes to critical storage slots
• Unusual delegate calls
• Sudden implementation changes in proxy contracts

Building better security practices

As the blockchain ecosystem continues to mature, preventing such attacks requires:

1. Enhanced transaction review processes
2. Better tooling for contract interaction analysis
3. Improved security monitoring systems
4. Regular security audits and penetration testing

Organizations handling significant digital assets must treat security as a core operational requirement, not an afterthought.

This incident serves as a stark reminder that in blockchain technology, a single transaction can have massive implications.

Looking forward

The Bybit hack joins a concerning pattern of similar attacks against major cryptocurrency platforms. As the industry evolves, implementing robust security measures becomes increasingly critical for both established players and emerging projects.

For technical teams, this incident provides valuable insights into the importance of:

• Understanding smart contract architecture patterns
• Implementing comprehensive security monitoring
• Developing thorough transaction review processes
• Maintaining up-to-date security practices

By learning from these incidents and implementing proper security measures, the blockchain industry can work toward building more resilient systems that better protect user assets.

Validate every transaction and never sign blindly again with Blockaid

$2B has been lost to blind signing. Blockaid’s Cosigner provides an automated security check to prevent losses, even when devices have been compromised.

Learn more.