ExaGroup Security Statement Post-Bybit Incident

Analysis

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 hashes match exactly with what’s displayed on our signing devices - even a single character difference is cause for immediate halt We watch vigilantly for multiple transactions with the same nonce. This should only ever happen when we’re intentionally replacing a transaction If we ever see unexpected duplicate nonces, we treat this as a potential attack in progress Any discrepancy triggers our security incident response plan 2.

Decentralized UI Implementation Use Eternal Safe , as a decentralized version of the Safe{Wallet} UI Eternal Safe was funded by the Safe Grants Program as a fork of Safe{Wallet}. It operates independently and requires no backend services and can be run completely locally. We’ve implemented SHA-256 hash verification of all Eternal Safe code before each usage We maintain multiple independent deployments across different environments for redundancy Each deployment is managed by different team members to prevent single points of compromise 3. Hardware Security Protocol Implement a strict separation of concerns for all hardware: Dedicated Treasury Devices : Our treasury operations are conducted only on dedicated devices that are never used for general browsing, email, or development Hardware Security Modules : We’re upgrading to enterprise-grade HSMs for all critical signing operations and requiring hardware wallets for all signers 4.

Mandatory Tenderly Simulations Before Execution Use Tenderly ’s infrastructure to simulate and validate transactions. To further fortify our transaction security, we are enforcing a policy that all transactions must be simulated using Tenderly before execution. Tenderly’s simulation engine allows us to: Detect potential vulnerabilities by simulating contract interactions Ensure correct execution logic , avoiding mistakes Validate transaction behavior under real-world conditions without committing changes to the blockchain Identify unexpected side effects that might not be immediately visible from the transaction details alone Simulation Procedure: Before any transaction is signed, it must first be run through Tenderly’s simulation environment . Each signer must review the simulation results and confirm expected behavior Any unexpected outputs or failed conditions halt the transaction for further investigation.

The final simulation report is logged for transparency and auditability This additional safeguard ensures that even if all prior verification steps pass, no transaction is executed unless its behavior has been rigorously simulated and validated. 5. Automated Policy Reviewer Implement an automated policy reviewer on a multisig, where a YAML blob defines security rules. This automated reviewer will: Read the current policy from the contract. Check if the proposed transaction adheres to that policy. Add its signature to the multisig only if the transaction complies. Example: Default deny policy where all transactions are denied unless they meet the allowed criterias Only USDC transfers to a hot wallet are permitted. A minimum of two signatures is required for execution. All transactions undergo a mandatory 72-hour delay, requiring unanimous approval before execution. 6. Incident Response Plan Develop a detailed incident response plan specifically for treasury security events Clearly defined roles and responsibilities Step-by-step response procedures Communication protocols during security events Relationships established with blockchain forensics firms Recovery and continuity plans Post-incident analysis procedures Our Commitment Moving Forward At Exa, we recognize that the Bybit attack has fundamentally changed what “adequate security” means for on-chain treasuries.

No system is impenetrable, but we believe in creating multiple layers of verification that would require compromising several independent systems simultaneously to be successful. We’re committed to continuous improvement of our security posture and will be regularly sharing updates as we enhance our protocols. The Bybit incident is a sobering reminder that even sophisticated multisig setups can be compromised through UI manipulation and blind signing without proper verification. While we have never experienced a security breach, we believe that proactive adaptation of our security practices in response to emerging threats is essential to maintaining that record. The measures outlined above represent not just incremental improvements, but a fundamental redesign of our treasury management operations built around principles of verification, redundancy, and defense-in-depth. We welcome any questions about our approach and are open to discussing how we can collectively improve security practices across the DAO ecosystem.

For more information on the tools mentioned: OpenZeppelin’s Safe Hash Preview tool: https://safeutils.openzeppelin.com Eternal Safe decentralized UI: https://eternalsafe.eth.limo/welcome/ Tendery’s Simulation tool: https://tenderly.co/ Stay vigilant! About Exa Group Exa Group is a research and consulting boutique firm focused on researching and building best practices to ensure long-lasting and sustainable token economies. Our team combines vast competencies in Web3 Infrastructures, Financial Markets, Social Economics and Project Management. For enquiries send an email to research@exagroup.xyz or follow us on Twitter and LinkedIn .