Bybit Hack Frontend Signature Exploit | Generated by AI
Question: How did Bybit lose more than $1 billion in crypto assets due to a hack? What are the technical details — specifically how the frontend loaded a malicious script and how signatures were manipulated?
Answer:
The Bybit Hack — Full Technical Breakdown (February 21, 2025)
Overview
On February 21, 2025, Bybit experienced a significant security breach resulting in the loss of nearly $1.5 billion worth of Ether (ETH), standing as the largest digital heist in the history of cryptocurrency. The FBI formally attributed the attack to North Korea, referring to this specific malicious cyber activity as “TraderTraitor.”
The Attack Chain — Step by Step
Step 1: Initial Compromise — Developer Machine
Snippets from Mandiant’s preliminary report indicate that a macOS workstation belonging to a Safe{Wallet} developer, referred to as Developer1, was compromised on February 4, 2025.
Once inside, the attackers used stolen AWS credentials to access Safe{Wallet}’s cloud storage (S3 bucket), which hosted the JavaScript for Bybit’s wallet management application.
Step 2: Malicious JavaScript Injection into AWS S3
On February 19, JavaScript resources hosted on the AWS S3 bucket serving Safe{Wallet}’s web interface were modified and injected with malicious code manipulating transactions. The malicious code included an activation condition, set to execute the transaction manipulation only on a specific Bybit cold wallet address.
The modified UI introduced two key changes: (1) Targeted Activation — the malicious code only triggered for Bybit’s multisig signers, identified by their wallet address. Other Safe users saw nothing unusual. (2) The injected payload changed the transaction parameters covertly.
Step 3: The Signing Event — UI Deception
When Bybit’s authorized signers reviewed what appeared to be a routine internal transfer, they were actually approving a request that handed over control of the cold wallet smart contract to the attackers.
The Safe{Wallet} UI displayed a legitimate transaction, while a different payload was sent to the signers’ Ledger hardware devices. The signers approved the transaction as presented in the UI, giving the attacker three valid signatures for the malicious payload.
This is the critical deception: what the screen showed ≠ what the hardware wallet actually signed.
Step 4: The delegatecall Exploit — Smart Contract Takeover
Instead of a normal execTransaction for 30,000 ETH with operation: 0 (a regular call), the injected code substituted a delegatecall payload — operation: 1 — targeting an attacker-controlled contract. One flipped parameter was enough to give attackers complete control to replace Safe’s wallet logic.
Because the proxy uses delegatecall, the attacker’s transfer() function overwrote the value of masterCopy at slot 0, replacing the entire Safe wallet implementation with a malicious implementation address. This gave the attacker full control of the cold wallet.
In plain terms:
operation=0→ normal ETH transfer (safe)operation=1→delegatecall→ rewrites the wallet’s own contract logic to a malicious one → attacker controls everything
Step 5: Funds Drained and Evidence Removed
Approximately two minutes after the malicious transaction was executed, new versions of the compromised JavaScript resources were uploaded to Safe{Wallet}’s AWS S3 bucket, removing the malicious code to cover their tracks.
The attackers moved approximately 401,000 ETH — valued at nearly $1.5 billion — to addresses under their control, then moved them through a complex web of intermediary addresses to obscure the trail.
Why Multi-Sig Failed to Protect Bybit
Bybit’s use of multisig was intended to protect users from a single point of failure, requiring several individuals — including CEO Ben Zhou — to sign off on every transaction. However, the attackers bypassed this by embedding malicious code into the frontend software to make the transaction appear legitimate.
Safe{Wallet} did not implement Subresource Integrity (SRI) hashing to detect modified front-end code, and there was no real-time alerting mechanism in place to flag unauthorized edits to the application. Stronger login security measures such as multi-factor authentication or IP allowlisting were also absent.
When the signers reviewed the transaction, the computers showed a spoofed transaction that tricked them, but their hardware wallets showed the malicious transaction. They could have caught this on the hardware wallet, but calldata can be tricky to verify on a wallet.
Security Failures Summary
| Layer | What Failed |
|---|---|
| Developer machine | Compromised via phishing/social engineering (Feb 4) |
| AWS S3 credentials | Stolen, used to overwrite frontend JS (Feb 19) |
| SRI hashing | Not implemented — no tamper detection |
| Safe UI | Showed fake legit transaction to signers |
| Ledger hardware wallet | Showed real malicious calldata — but signers didn’t verify |
| Multisig (3-of-6) | All 3 required signatures collected — on the malicious tx |
| Smart contract | delegatecall replaced masterCopy, giving full control to attacker |
Aftermath
In less than 72 hours, Bybit pieced together hundreds of thousands of ether tokens through a mix of emergency loans and large deposits, keeping customer withdrawals open. Recovering the stolen assets remains a challenge; in past cryptocurrency thefts by North Korean hackers, the threat actors almost immediately transferred stolen funds into Bitcoin, which is harder to trace than ETH due to Bitcoin’s UTXO transaction model.
References:
- Chainalysis — Bybit Hack & DPRK Analysis
- Sygnia — Investigation into the Bybit Hack
- NCC Group — In-Depth Technical Analysis
- BlockSec — Web2 Breach Enables Largest Crypto Hack
- Dfns — The Bybit/Safe Hack
- Cyfrin — Safe Wallet Hack / Bybit Exploit
- BleepingComputer — Lazarus Hacked Bybit via Safe Developer Machine
- FBI IC3 — PSA on North Korea Bybit Hack
- CSIS — The ByBit Heist