The Bybit Hack: A Comprehensive Exposé

On February 21, 2025, the cryptocurrency world was shaken by what has been dubbed the largest hack in its 15-year history. Bybit, a Seychelles-based cryptocurrency exchange known for its high trading volumes and robust offerings, suffered a staggering loss of over $1.4 billion in Ethereum (ETH) from its cold wallet. This incident not only dwarfed previous notable cryptocurrency heists—like the Ronin Network’s $624 million breach in 2022—but also exposed critical vulnerabilities in the security practices of even the most reputable exchanges. At the heart of this breach was the exploitation of a multisignature (multisig) wallet system facilitated by Safe.global, a widely trusted wallet provider in the Ethereum ecosystem. This exposé delves into the details of the hack, the pivotal role Safe.global played, and the broader implications for cybersecurity and cryptographic security in the crypto industry.

What Happened: The Bybit Hack Unraveled¶

The breach occurred during a routine transfer of funds from Bybit’s Ethereum cold wallet—a storage mechanism designed to keep assets offline and secure—to a warm wallet, which is typically used for more immediate transactions. According to Bybit CEO Ben Zhou, the hacker manipulated the transaction approval process by compromising the user interface (UI) of the multisig wallet system provided by Safe.global. The attacker crafted a fraudulent UI that mimicked the legitimate Safe interface, deceiving the authorized signers into approving a malicious transaction.

This transaction didn’t merely transfer funds to an unauthorized address; it went further by swapping the Safe wallet’s implementation contract with a backdoored version. The compromised contract, identified on-chain as 0x96221423681a6d52e184d440a8efcebb105c7242, allowed the attacker to gain full control over the wallet. Subsequently, 400,000 ETH—valued at over $1.4 billion—was drained and split across dozens of wallets. Blockchain research platforms like Arkham and on-chain sleuth ZachXBT have since linked the attack to the North Korea-backed Lazarus Group, a notorious cybercrime syndicate with a history of targeting cryptocurrency platforms.

The sophistication of this attack lies not in breaking cryptographic algorithms but in exploiting human trust and procedural weaknesses. Each signer saw a “masked” UI displaying the correct recipient address and transaction details, leading them to approve what they believed was a legitimate transfer. This social engineering tactic, combined with technical manipulation of the wallet’s smart contract logic, underscores a hybrid threat that blends human error with technological vulnerabilities.

The Role of Safe.global: A Double-Edged Sword¶

Safe.global, formerly known as Gnosis Safe, is a leading provider of multisig wallet solutions on Ethereum and other blockchain networks. It secures over $100 billion in digital assets across more than seven million smart accounts, making it a cornerstone of decentralized finance (DeFi) and institutional crypto custody. Its popularity stems from its promise of enhanced security through multisignature authentication, where multiple parties must approve a transaction before it executes, theoretically reducing the risk of single-point failures like stolen private keys.

In Bybit’s case, Safe.global was the backbone of their cold wallet infrastructure. However, the hack revealed that even a trusted tool can become a liability when its implementation or oversight fails. The attacker exploited the transaction approval process by spoofing the Safe UI, a critical layer where human operators interact with the underlying smart contracts. This raises questions about Safe.global’s design and the security practices of its users, particularly large institutions like Bybit.

Exploring Safe.global in Depth¶

Safe.global operates as a smart contract-based wallet system deployed on Ethereum. Its core functionality relies on a modular architecture where the “Safe” contract acts as a proxy, delegating calls to an implementation contract that defines the wallet’s logic. This separation allows for upgrades and flexibility but also introduces potential attack vectors if not properly secured. Key features include:

- Multisignature Authentication: Transactions require approval from a predefined number of signers (e.g., 3-of-5), enhancing security over single-key wallets.¶

Customizable Logic: Users can integrate additional modules or upgrade the implementation contract, tailoring the wallet to specific needs.¶

Transparency: As an open-source project, Safe’s code is publicly auditable, fostering trust in its cryptographic integrity.¶

User Interface: Safe provides a web-based UI for managing transactions, which is where Bybit’s signers were deceived.

The Safe ecosystem is designed with security in mind, leveraging Ethereum’s blockchain for immutability and cryptographic guarantees. Transactions are signed off-chain by authorized parties using their private keys, then submitted to the Safe contract for execution. This process relies heavily on the integrity of the UI and the diligence of signers to verify transaction payloads—both of which proved to be weak links in the Bybit hack.

While Safe.global’s contracts have undergone multiple audits and are considered cryptographically sound, the Bybit incident highlights a disconnect between the smart contract layer and the human-operated front end. The attacker didn’t exploit a flaw in Safe’s code but rather in how it was used, manipulating the transaction review process to bypass the multisig safeguards.

Cybersecurity and Cryptographic Security Analysis¶

The Bybit hack is a case study in the evolving landscape of cybersecurity and cryptographic security within the cryptocurrency industry. Here’s a comprehensive analysis of what went wrong and why:

Social Engineering Over Technical Exploitation
- What Went Wrong: The hack didn’t involve breaking encryption or cracking private keys—a testament to the strength of modern cryptographic standards like ECDSA (Elliptic Curve Digital Signature Algorithm) used in Ethereum. Instead, it relied on tricking human operators into approving a malicious transaction.¶

Why: Humans remain the weakest link in any security system. The fraudulent UI exploited trust in Safe’s branding and the assumption that the displayed information was accurate. This mirrors classic phishing attacks but tailored to the crypto context.
UI/UX Vulnerability
- What Went Wrong: The Safe UI, meant to simplify transaction management, became the attack vector. By presenting a “masked” interface, the hacker obscured the true nature of the transaction payload, which swapped the implementation contract.¶

Why: Safe’s reliance on a user-friendly UI, while beneficial for adoption, introduced a layer of abstraction that signers failed to scrutinize. Unlike raw transaction data, which could reveal anomalies, the UI hid the malicious intent, and Bybit’s team didn’t verify the underlying bytecode.
Multisig Process Flaw
- What Went Wrong: The multisig mechanism, designed to distribute trust, failed when all signers approved the same fraudulent transaction. The backdoored implementation contract gave the attacker unilateral control post-approval.¶

Why: The process lacked a secondary verification step, such as cross-checking the transaction hash or implementation contract address against a known safe state. Institutional users like Bybit may have prioritized efficiency over rigorous validation, a common trade-off in operational workflows.
Smart Contract Upgrade Risks
- What Went Wrong: The ability to upgrade Safe’s implementation contract, a feature meant for flexibility, was weaponized to introduce a backdoor.¶

Why: While upgradeability is a strength of modular systems, it demands strict governance and monitoring. The attacker likely studied Bybit’s transfer patterns—possibly over years, as some evidence suggests—to execute this at the perfect moment, exploiting a lack of real-time contract integrity checks.
Centralized Trust in Third-Party Tools
- What Went Wrong: Bybit’s reliance on Safe.global as a trusted third-party tool shifted some responsibility away from internal security practices.¶

Why: Even audited, open-source solutions like Safe require proper integration and oversight. Bybit’s failure to implement additional safeguards—like air-gapped signing or manual payload review—left them vulnerable to external manipulation.

Broader Implications for Cybersecurity and Cryptographic Security¶

The Bybit hack underscores several critical lessons for the crypto industry:

UI Verification: Multisig wallets must enforce raw data review, not just UI confirmation, especially for high-value transactions. Tools like hardware signers or deterministic transaction simulators could mitigate spoofing risks.¶

Contract Governance: Upgradable smart contracts need real-time monitoring and immutable fallbacks to prevent unauthorized changes. Safe.global could explore integrating alerts for implementation swaps.¶

Regulatory Pressure: With $1.4 billion stolen, regulators will likely push for stricter security standards, auditing requirements, and liability frameworks for wallet providers and exchanges.¶

Cold Wallet Myths: The breach challenges the perception of cold wallets as invulnerable, prompting a shift toward decentralized or hybrid custody models with enhanced oversight.

What Went Wrong and Why: The Root Causes¶

At its core, the Bybit hack resulted from a convergence of human, procedural, and technological failures:

- Human Error: Signers trusted the UI without verifying the raw transaction data, a lapse in diligence fueled by routine operations.¶

Procedural Gaps: Bybit lacked robust checks—e.g., comparing contract addresses or simulating transactions—before approval.¶

Technological Oversight: Safe.global’s design, while secure at the contract level, didn’t account for UI spoofing or enforce signer-side validation, leaving room for exploitation.¶

Timing and Sophistication: The Lazarus Group’s patience and reconnaissance suggest a long-planned attack, exploiting Bybit’s operational predictability.

The “why” ties back to the crypto industry’s rapid growth outpacing security maturity. Exchanges like Bybit, handling billions, face nation-state actors with resources far exceeding typical cybercriminals. The reliance on trusted tools like Safe.global, without tailoring them to institutional needs, amplified the risk.

How UnoLock Could Have Prevented the Bybit Hack¶

The attacker exploited a spoofed Safe UI, deceiving authorized signers into approving a malicious transaction that replaced the wallet’s implementation contract with a backdoored version, handing control to the Lazarus Group. This breach stemmed from human trust in a fraudulent interface, lack of raw data verification, and reliance on a centralized UI. UnoLock’s CybVault Digital Paper Wallet (DPW), available in both the Sovereign and HighRisk tiers, with its Key Extraction Protocol (KEX) feature, could have prevented this attack. While UnoLock supports both hot and cold wallets for key export, Bybit’s high-stakes context would naturally lead to using hardware wallets. Here’s how DPW with KEX could have intervened.

Recap of the Bybit Hack¶

Key details:

- Target: Bybit’s Ethereum cold wallet, managed via Safe.global’s multisig system.¶

Method: A fake Safe UI tricked signers into approving a transaction altering the wallet’s contract logic.¶

Execution: The backdoored contract drained 400,000 ETH.¶

Weaknesses:

- Human error: Signers trusted the UI without verifying raw transaction data.
-

No secondary validation: Payloads weren’t scrutinized. -
Centralized UI: Safe’s interface was a single point of failure.

The Lazarus Group’s social engineering success highlights the need for a trustless, human-proof security solution.

UnoLock’s Preventive Mechanism: DPW with KEX¶

UnoLock’s CybVault DPW, available in both the Sovereign and HighRisk tiers, generates cold-like keypairs offline, requiring export to external wallets—hot (e.g., MetaMask) or cold (e.g., Ledger)—for transactions. KEX, a feature of DPW, enforces offline mnemonic retrieval, splitting the 24-word mnemonic into two halves (12 words each). While both halves can be viewed on one device, UnoLock recommends using two separate devices (e.g., a phone and a laptop) to avoid single-device exposure. For Bybit, managing $1.4 billion, hardware wallets would be the obvious choice for signing transactions after key export. Here’s how DPW with KEX could have stopped the hack.

How DPW with KEX Works:

- Key Generation: DPW generates private/public keypairs offline in the browser using AES-256 GCM encryption, ensuring a secure, uncompromised origin. Keys are encrypted client-side and stored in AWS S3 with dual-layer encryption, but DPW cannot sign transactions—users must export keys to an external wallet.¶

KEX Process: When retrieving the mnemonic, KEX forces the user offline. The mnemonic is split into two halves, each displayed separately. While technically viewable on one device, best practice (as per UnoLock’s recommendation) uses two devices. Users enter each half directly into their chosen wallet (e.g., a hardware wallet like Ledger), avoiding manual recording or digital storage.¶

Flexibility: Both Sovereign and HighRisk offer DPW with KEX, multi-device access (up to 10 access keys), and Spaces. Bybit could use either, and the multi-device capability aligns with institutional needs.¶

Relevance to Bybit:

- Bybit relied on Safe’s UI-driven multisig process, vulnerable to spoofing. DPW with KEX shifts key generation and retrieval offline, isolating keys from online threats. Given Bybit’s risk profile, exporting keys to hardware wallets would be the practical choice over hot wallets, bypassing Safe’s UI entirely for transaction signing.¶

Prevention Potential:

- Offline Key Security: KEX’s mandatory offline mode prevents UI-based attacks. The spoofed Safe UI couldn’t access keys, as signers would retrieve mnemonics offline via DPW.¶

Hardware Signing: Exporting keys to hardware wallets (e.g., Ledger) ensures signing occurs on secure devices, not through a spoofable interface. Signers would review raw transaction data on hardware screens, detecting the malicious contract swap.¶

Split Retrieval: Using two devices for KEX halves (as recommended) complicates spoofing, though even one device offline thwarts the attack by avoiding UI interaction.

How DPW with KEX Addresses the Attack Vectors¶

Attack Vector

Exploited Weakness

UnoLock Countermeasure

Spoofed Safe UI

Signers trusted a fake interface

DPW with KEX forces offline mnemonic retrieval, bypassing UI; keys export to hardware

Multisig Approval Deception

All signers approved via one UI

KEX’s offline split retrieval (ideally two devices) avoids uniform UI deception

Contract Swap Execution

No validation of changes

Hardware wallet signing shows raw data, detecting anomalies

Human Error

No raw data verification

KEX’s offline process enforces diligence; hardware review catches malicious payloads

Centralized UI Dependency

Safe’s UI as a single failure point

DPW’s cold-like keys and hardware export eliminate UI reliance

Hypothetical Scenario: Bybit Using DPW with KEX¶

Bybit adopts UnoLock’s CybVault, leveraging DPW with KEX and hardware wallets:

Key Generation: Signer keys are generated offline via DPW, encrypted with AES-256 GCM, and stored securely in AWS S3.
Key Export: Signers use KEX, going offline. The mnemonic is split into two halves—ideally viewed on two devices (e.g., phone for first 12 words, laptop for second 12)—and entered into hardware wallets (e.g., Ledger).
Transaction Approval: A fund transfer is initiated. Signers use hardware wallets to review and sign the raw transaction data on-screen, not Safe’s UI.
Attack Attempt: Lazarus deploys a spoofed UI:

- Signers bypass the UI, retrieving keys offline via KEX and signing on hardware.¶

The offline process ensures no UI interaction, and hardware screens reveal the malicious contract swap, prompting rejection. 5.
Outcome: The transaction lacks enough signatures (e.g., 3-of-5), preserving the $1.4 billion.

UnoLock’s multi-device access (up to 10 access keys) supports distributed signer verification, though KEX’s offline nature alone suffices.

Why UnoLock Succeeds Where Safe.global Failed¶

Safe.global’s cryptographic design was robust, but its UI was a weak link. UnoLock’s DPW with KEX excels by:

- Offline Isolation: Keys are generated and retrieved offline, immune to UI spoofing.¶

User Choice: Supports hot or cold wallets, with Bybit logically choosing hardware for high-value assets.¶

Human-Proofing: KEX’s split, offline retrieval reduces reliance on signer vigilance.

Safe trusted signers to spot UI fraud; UnoLock eliminates the UI from critical steps.

Broader Implications¶

For exchanges like Bybit, DPW with KEX offers:

- Enhanced Cold Storage: Offline key generation and hardware export redefine security.¶

Operational Flexibility: UnoLock’s multi-device access suits institutional workflows.¶

Threat Mitigation: Offline processes counter social engineering.

The hack could have been a non-issue with UnoLock’s approach.

Limitations¶

- User Responsibility: KEX allows single-device viewing, requiring Bybit to enforce two-device best practice.¶

Setup Effort: Integrating DPW and hardware needs training, though minor for Bybit’s scale.¶

Attack Adaptation: Lazarus might target devices, but offline KEX raises the bar significantly.

These are negligible compared to a $1.4 billion loss.

Conclusion¶

UnoLock’s CybVault DPW with KEX, available in both Sovereign and HighRisk, could have prevented the Bybit hack by forcing offline key retrieval and export to hardware wallets, bypassing the spoofed Safe UI. While UnoLock supports hot wallets, Bybit’s risk profile favors hardware, ensuring trustless, offline signing. Unlike Safe.global, UnoLock removes UI vulnerabilities, providing a robust defense against 2025’s sophisticated threats.