Back to Blog
exploit-teardownevmmultisigsupply-chainnorth-korea

The Bybit $1.5B Hack: How a Safe Multisig Was Drained

|Odin Scan Team
The Bybit $1.5B Hack: How a Safe Multisig Was Drained

On February 21, 2025, $1.5 billion left Bybit's cold wallet. Not because the Safe multisig was broken. Not because the private keys were stolen. Because the signers were shown a fake transaction and they signed it.

The Lazarus Group (North Korea's TraderTraitor unit, per the FBI) executed a supply chain attack against the Safe{Wallet} infrastructure, manipulated the UI that Bybit employees were looking at, and walked away with the largest theft in the history of cryptocurrency.

This is not a story about a smart contract bug. It is a story about what happens when you trust your eyes and the thing showing you information has already been compromised.

What Is a Multisig and Why Was Bybit Using One?

A multisig (multi-signature) wallet requires multiple independent keys to approve any transaction. Bybit used Safe{Wallet}, formerly Gnosis Safe, the industry-standard multisig used by most serious crypto institutions.

The security model is straightforward: if you need three of five keys to sign, an attacker needs to compromise three separate devices, held by three separate people. That is a very high bar. Hardware wallets. Air-gapped devices. Out-of-band verification. The setup Bybit had is the setup that security professionals recommend.

It was not enough.

The Attack, Step by Step

Step 1: Compromise a Safe developer's machine.

Earlier in February 2025, attackers socially engineered a developer at Safe{Wallet}. Exactly how is not fully public, but the result was that the developer's workstation was compromised. From that machine, the attackers stole AWS session tokens: temporary credentials that let you authenticate to AWS without needing the full login flow.

Step 2: Access Safe's AWS infrastructure.

With the stolen session tokens, the attackers bypassed multi-factor authentication and accessed Safe{Wallet}'s AWS account. Inside that account was the JavaScript code serving Safe's web frontend.

Step 3: Swap the JavaScript.

The attackers replaced a specific piece of Safe's frontend JavaScript with a malicious version. The malicious version was designed to activate only when it detected a Bybit-specific address, making it nearly impossible to catch through general monitoring.

Step 4: Wait for a routine transfer.

On February 21, Bybit employees initiated what appeared to be a routine transfer from their cold wallet. They opened Safe's web UI. They saw a transaction that matched what they expected: the right destination address, the right amount, the right contract interaction.

They were not seeing reality. They were seeing what the malicious JavaScript wanted them to see.

The transaction they actually signed was different. It called delegatecall to a malicious contract that upgraded the Safe's implementation to attacker-controlled code.

Step 5: Drain the wallet.

Once the implementation contract was swapped, the attacker had full control over the Safe. All funds, approximately $1.5 billion in ETH, were transferred to attacker-controlled wallets and immediately began the laundering process through mixers and cross-chain bridges.

The FBI attributed the attack to North Korea's Lazarus Group and specifically to the TraderTraitor campaign.

Why the Multisig Did Not Save Them

The multisig worked exactly as designed. Multiple people signed the transaction. The threshold was met. The execution was authorized.

The problem was that none of the signers understood what they were signing. They saw one transaction. They signed a different one.

This is called a blind signing attack or UI spoofing attack. The security guarantees of a multisig assume the signers can accurately evaluate what they are approving. When the interface showing them the transaction has been compromised, that assumption breaks.

Bybit's signers were not careless. They followed their procedures. The procedure assumed the UI was telling the truth. It was not.

The Specific Technical Mechanism

The malicious transaction exploited a Safe-specific upgrade mechanism. A Safe can change its implementation contract (the logic contract it delegates to) through an authorized call to upgradeTo. Once the implementation is changed, all subsequent calls to the Safe go through the new code.

The malicious JavaScript generated a transaction that:

  1. Looked like a normal ETH transfer in the UI
  2. Was actually a call to execTransaction with a payload that invoked delegatecall to a malicious contract
  3. That malicious contract called upgradeTo on the Safe, pointing the implementation at attacker code
  4. The new implementation had no restrictions, allowing the attacker to move all funds

The key detail: delegatecall executes external code in the context of the calling contract. Storage, ETH balance, and address remain the Safe's own, but the logic running against them belongs to whoever wrote the implementation. Once the attacker controlled the implementation, the Safe's entire state was under their control.

What Could Have Prevented It

Transaction simulation with independent verification.

Before signing any transaction, simulate it against a forked mainnet state and display the exact state changes, not the intended action, but what will actually happen on-chain. Bybit's UI showed "transfer X ETH to Y address." An independent simulation would have shown "upgrades implementation to contract 0x[attacker]."

Tools like Tenderly, Alchemy's simulation API, and Fireblocks' Policy Engine do this. None of them can be spoofed by a compromised frontend because they run independently.

Hardware wallet transaction decoding.

Hardware wallets like Ledger and Trezor display raw transaction data. If configured and if the signer actually reads the screen, they can catch discrepancies between what the UI shows and what they are signing. In practice, signers rarely read the raw hex. They rely on the UI to decode it for them, which is exactly the vector that was exploited.

Out-of-band transaction hash verification.

Before signing, each signer independently computes the transaction hash from the raw data and compares it through a separate communication channel (Signal, a phone call). If the hashes match, the transaction has not been tampered with. This process is operationally annoying. It is also what would have caught this attack.

Air-gapped signing devices with their own display.

If the signing device is never connected to the internet and has its own screen that decodes the raw transaction, a compromised web UI cannot affect what the signer sees on the device. The device becomes the source of truth.

What This Means for Smart Contract Security

This attack sits at the intersection of supply chain security, operational security, and smart contract security. The Safe contract itself was not vulnerable. The JavaScript serving the Safe UI was.

This matters for smart contract developers because:

Your deployment scripts are part of your attack surface. If you use a web-based tool to compose or sign deployment transactions, that tool's infrastructure is a trust dependency. A compromised Hardhat plugin, a malicious npm package in your deployment toolchain, or a hacked CI/CD system can inject malicious transactions before you sign them.

Governance proposals deserve the same scrutiny as deployment. Bybit's situation was a routine operational transfer, but the mechanism is identical to governance. An organization voting to execute a malicious governance proposal through a compromised UI is structurally the same attack.

Simulation before signing is non-negotiable. Whatever you are signing, you should know exactly what state changes it will produce before you authorize it. This applies to governance votes, operational transfers, and every deployment action.

The Lazarus Group and Why This Keeps Happening

The FBI's attribution to TraderTraitor/Lazarus Group is consistent with a long track record. Lazarus has been responsible for billions in crypto theft across the Ronin bridge hack ($625M), the Harmony Horizon bridge hack ($100M), and numerous others.

Their methodology is consistent: patience, social engineering, supply chain compromise, and meticulous laundering through mixers and cross-chain bridges. They do not need to break cryptography. They find the humans in the process and compromise them instead.

For any protocol or institution that holds significant funds, this is the threat model. The smart contract might be perfect. The people and tools surrounding it are the attack surface.

What You Can Do Today

If you operate a multisig for a protocol or organization:

  • Enable transaction simulation before every signing action, using an independent tool not connected to the same infrastructure as your signing UI
  • Use hardware wallets that decode and display raw transaction data, and train signers to actually read what the device shows
  • Verify transaction hashes out of band for any transaction above a defined threshold
  • Audit your frontend dependencies the same way you audit your contracts. An npm package that can execute in your signing UI is as dangerous as a bug in your contract

The Bybit hack was not a smart contract vulnerability in the traditional sense. But it demonstrates that operational and supply chain security are part of protocol security. A perfectly audited contract drained through a compromised UI is still a drained contract.

Odin Scan scans smart contract code, deployment scripts, and governance proposal scripts for vulnerabilities. While it cannot protect against UI-level supply chain attacks, it catches the contract-level vulnerabilities that attackers exploit once they have access. Start your free trial.

Sources: FBI PSA, CoinTelegraph, CNBC