As Exa, we wanted to share our response to the recent Bybit hack and our proactive strategy for enhancing our treasury management security. While we’re fortunate to have never experienced a security b
2025-03-01 - 6 min read
Security statement and a proactive strategy to maximise DAO Treasury longevity and capital preservation As Exa, we wanted to share our response to the recent Bybit hack and our proactive strategy for enhancing our treasury management security. While we’re fortunate to have never experienced a security breach, it’s crucial we incorporate these lessons into our operations immediately. Executive Summary Investigation Findings: Malicious JavaScript was injected into Safe{Wallet}’s AWS S3 bucket, modifying transaction signing. The injected code targeted transactions involving Bybit’s contract and an unknown test contract. Two minutes after the malicious transaction, Safe{Wallet}’s AWS S3 resources were updated to remove the malicious code. The attack likely originated from Safe{Wallet}’s AWS infrastructure, with no compromise detected on Bybit’s side. Security Enhancements by ExaGroup: Transaction Verification - Mandatory use of OpenZeppelin’s Safe Hash Preview tool to validate transaction hashes before signing. Decentralized UI - Switching to Eternal Safe, a fully local, independent UI fork of Safe{Wallet}, with SHA-256 integrity checks. Hardware Security - Use of dedicated treasury devices, enterprise-grade Hardware Security Modules (HSMs), and hardware wallets for signing. Tenderly Simulations - All transactions must be simulated in Tenderly before execution to detect vulnerabilities and ensure correct execution logic. Automated Policy Reviewer - Implementing a YAML-defined multisig policy reviewer to enforce security rules before signing. Incident Response Plan - A structured response framework with clear roles, forensic partnerships, and recovery procedures. These measures aim to prevent future security breaches and ensure robust protection against sophisticated threats. Understanding What Happened The Bybit incident represents a watershed moment for crypto security. A staggering $1.5 billion was stolen in a single attack - approximately 400,000 ETH, representing 0.42% of all Ethereum in circulation. Let us walk you through how this sophisticated attack unfolded: Developer Machine Compromise : The Lazarus Group first gained access to a Safe{Wallet} developer’s machine. This wasn’t random - this was a deliberate targeting of infrastructure that would give them access to deployment credentials. This allowed access to AWS and their S3 bucket. A malicious JavaScript was pushed to the bucket and eventually distributed. The malicious JS code targeted specifically the Bybit contract address. The JS code changes the content of the transaction during the signing process. Precision UI Manipulation : Unlike broad attacks, the attacker injected malicious JavaScript into the Safe interface that specifically targeted only Bybit’s cold wallet addresses. This selective targeting made the attack virtually invisible to other users of the platform. Multisig Deception : What makes this attack particularly concerning is that all three required Bybit signers approved the transactions. Each was shown what appeared to be legitimate operations in their UI, while the actual on-chain data authorized massive transfers to attacker-controlled wallets. Rapid Fund Dispersal : Within hours, the stolen funds were spread across more than 40 wallets, run through mixers, and partially converted to Bitcoin - demonstrating both planning and operational sophistication. Our Enhanced Treasury Management Framework While we have maintained extremely strong security practices thus far, we are implementing operational improvements to ensure our clients’s safety against the most sophisticated threats: 1. Transaction Verification Through OpenZeppelin’s Safe Hash Preview Tool Use OpenZeppelin’s Safe Hash Preview tool to verify transaction hashes before signing. We’re making this tool a mandatory component of our signing process. It allows us to verify Safe transaction hashes before signing by calculating three critical elements: Domain Hash : Verifies the chain and contract you’re interacting with Message Hash : Confirms the specific transaction details Safe Transaction Hash : The final hash that will be signed The tool works by retrieving transaction details either through manual input or directly from the Safe transaction service API, then computing these hashes using the EIP-712 standard. This provides an independent verification layer that doesn’t rely on the Safe UI. Our new signing protocol is the following: All signers must independently verify transaction details using the OpenZeppelin tool before approval We select either Manual Input or Safe API method depending on the transaction We select our network and add our Safe address Each parameter is confirmed by at least two team members We click “Calculate Hashes” to view the results Critical step : We compare these hashes with what’s displayed on our hardware signing devices All signers must document their verification in our secure operations log Specific verification requirements: We ensure the h