Back to Blog 
SulfurPT

Web3 SecurityHacksDeFiAudit
Blind Signing: The Bybit $1.5B Lesson in UI Insecurity

9 min
TL;DR: The Interface Lied, $1.5B Vanished
- The Incident: On February 21, 2025, exchange Bybit lost roughly $1.5B in ETH (about 401,000 ETH, the bulk of the exchange's ETH holdings).
- The Vector: Attackers compromised the Safe{Wallet} frontend infrastructure, injecting malicious JavaScript into assets served from AWS S3.
- The Heist: The attacker replaced the JavaScript that constructs transactions. The interface displayed a routine transfer, but the data sent to the hardware wallet handed control of the cold wallet to the attacker.
- The Flaw: Blind Signing. Managers signed the payload the hardware wallet received, but the computer screen showed false data.
- The Lesson: Cold wallet security is useless if the computer preparing the transaction is compromised. Web2 infrastructure (AWS S3) is the weak link.
The Largest Heist in Crypto History
While the world watched market volatility, Bybit suffered the largest theft in cryptocurrency history.
The Numbers:
- Amount Stolen: ~$1.5 billion in ETH (about 401,000 ETH).
- Date: February 21, 2025.
- Attack Duration: Minutes.
- Method: Web2 infrastructure compromise (S3) → UI Injection → Blind Signing.
- Attributed Actors: Lazarus Group (attributed by the FBI under its TraderTraitor designation, and corroborated by independent analysts including Chainalysis).
Unlike hacks that exploit smart contract bugs (like Balancer or Cetus), this attack targeted the human signing process.
The Attack Mechanism: From S3 to Blockchain
The Bybit attack did not exploit vulnerabilities in the Ethereum blockchain. The blockchain worked perfectly. What failed was the chain of trust between the user and the hardware wallet.
1. The Entry Point: Compromised AWS S3
Bybit's signers managed their cold wallet multi-sig through Safe{Wallet} (formerly Gnosis Safe). The wallet's frontend (HTML/JS/CSS files) was served from Safe's AWS infrastructure, including an Amazon S3 bucket.
According to the forensic investigations, attackers first compromised a Safe{Wallet} developer's workstation, obtained credentials with write access to that infrastructure, and replaced the JavaScript served to users with a malicious version. The payload was surgical: it activated only when the connected wallet matched Bybit's Safe address, staying invisible to every other user.
2. Transaction Logic Substitution
When key managers accessed the interface to authorize a routine transaction:
- Malicious Script Loading: The browser loaded the modified JavaScript from the compromised S3 bucket.
- Transaction Construction Interception: The malicious script intercepted the function that builds the transaction payload.
- Double Layer of Deception:
- On Screen (UI): The interface displayed the routine transfer the team expected to sign.
- In Reality (Signed Data): The script constructed a
delegatecallthat swapped the Safe's implementation contract for an attacker-controlled one, handing over control of the entire wallet.
- Blind Signing: The hardware wallet (e.g., Ledger) received the actual malicious transaction data, but the key managers, trusting what they saw on the computer screen, confirmed the operation.
3. The Result
The transaction was signed by authorized managers and sent to the blockchain. Ethereum validated the signatures (which were mathematically correct) and executed it. With the wallet's logic replaced, the attacker drained the cold wallet in follow-up transactions.
Critical Point: The blockchain saw valid signatures. The hardware wallet displayed the actual transaction details or opaque contract interaction data, but the operators trusted the interface they saw on the workstation instead. The computer interface was what lied.
Blind Signing: The Invisible Enemy
Blind Signing occurs when a user signs a message or transaction without being able to independently verify its actual content.
In Web2, we trust the WYSIWYG principle (What You See Is What You Get). In Web3, what you see on screen can be radically different from what you're signing.
Why Is It So Dangerous?
- Data Complexity: A DeFi transaction can involve multiple contracts,
approvefunctions, swaps, and bridges. Manually validating hex is impossible for humans. - Hardware Limitations: Hardware wallets like the Ledger Nano S have tiny screens that often provide limited context for complex smart contract interactions (e.g., they don't say "this is an unlimited approve").
- Confirmation Fatigue: Users become accustomed to clicking "Confirm" without validating each byte, especially during routine operations.
The Bybit Case: Managers saw a routine operation. What they signed was the total drain of the exchange's ETH cold wallet.
Web2 Is the Achilles' Heel
This incident reinforces the thesis of our earlier piece, When Web2 Infrastructure Breaks DeFi.
Bybit implemented best practices for the Cold Wallet:
- ✅ Multi-sig (multiple keys required).
- ✅ Hardware Wallets (Ledger).
- ✅ Offline key storage.
But the Management Infrastructure (Web2) around the signing flow failed:
- ❌ Frontend assets served without integrity verification (SRI).
- ❌ No monitoring for changes in static files.
- ❌ Infrastructure access compromised via a developer workstation.
Hard Conclusion: It doesn't matter if you have the world's safest vault (Blockchain/Cold Wallet) if the computer preparing the transaction (Frontend/S3) is compromised.
Get funded for your audit
Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.
No spam. Unsubscribe anytime.
Checklist: Protecting Management Infrastructure
For teams managing funds or private keys, this checklist is mandatory:
- Integrity Verification (SRI): Use cryptographic hashes (
integrity="sha384-...") for all scripts and stylesheets loaded in the frontend. The browser blocks scripts with invalid hashes. - Bucket Monitoring: Immediate alerts (e.g., AWS CloudTrail + Lambda) for any changes (
PutObject,DeleteObject) in S3 buckets containing production code. - Least Privilege Policy: S3 write access only from specific IPs, with mandatory MFA and short-duration access keys.
- Independent Validation: For high-value transactions, use simulation tools (e.g., Tenderly, Blockaid, Pocket Universe) that show the final state of the transaction before signing.
- Large-Screen Hardware Wallet or Mobile Verification: Prefer devices that allow viewing the complete address and formatted value, or use mobile apps that parse the transaction.
- Differentiated Batch Signing: Never mix "maintenance" transactions with "value" transactions. Use different destination addresses for each context.
- Address Whitelisting: The cold wallet should have speed limits (time-locks) or whitelisted destination addresses for automatic withdrawals.
- Dependency Auditing: Regularly verify the integrity of served
index.htmlandmain.jsfiles, comparing with known hashes.
FAQ
1: Doesn't my Hardware Wallet (Ledger/Trezor) protect me from this?
Partially. The hardware wallet ensures the private key never leaves the secure device. However, it only shows the data the computer sends. If the computer (via malicious UI) sends false data to the hardware wallet, or if the user cannot read the hex on the small screen, the protection fails. The hardware wallet protects the key, but does not validate user intent.2: What is Subresource Integrity (SRI)?
It's a security mechanism that allows browsers to verify whether files loaded from CDNs or external servers (like an S3 bucket) have been altered. The HTML code includes anintegrity attribute with the expected file hash. The browser calculates the hash of the received file and, if it differs from expected, blocks script execution.
3: How can I detect if a website has been compromised?
For end users, it's difficult. Tools like Blockaid, Pocket Universe, Scam Sniffer, or Wallet Guard simulate the transaction in a secure environment and alert if the result is a fund transfer instead of the expected action (e.g., "Mint" or "Swap"). Using these extensions is crucial for detecting UI injections.4: Did Bybit recover the funds?
To date, most funds have not been recovered; a large share was laundered within days. Bybit covered the shortfall with its own treasury and bridge loans from partners, restored 1:1 backing of client assets, and kept withdrawals open throughout. The attack demonstrated that even the most secure exchanges are vulnerable if their management layer (frontend/key management) is compromised.Conclusion
The Bybit case was not a failure in the blockchain, the Ethereum protocol, or key cryptography. It was a failure in the layer of visual and human trust.
While Web3 promises "Don't Trust, Verify," the reality is that no one can manually verify the hexadecimal code of every transaction. We remain hostages of the interface presenting the data.
Protecting Web2 infrastructure (S3, DNS, Domains, CI/CD) is not optional for Web3 projects. It is the first line of defense for user funds. A compromised S3 bucket is all an attacker needs to drain millions, even if keys are in a cold wallet.
Get in touch
At Zealynx, we audit full-stack security, from smart contracts to the Web2 infrastructure supporting them. Because the weakest link isn't the code; it's often the infrastructure around it.
Want to ensure your exchange or protocol isn't the next victim?
Contact us: zealynx.io/quote
For more on vulnerable Web2 infrastructures, read our article on Supply Chain Attacks in Web3.
Glossary
| Term | Definition |
|---|---|
| Blind Signing | Signing a transaction without verifying or fully understanding its actual content, trusting only the visual representation or device trust. |
| UI Injection | Injection of malicious code into the user interface to alter what is displayed or to steal data, often via compromised Web2 servers. |
| Cloud Misconfiguration | Incorrectly secured cloud infrastructure (like S3 buckets hosting dApp frontends) that gives attackers a path to serve malicious code. |
| Cold Wallet | A wallet whose private keys are generated and stored offline, isolated from internet-connected systems. |
| Multi-sig | A wallet requiring multiple signatures (approvals) from different private keys to authorize a transaction, increasing security. |
| Hardware Wallet | A physical device that stores private keys offline and signs transactions without exposing the keys to the host computer. |
| Subresource Integrity (SRI) | A security feature that allows browsers to detect if a loaded file (e.g., script) has been altered by comparing the hash with the expected value. |
| Transaction Simulation | The process of simulating a transaction in a secure environment (blockchain fork) to predict its exact result before signing, preventing blind signing. |
| Address Whitelisting | Restricting a wallet or contract so funds can only move to a pre-approved list of destination addresses. |
| Confirmation Fatigue | Habituation to repetitive approval prompts that leads users to click "Confirm" reflexively without verifying what they are signing. |
Get funded for your audit
Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.
No spam. Unsubscribe anytime.