Bybit Exchange was hacked at around 14:00 PM UTC time on February 21, 2025, resulting in losses approaching 1.5 billion – the largest security incident in crypto history to date. Unlike previous security breaches, this theft was not caused by issues with smart contract permissions, but rather by a malicious upgrade of the Safe multisig wallet used by Bybit. The attacker deceived multiple Safe wallet operators into signing a wallet upgrade transaction, thereby successfully taking control of the Safe wallet. Once in control, the attacker drained the funds.
We discovered that this attack was a meticulously planned operation targeting Bybit, with the attacker having deployed and tested the attack contract on-chain two days prior to launching the final assault. In this blog post, we will begin with an introduction to the Safe wallet, analyze the entire attack process, and finally offer some security recommendations.
What is a Safe Multisig Wallet
A Safe Multisig Wallet is a type of smart contract wallet whose core feature is the use of multiple keys to authorize transactions. This wallet requires multiple users (typically pre-designated key holders) to sign a transaction before a transfer or other operation can be executed, thereby enhancing security and preventing a single point of failure or the compromise of a single key.
When the wallet is created, multiple keys are set up (usually using an "n-of-m" model), meaning that among the multiple key holders, a certain number of signatures are required for a transaction to be executed. For example, a "3-of-5" multisig wallet means that out of five key holders, at least three signatures are needed for the transaction to be valid.
Although there are methods to construct transactions without relying on the official Safe website, from a user experience perspective, most users opt to construct and sign transactions via the Safe website. Typically, users visit https://app.safe.global to build transactions. When using a Safe wallet to construct and sign a transaction, users first simulate the transaction to understand its potential outcome once on-chain, and to verify whether it aligns with their expectations. Only if the outcome is as expected will the operator proceed to complete the signing process.
Below is a screenshot of the transaction construction interface in the Safe wallet. Since the Safe website is currently temporarily unavailable, the following screenshot is sourced from the internet (source: https://milkroad.com/reviews/safe-wallet/).
In reality, when using a Safe wallet, the following security risks exist:
-
Long security chain: Users must trust the Safe official website, app, and backend services, as well as their own computer and browser, and finally the wallet used for signing (whether a browser extension or a hardware wallet). If any one of these components is compromised by an attacker, the operator might receive incorrect information (for example, you might be signing an upgrade transaction while the interface displays a normal transfer transaction).
-
Lack of transaction parsing in hardware wallets: Hardware wallets generally lack the ability to parse Safe transactions. This means that if users are misled by the Safe interface, they have no means to cross-verify during the final signing, leading to what is known as "blind signing."
Attack Process
Before launching the final attack, the attacker had already deployed and tested the attack contract on-chain. Multiple different addresses were involved in the entire attack process.
Step 1: Obtaining Funds
The attacker first needed to acquire the initial funds for the attack. Typically, attackers obtain funds through mixing platforms (for example, Tornado Cash) to hide their tracks. However, in this case, the attacker's funds came from Binance. We believe this might be the attacker's method for concealing their identity, as funds and addresses from mixing services are usually closely monitored by security firms, whereas funds from exchanges are less strictly monitored. Additionally, although the funds originated from an exchange, it is possible that the exchange account did not undergo KYC, or that its KYC information was falsified.
Step 2: Deploying and Testing the Contract
Before launching the actual attack, the attacker conducted a series of tests. These tests included deploying a Safe wallet, deploying the attack contract, and using the self-deployed Safe wallet to perform an upgrade operation as well as extract funds from the upgraded Safe wallet. Moreover, during testing, the attacker only experimented with a limited range of assets – assets that matched those in the wallet that was ultimately drained at Bybit. This indicates that the attacker specifically targeted Bybit's Safe wallet.
The attacker created a Safe wallet for testing purposes; one of the test Safe wallet addresses was:
0x509b1eDa8e9FFed34287ccE11f6dE70BFf5fEF55
The attacker tested the upgrade of the Safe contract. We can view the relevant information via the Phalcon Explorer at the following link:
After testing the upgrade, the attacker proceeded to test the withdrawal process. They directly extracted stEth assets from the upgraded Safe contract at address:
0x509b1eda8e9ffed34287cce11f6de70bff5fef55
Step 3: Deceiving Users into Constructing and Signing the Upgrade Transaction
After completing the tests, the attacker needed to deceive users into constructing and signing the Safe contract upgrade transaction. Since the tests were conducted two days earlier, the deception likely occurred within two days following the tests. It is not yet publicly confirmed whether this was achieved by attacking the Safe servers or the wallet operators’ computers.
Step 4: Launching the Attack
Once the attacker obtained a sufficient number of signatures, they submitted the transaction on-chain and successfully executed the contract upgrade. Following the upgrade, the attacker extracted the funds. We found that the malicious upgrade transaction was identical to the previous test transaction.
Lessons and Insights
In fact, similar attacks occurred twice last year – including the thefts from Radiant and the Indian exchange WazirX (with losses exceeding $200 million) – both resulting from malicious transactions signed using Safe wallets. The difference in this incident is that the transaction signed this time was a contract upgrade transaction. Therefore, learning lessons from these security incidents and preventing future attacks remains a challenge that exchanges and project teams holding large amounts of digital assets must address. This can be achieved by improving day-to-day operations, internal process management, security protocols for sensitive operations, and decentralization settings to reduce the risk of being attacked.
Secondly, the issue of how wallets can better participate in the security process during transaction signing remains unresolved. Currently, especially hardware wallets typically lack the ability to parse complex transactions. Moreover, since hardware wallets do not connect directly to the internet, how to perform transaction simulations (and present the results to users in an easily understandable manner) to avoid blind signing remains a challenge.
Additionally, it is necessary to implement multiple security measures, such as employing security monitoring platforms like BlockSec Phalcon to monitor Safe wallets, ensuring that any abnormal behavior is promptly detected and addressed. In fact, Phalcon already has the capability to monitor Safe wallets, and we will continue to upgrade our products so that such monitoring can be automatically configured in the future, helping users avoid risks when using Safe to manage large amounts of assets. Although this incident was caused by the use of a Safe wallet, there is no need to fear "Safe"; it remains the de facto standard for multisig wallets, with its contract security having been proven over time.
Finally, we must emphasize that security defense is never a battlefield for single-point breakthroughs, nor is there a silver bullet that works once and for all. While ensuring operational and business security, industry participants can use BlockSec Phalcon as the last line of defense to protect their assets.
