Event Review
On February 21, 2025 at 02:16:11 PM UTC, Bybits Ethereum cold wallet (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4) was attacked, and approximately 401,346 ETH, 15,000 cmETH, 8,000 mETH, 90,375 stETH and 90 USDT were transferred to unknown addresses, with a total value of approximately US$1.46 billion.
The attacker tricked Bybits multi-signature wallet signers into signing malicious transactions through phishing attacks. The specific steps are as follows:
The attacker deployed a malicious contract in advance, which contained a backdoor function for transferring funds.
Tamper with the Safe front-end interface so that the transaction information seen by the signer on Safe is inconsistent with the data actually sent to the Ledger hardware wallet.
Through the forged interface, the attacker successfully obtained three valid signatures and replaced the implementation contract of the Safe multi-signature wallet with a malicious contract, thereby controlling the cold wallet and transferring funds.
Sygnia was commissioned by Bybit to conduct a forensic investigation to determine the root cause of the attack, with the goal of identifying the scope and source of the attack and mitigating current and future risks. The latest report can be found at: Bybit Interim Investigation Report (https://docsend.com/view/rmdi832mpt8u93s7/d/rwecw3rumhqtgs6a).
To date, the forensic investigation highlights the following findings:
A forensic investigation of all hosts used to initiate and sign transactions revealed that resources in Safes AWS S3 buckets were injected with malicious JavaScript code.
Resource modification times and publicly available network history archives indicate that the injection of malicious code was performed directly in Safe’s AWS S3 bucket.
Initial analysis of the injected JavaScript code showed that its main purpose was to manipulate transactions, effectively changing their contents during the signing process.
Additionally, analysis of the injected JavaScript code revealed an activation condition that is only executed if the transaction origin matches one of two contract addresses: Bybit’s contract address and a currently unidentified contract address (likely related to a test contract controlled by the threat actor).
Two minutes after the malicious transaction was executed and published, new versions of the JavaScript resources were uploaded to Safe’s AWS S3 bucket. These updated versions had the malicious code removed.
Initial findings indicate that the attack originated from Safes AWS infrastructure.
So far, forensic investigations have not found any signs of a compromise of Bybit’s infrastructure.
Forensic investigation of the three signer hosts revealed that the root cause of the attack was malicious code originating from the Safe infrastructure.
No signs of compromise were found in Bybits infrastructure.
Investigations are continuing to further confirm these findings.
From the current information, the front end is not the main problem this time. The main reason for this attack is that the storage service on AWS was hacked and the JavaScript was tampered with, which led to the modification of the transaction content initiated on the Safe front end. However, if the Safe front end had done basic SRI verification, even if the JavaScript was changed, nothing would have happened. In this way, the front end should be responsible to a certain extent. Of course, Bybit must also be responsible. First of all, they confirmed that the hardware wallet they used did not display specific transaction information. Their trust in the Safe front end itself is unreliable.
Hardware wallets have limitations when processing complex transactions and are unable to fully parse and display detailed transaction data of multi-signature wallets, causing signers to blindly sign without fully verifying the transaction content.
Hackers are very good at exploiting the design flaws of the interaction process to defraud users of their assets, such as: using UI hijacking to trick users into signing; using blind signatures to trick users into signing; using Permit signatures to steal users assets; using TransferFrom to trick users into phishing; using short positions with the same last digit to commit scams; phishing for NFTs and other common phishing techniques.
With the rapid development of Web3 technology, the boundary between front-end security and blockchain security is gradually blurring. Traditional front-end vulnerabilities (such as XSS, CSRF) are given new attack dimensions in Web3 scenarios, while smart contract vulnerabilities, private key management flaws and other issues further amplify the risks.
Next, we will analyze the relationship between front-end development and security issues from two scenarios.
Scenario 1: Transaction parameter tampering - the interface shows the transfer, but the authorization is actually executed
Example: Separation of front-end display and on-chain execution
User perspective:
✅ The wallet pop-up window shows Transfer 1 ETH to 0x User...
Actual on-chain effect:
⚠️ Execute approve(attacker, unlimited) to transfer assets at any time
What to do? EIP-712 Structured Signature Verification
1. The front end generates verifiable data
2. Smart contract verification signature
Effect: Any tampering with the front-end parameters will result in signature mismatch and the transaction will be automatically rolled back.
Scenario 2: Blind Signature Hijacking — Why Hardware Wallets Were Hacked
Example: Tampering with Ledger parsing rules
1. The attacker hijacks the front-end code and sends fake calldata to the hardware wallet:
2. Ledger screen display:
Actual execution: approve(attacker, unlimited)
What to do? Hardware wallet semantic analysis + on-chain secondary verification
1. Upgrade hardware wallet firmware to support EIP-712
2. On-chain mandatory semantic matching
Conclusion
The integration of front-end security and Web3 security is both a challenge and an opportunity. The Bybit theft exposed profound problems in the cryptocurrency industry in security management and technical architecture. With the continuous evolution of hacker attack technology, the industry needs to comprehensively improve its protection capabilities from multiple levels such as device security, transaction verification and risk control mechanisms to cope with increasingly complex threats. What front-end developers need to do is to repeatedly verify the links such as accessing DApp, connecting wallets, message signing, transaction signing, and post-transaction processing. Achieve the leap from passive patching to active immunity. Only in this way can we protect the value and trust of every transaction in the open world of Web3.
Of course, security audits of on-chain contracts are also indispensable for every Dapp. ZAN AI Scan (https://zan.top/cn/home/ai-scan?chInfo=ch_WZ) can ensure code correctness through formal verification and AI-assisted security specification generation, provide code similarity and intellectual property risk analysis for millions of deployed contracts, and provide 24/7 monitoring and instant notifications, involving zero-day vulnerabilities and security incidents that may affect your deployed projects. And it has a GPT model optimized based on a huge vulnerability database to detect various real-world vulnerabilities in smart contracts.
This article was written by KenLee from ZAN Team (X account @zan_team ).
