The one-sentence version
In February 2025, approximately 400,000 ETH (about $1.5 billion) was stolen from Bybit's cold wallets, marking the largest single theft in cryptocurrency history. The blockchain, smart contracts, and hardware wallets were not breached; what was breached was the webpage seen by the signers: attackers tampered with the frontend code of the multi-sig wallet service, making signers believe they were performing routine transfers, while they were actually signing "transfer control of the wallet to the attacker." The lesson is: The signing page itself is a security boundary. It must be protected, monitored, and verified just like a server.
This article has three layers:
- Layer 1: The Intuition: How it happened
- Layer 2: Real-World Use: Similar incidents and industry reflections
- Layer 3: Principles and engineering key points
Layer 1: The Intuition
1.1 Incident Progression (Compiled from public investigation reports)
The FBI subsequently attributed this incident to the North Korean hacking group, Lazarus.
1.2 Why so many lines of defense failed to stop it
| Defense | Why it failed |
|---|---|
| Multi-sig (requires multiple signers) | Every signer sees the exact same tampered page |
| Hardware wallet | Only displays a string of hashes or raw data that humans cannot read, leading to "blind signing" |
| Internal exchange processes | Everything displayed on the page appeared "normal," triggering no manual reviews |
In short: Everyone was trusting the same screen, and that screen was lying.
Layer 2: Real-World Use
Similar Incidents
| Incident | Tampered Component |
|---|---|
| Badger DAO (2021) | Attackers obtained Cloudflare API keys and injected scripts into the frontend to induce users to sign authorizations, resulting in a loss of approximately $120 million |
| Ledger Connect Kit (2023) | npm package poisoning, causing widespread automatic frontend loading (see "CSP & SRI") |
| Multiple DNS Hijacking cases | Domain resolution was altered, leading users to a fake frontend |
Industry Reflections
- Frontend hosting must be isolated from developer computers and business servers, with minimized credentials (see "Least Privilege and Key Management");
- Signers must be able to decode and verify transactions independently of the webpage (see "Blind Signing vs. What You See Is What You Sign," out-of-band verification);
- The frontend needs to be continuously monitored just like a server.
Layer 3: Principles and Engineering
3.1 Reproducible Build
The same source code, when built on any machine by any person, should produce a byte-for-byte identical artifact. This allows one to:
- Publish the hash of the artifact;
- Allow anyone to build from source themselves and compare hashes to confirm that the version running online is indeed that specific source code.
Key implementation points: Lock the versions and hashes of all dependencies, fix the build tool version, and strip timestamps and random paths from the artifacts.
3.2 Online Hash Inspection
Periodically fetch the online page and all scripts from an external source, calculate their hashes, and compare them against expected values:
| Key point | Why |
|---|---|
| The inspection program is placed on a machine unrelated to the hosting platform | If the hosting platform is compromised, the inspection program will not be compromised along with it |
| Expected hashes are stored locally on the inspection machine, not trusting the online manifest | When an attacker modifies the page, they will likely modify the online manifest as well |
| Immediate alerts on state changes; regular "heartbeats" during normal operation | The absence of a heartbeat itself indicates the inspection has failed |
| Deployment follows a unified script, updating expected values synchronously during deployment | Prevents legitimate releases from being flagged as attacks |
The limitation of inspection is the window of vulnerability: if a tampering occurs and is used by a user between two inspection cycles, it can only be discovered after the fact. Shortening the interval and combining it with the version monitoring below can minimize this window.
3.3 Deployment Version Monitoring
Many hosting platforms (Cloudflare, Vercel, cloud storage) provide APIs to query "which version is currently live." A monitoring program can query this periodically; if any version appears that is not in our "deployed versions" list, an alert is triggered immediately.
This is faster than comparing page content: a new version can be detected as soon as it is uploaded, without waiting for it to be actually accessed by a user.
3.4 Hosting Platforms can "do harm while trying to help"
CDNs and hosting platforms often feature "auto-optimization" functions: injecting statistics scripts, compressing/rewriting HTML, or obfuscating email addresses on the page. While beneficial for standard websites, for signing pages, this constitutes "unvetted code injection." One should:
- Disable all auto-rewriting functions;
- Add
Cache-Control: no-transformto response headers; - Use inspection to verify that the page has indeed not been modified.
3.5 Automated Damage Control
Inspection can only notify people. If an anomaly is detected when no one is online, users may still sign transactions on the tampered page. A more advanced approach: when a mismatch is detected, automatically take the page offline (it is better to suspend service than to allow continued signing). The credentials to take the page offline should only have the "offline" permission; even if leaked, they cannot be used to modify the page content.
Summary
| Layer | Key points |
|---|---|
| Incident | The chain and contracts were not breached; the page seen by the signers was breached |
| Root Cause | All defenses trusted the same screen; hardware wallets can only perform blind signing |
| Defense | Reproducible builds, external hash inspection, deployment version monitoring, disabling platform rewriting, automated damage control |
| Bottom Line | The signing page is a security boundary and must be treated with the same rigor as a server |