## Unpacking the $1.4 Billion Bybit Hack: A Deep Dive into Multisig Security The cryptocurrency exchange Bybit recently suffered a significant security breach, resulting in losses of approximately $1.4 billion. This incident highlights critical vulnerabilities not in the core smart contracts of widely used wallet solutions, but in the operational security practices surrounding their use. Bybit's CEO, Ben Zhou, explained that the exploit occurred during what was believed to be a "regular cold wallet transfer." Bybit utilizes Safe (formerly Gnosis Safe, accessible via `safe.global`), a popular smart contract wallet solution, for its multisig cold storage. Mr. Zhou, acting as the final of three required signers for their 3-of-6 multisig setup, stated he believed he was authorizing a standard transaction. He reported checking the URL (`safe.global`) and the destination address on the user interface (UI), which appeared correct. However, he crucially admitted he "didn't check fully" the transaction details displayed on his Ledger hardware wallet. This oversight proved catastrophic, as an emergency call about the exploit came just thirty minutes after he signed the transaction. This lesson will dissect the technical mechanisms behind this sophisticated attack. ## The Core Exploit: Manipulating `execTransaction` via `delegatecall` The attackers orchestrated this heist by crafting a malicious `execTransaction` call to Bybit's Safe multisig proxy contract. The Safe architecture relies on a central function, `execTransaction`, to dispatch approved transactions. The key to this exploit lay in the `operation` parameter of the `execTransaction` call. This parameter dictates how the multisig proxy interacts with the target contract. An `operation` type of `0` signifies a standard `CALL` opcode, while an `operation` type of `1` signifies a `DELEGATECALL`. The attackers used `operation: 1`. A `DELEGATECALL` is a powerful and potentially dangerous Ethereum Virtual Machine (EVM) opcode. When a contract (the proxy) `DELEGATECALL`s another contract (the implementation or, in this case, a malicious contract), the called contract's code executes *within the context of the calling contract*. This means that `msg.sender` remains the original caller to the proxy, and, most importantly, any changes to storage (state variables) occur in the *proxy's storage*, not the `DELEGATECALL`ed contract's storage. In this attack, the malicious `execTransaction` forced the Bybit Safe proxy to `DELEGATECALL` a contract deployed and controlled by the hackers. The code within this attacker-controlled contract was designed to overwrite a specific storage slot in the Bybit Safe proxy contract – storage slot `0`. This slot is critical because it stores the address of the *implementation contract* (also known as the mastercopy) that the proxy delegates its logic to. By overwriting storage slot `0`, the attackers replaced the address of the legitimate Safe implementation contract with the address of a new, malicious implementation contract, also under their control. Once this malicious implementation was in place, subsequent transactions initiated by the hackers, such as "Sweep ETH" and "Sweep ERC20" calls, were processed by this compromised logic, allowing them to drain all funds from the Bybit multisig wallet to an "Bybit Exploiter" address. ## Dissecting the Attacker's Payload: A Closer Look at the Malicious `execTransaction` Understanding the parameters of the malicious `execTransaction` call is crucial to grasping the attack. The function signature from `GnosisSafe.sol` (the core Safe contract logic) is as follows: ```solidity function execTransaction( address to, uint256 value, bytes calldata data, Enum.Operation operation, // 0 for call, 1 for delegatecall uint256 safeTxGas, uint256 baseGas, uint256 gasPrice, address gasToken, address payable refundReceiver, bytes calldata signatures ) external payable returns (bool success); ``` The attackers submitted a transaction (hash: `0x46deef0f52e3a983b67abf471444a41dd7ffd6d32da69d62081c68ad7882`) that interacted with Bybit's Cold Wallet 1 multisig proxy (`0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4`). The key parameters *within* this `execTransaction` call were: * **`to` (parameter 0):** `0x96221423681A6d52E184D440a8eFCEbb105C7242`. This was the address of the *first* malicious contract deployed by the attacker, to which the Safe proxy would perform a `delegatecall`. * **`value` (parameter 1):** `0`. No Ether was intended to be transferred by the `execTransaction` itself to this malicious contract. * **`data` (parameter 2):** `0xa9059cbb000000000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025be29695160000000000000000000000000000000000000000000000000000000000000000`. * The first four bytes, `0xa9059cbb`, are the function selector for the standard ERC20 `transfer(address,uint256)` function. This was a deceptive tactic. * The first argument encoded in this `data` was `0xbdd077f651ebe7f7b3ce16fe5f2b025be2969516`. When the malicious contract at `0x9622...` executed via `delegatecall` in the context of the Bybit proxy, it used *this address* to overwrite storage slot `0` of the proxy. This address, `0xbDd077...`, became the address of the *new, malicious implementation contract*. * The second argument was `0`. * **`operation` (parameter 3):** `1`. This explicitly instructed the Safe proxy to use `delegatecall` when interacting with the `to` address (`0x9622...`) using the provided `data`. The use of the `transfer` function selector in the `data` payload was a clever misdirection. While a block explorer's input data decoder might interpret this as a `transfer` call based on the selector, the crucial context is the `delegatecall` operation. The code at the `delegatecall` target (`0x9622...`) was not a standard ERC20 token; it was specifically designed to take the first argument from this "fake transfer" data and use it to modify the proxy's implementation address. ## The Human Factor: How UI Masking and Incomplete Verification Led to Disaster The technical sophistication of the `delegatecall` exploit relied on a critical human vulnerability: the failure of signers to meticulously verify transaction details on their hardware wallets. It's highly probable that the Bybit signers, including the CEO, were victims of a "musked UI" (masked or manipulated User Interface) attack. In such scenarios, malware on a signer's computer alters the information displayed on their screen. The signer might see what appears to be a legitimate transaction on their web browser – for example, a simple ETH transfer to a known, whitelisted address. However, the actual transaction data being packaged and sent to their connected hardware wallet for signing is entirely different: in this case, the malicious `execTransaction` call detailed above. Ben Zhou's admission of "not check[ing] fully" the details on his Ledger hardware wallet's trusted display is the linchpin of the successful exploit. Had the signers carefully examined all parameters presented on their hardware wallet screens, they might have identified several red flags: 1. **The `to` address within the `execTransaction` data:** This would have been the unfamiliar, malicious contract address (`0x9622...`), not a known Bybit address. 2. **The `operation` type:** The hardware wallet, if capable of clearly signing or displaying this detail, would have shown the operation as `1` (for `delegatecall`), a highly privileged and unusual operation for routine transfers. 3. **The `data` payload:** While complex, the presence of an unfamiliar target address (`0xbDd077...`) embedded within this data should have raised alarms. This attack vector, leveraging UI masking to trick users into signing malicious transactions on their hardware wallets, is not novel. It has been observed in previous high-profile incidents, such as the hacks against WazirX and Radiant Capital. Security researchers like ZachXBT have linked such attack patterns to North Korean state-sponsored threat actors. The incident underscores the critical difference between "blind signing" and "clear signing" on hardware wallets. Blind signing occurs when a hardware wallet cannot fully decode or interpret the transaction data, presenting the user with only a hash or raw hexadecimal strings. Clear signing, conversely, involves the hardware wallet parsing the transaction and displaying its meaningful components in a human-readable format (e.g., "You are calling function `execTransaction` on contract `0xBybitProxy...` with `operation: DELEGATECALL` to `0xMaliciousContract...`"). The community, including hardware wallet manufacturers like Keystone, has been advocating for improved clear signing capabilities, especially for complex interactions like Safe multisig executions. ## Understanding Safe's Proxy Architecture: How `delegatecall` Hijacked Bybit's Wallet To fully appreciate the attack, it's essential to understand the proxy pattern used by Safe: * **Safe (Gnosis Safe / safe.global):** A smart contract system enabling features like multisignature asset management. * **Multisig Proxy Contract:** This is the contract that holds the actual assets (e.g., Bybit's Cold Wallet 1: `0x1Db92e...dFCF4`). It has its own storage but delegates most of its logic execution to an implementation contract. Users interact directly with this proxy contract. * **Implementation Contract (Mastercopy):** This contract contains the standard logic for all Safe wallets of a particular version (e.g., functions like `execTransaction`, `addOwner`, `removeOwner`). It is stateless in the context of a single user's Safe; its code is executed by many proxies. The `delegatecall` opcode is fundamental to this EIP-1167 (Minimal Proxy Contract) or similar proxy patterns. When the Bybit proxy contract executed the attacker's `execTransaction` with `operation: 1` (delegatecall) targeting the malicious contract `0x9622...`, the code of `0x9622...` ran *as if it were the proxy's own code*. Crucially, this meant that any storage modifications made by the malicious contract's code affected the *proxy's storage*. As previously mentioned, Safe proxies store the address of their current implementation contract in storage slot `0x0...0` (the very first slot). The malicious code was designed to write a new address – the address of the attacker's *second* malicious contract (`0xbDd077...`) – into this slot. This change can be verified by inspecting the proxy contract's storage before and after the malicious transaction: * **Before the hack transaction (e.g., at block 21895237), storage slot `0` of `0x1Db92e...dFCF4` held:** `0x00000000000000000000000034cfac646f301356faa8b21e94227e3583fe3f5f` (a legitimate Safe L2 V1.3.0 mastercopy address). * **After the hack transaction (e.g., at block 21895239), storage slot `0` of `0x1Db92e...dFCF4` held:** `0x000000000000000000000000bdd077f651ebe7f7b3ce16fe5f2b025be2969516` (the address of the new, malicious implementation contract). Once this implementation address was changed, the Bybit Safe proxy effectively operated under the attacker's complete control. Any subsequent interactions with the proxy would execute the code of this new malicious implementation, enabling the attackers to authorize arbitrary transactions and drain the funds. According to Safe's own investigation, no codebase breach or malicious dependencies were found on their side. The vulnerability exploited was purely operational, hinging on compromised signers and the misuse of the `delegatecall` feature through social engineering. ## Investigative Tools: Verifying On-Chain State Changes Several tools are available for on-chain investigation and verification, which can help in understanding such attacks and confirming state changes. The Foundry toolkit's `cast` command-line utility is invaluable for inspecting contract storage directly. For example, to see the change in the implementation address (mastercopy) for the Bybit proxy, one could use: * To view storage slot 0 *before* the malicious transaction: `cast storage 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4 0 --block 21895237` * To view storage slot 0 *after* the malicious transaction: `cast storage 0x1Db92e2EeBC8E0c075a02BeA49a2935BcD2dFCF4 0 --block 21895239` These commands would clearly show the value stored at slot `0` changing from the legitimate Safe implementation address to the attacker's malicious implementation address. Block explorers like Etherscan.io and Blockscout.com are also essential. Etherscan's input data decoder helps in breaking down the parameters of transactions like `execTransaction`. However, as noted in this attack, sometimes the default decoding (e.g., seeing `transfer` based on a selector) can be misleading without considering the full context, like the `operation` type being `delegatecall`. Blockscout was noted by some analysts to correctly show the *updated* malicious implementation for the Bybit proxy post-hack, while Etherscan (depending on its proxy detection heuristics) might initially still display the ABI of the original, legitimate implementation. This highlights the utility of cross-referencing information across different explorers. ## Critical Lessons for Multisig Users: Preventing Similar Attacks The Bybit hack, despite its sophistication, underscores fundamental security principles that, if adhered to, could have prevented the loss. For all users of Safe multisigs, and indeed any smart contract wallet system, the following lessons are paramount: 1. **Hardware Wallet Verification is Non-Negotiable:** The trusted display of your hardware wallet is your last line of defense. **NEVER** sign a transaction based solely on what your computer screen or web UI shows. UI masking is a prevalent threat. Meticulously verify **ALL** transaction details on the hardware wallet itself before approving. This includes the destination address, value, function being called, and any complex data payloads. As Tayvano, a prominent security researcher, starkly warned, if attackers gain access to your device (e.g., via malware enabling UI masking), you are vulnerable if you don't verify on your hardware wallet. 2. **Understand `execTransaction` Parameters in Safe:** When signing an `execTransaction` for a Safe multisig, pay extremely close attention to: * **The `to` address parameter:** This is the contract your multisig will ultimately interact with. Is it known and trusted? * **The `operation` parameter:** `0` for `call`, `1` for `delegatecall`. A `delegatecall` (`operation: 1`) should be treated with extreme suspicion unless you are an advanced user performing a specific, understood administrative action (like a Safe upgrade initiated by the official Safe team). For most user-initiated transactions, this should be `0`. * **The `data` payload:** Attempt to understand what function and arguments are encoded here. If it's opaque or points to unfamiliar contracts or functions, do not proceed without absolute certainty. 3. **Beware of Blind Signing:** If your hardware wallet indicates it requires "blind signing" for a transaction (meaning it cannot fully decode and display the transaction's intent), you are taking on significant risk. Advocate for and use hardware wallets that offer comprehensive "clear signing" for the types of transactions you frequently perform, especially for complex interactions like those with Safe contracts. 4. **Proficiency in Decoding Raw Data is Essential for Security Teams:** Technical personnel, especially those on security councils, C-level executives involved in signing, or incident response teams, *must* be capable of decoding and understanding raw transaction call data. Relying solely on UIs is insufficient for high-value targets. 5. **Continuous Vigilance:** The threat landscape is constantly evolving. Stay informed about new attack vectors and refresh your security practices regularly. This incident was not a flaw in Safe's audited smart contracts but an exploitation of human trust and operational gaps. By internalizing these lessons and implementing robust operational security measures, users and organizations can significantly mitigate the risk of falling victim to similar devastating attacks. The security of decentralized systems relies not only on strong cryptography and well-audited smart contracts but also, critically, on vigilant and informed human operators.