Incident Review

On February 21, 2025, at 02:16:11 UTC, Bybit's Ethereum cold wallet (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4) was attacked, resulting in the transfer of approximately 401,346 ETH, 15,000 cmETH, 8,000 mETH, 90,375 stETH, and 90 USDT to an unknown address, totaling roughly $1.46 billion in value.

The attacker used phishing techniques to deceive signers of Bybit's multi-signature wallet into signing malicious transactions. The specific steps were as follows:

• The attacker pre-deployed a malicious contract containing backdoor functionality for fund transfer.
• They tampered with the Safe frontend interface, misleading signers into believing the transaction information on Safe was consistent with the data sent to the Ledger hardware wallet.
• By forging the interface, the attacker successfully obtained three valid signatures, replacing the implementation contract of the Safe multi-signature wallet with a malicious contract, thus gaining control of the cold wallet and transferring the funds.

Sygnia was commissioned by Bybit to conduct a forensic investigation to identify the scope and origin of the attack and mitigate current and future risks. The latest report can be found in the Bybit Interim Investigation Report.

So far, the forensic investigation has highlighted the following findings:

• Forensic examinations of all hosts used to initiate and sign transactions revealed that malicious JavaScript code was injected into resources stored in Safe’s AWS S3 bucket.
• Resource modification timestamps and publicly available network archives indicate that the injection of malicious code occurred directly within Safe's AWS S3 bucket.
• Preliminary analysis of the injected JavaScript code suggests that its primary purpose was to manipulate transactions, effectively altering transaction contents during the signing process.
• Furthermore, preliminary analysis of the injected JavaScript code identified an activation condition that executed only when the transaction source matched one of two contract addresses: Bybit's contract address and an unidentified contract address (potentially related to the threat actor's control).
• Two minutes after the malicious transaction was executed and published, an updated version of the JavaScript resource was uploaded to Safe's AWS S3 bucket, which had removed the malicious code.
• Initial findings indicate that the attack originated from Safe's AWS infrastructure.
• So far, the forensic investigation has found no signs of a breach in Bybit's infrastructure.

Investigations of the three signers' hosts confirm that the root cause of the attack was malicious code originating from Safe's infrastructure.

There are no indications of any breaches in Bybit's infrastructure.

The investigation is ongoing to further confirm these findings.

Based on current information, the frontend is not the main issue in this attack. The primary responsibility lies with the AWS storage service being compromised, allowing JavaScript to be tampered with, which led to the alteration of transaction content initiated from the Safe frontend. However, it can be argued that the frontend bears some responsibility; for example, if the Safe frontend had implemented basic Subresource Integrity (SRI) checks, even if this JavaScript were altered, incidents could have been avoided. Thus, there is a degree of accountability on the frontend's part. Of course, Bybit also holds responsibility; primarily, their hardware wallet did not display specific transaction details, and they confirmed the transaction without fully validating it, indicating that their trust in the Safe frontend was inherently unreliable.

Hardware wallets have limitations when handling complex transactions, as they are unable to completely parse and display detailed transaction data from multi-signature wallets. This leads signers to execute "blind signatures" without fully validating transaction content.

Hackers are adept at exploiting design flaws in interaction processes to deceive users into compromising their assets, such as: UI hijacking to trick users into signing; phishing users via blind signatures; stealing assets through Permit signatures; misleading users into phishing via TransferFrom; executing scams with matching last digits; phishing NFTs and other common phishing techniques.

As Web3 technology rapidly evolves, the boundary between frontend security and blockchain security is becoming increasingly blurred. Traditional frontend vulnerabilities (like XSS, CSRF) gain new attack vectors in Web3 contexts, while smart contract vulnerabilities and private key management flaws amplify overall risks.

Next, we will analyze the relationship between frontend development and security issues through two scenarios.

Scenario One: Transaction Parameter Manipulation — Displaying a Transfer in the UI, but Actually Authorizing Access

Example: Separation of Frontend Display and On-chain Execution

// Frontend displays the transfer of 1 ETH
const showData = contract.interface.encodeFunctionData('transfer', [
  '0xUserAddress',
  ethers.parseEther('1')
]);

// Actually initiates unlimited authorization
const realData = contract.interface.encodeFunctionData('approve', [
  '0xAttackerAddress',
  ethers.MaxUint256
]);

// Sends deceptive transaction
const tx = await signer.sendTransaction({
  to: contract.address,
  data: realData,
  customData: { 
    // Falsifies frontend display data
    security: { displayData: showData } 
  }
});

User Perspective:
✅ Wallet popup shows "Transfer 1 ETH to 0xUser..."
Actual On-chain Effect:
⚠️ Executes approve approve(attacker, unlimited) , allowing assets to be withdrawn anytime.

What to Do? EIP-712 Structured Signature Validation

1. The frontend generates verifiable data.

const domain = {
  name: 'MyDApp',
  chainId: 1,
  verifyingContract: '0xContractAddress'
};

const types = {
  Transaction: [
    { name: 'action', type: 'string' },
    { name: 'to', type: 'address' },
    { name: 'amount', type: 'uint256' }
  ]
};

const value = {
  action: 'Transfer',
  to: '0xUserAddress',
  amount: '1000000'
};

// Generates signature
const sig = await signer.signTypedData(domain, types, value);

2. The smart contract verifies the signature.

function execute(
  string calldata action,
  address to,
  uint256 amount,
  bytes calldata sig
) external {
  bytes32 digest = _hashTypedDataV4(
    keccak256(abi.encode(
      keccak256("Transaction(string action,address to,uint256 amount)"),
      keccak256(bytes(action)),
      to,
      amount
    ));
  require(ECDSA.recover(digest, sig) == msg.sender, "Invalid signature");

  // Executes logic
  if (keccak256(bytes(action)) == keccak256("Transfer")) {
    _transfer(to, amount);
  }
}

Effect: Any frontend parameter manipulation results in a signature mismatch, causing an automatic rollback of the transaction.

Scenario Two: Blind Signature Hijacking — How Hardware Wallets Were Compromised

Example: Tampering with Ledger Parsing Rules

1. The attacker hijacks frontend code to send forged calldata to the hardware wallet:

// Normal calldata for upgrading contract
const realData = '0x095ea7b30000000000000000000...'; // approve(...)

// Tampered display rules for 'upgrade contract'
const fakeDisplay = {
  type: 'contractUpgrade',
  info: 'Updates to v1.2 security patch'
};

// Sent to Ledger
ledger.signTransaction(realData, fakeDisplay);

2. Ledger screen displays:

[Contract Upgrade]
Type: Security Patch  
Version: v1.2 
✅ Confirm Signature  

Actual Execution: approve(attacker, unlimited)

What to Do? Hardware Wallet Semantic Parsing + On-chain Secondary Verification

1. Upgrade hardware wallet firmware to support EIP-712.

// Example of Ledger parsing logic
void parse_calldata(const uint8_t *data) {
  if (is_eip712(data)) {
    display_struct_data(data); // Displays "Transfer 1 ETH to 0x..."
  } else {
    display_hex(data); // Traditional hexadecimal display
  }
}

2. Enforce semantic matching on-chain.

function execute(bytes calldata data) external {
  (string memory action, address to, uint256 amount) = 
    abi.decode(data, (string, address, uint256));
  
  // Must match signature type
  require(
    keccak256(bytes(action)) == keccak256(bytes("Transfer")),
    "Operation type mismatch"
  );
  
  _transfer(to, amount);
}

Conclusion

The integration of frontend security and Web3 security poses both challenges and opportunities. The Bybit theft incident exposed profound issues in the security management and technical architecture of the cryptocurrency industry. As hacking techniques continue to evolve, the industry must enhance its protective measures across various dimensions, including device security, transaction verification, and risk control mechanisms, to cope with increasingly sophisticated threats. Frontend development must diligently verify aspects such as accessing DApps, connecting wallets, message signing, transaction signing, and post-transaction processing. This requires a leap from “passive patching” to “active immunity.” Only in this way can we uphold the value and trust of every transaction in the open world of Web3.

Moreover, on-chain contract security audits remain indispensable for every DApp. ZAN AI Scan can ensure the correctness of the code through formal verification and AI-assisted security norms generation. It offers analysis of code similarity and intellectual property risk for millions of deployed contracts, providing around-the-clock monitoring and instant notifications about zero-day vulnerabilities and security incidents that may affect your deployed projects. It also employs a GPT model optimized using a vast vulnerability database to detect various real-world vulnerabilities in smart contracts.