Security Research

Trust Wallet Extension Backdoor: v2.68 Malicious Code Injection Analysis

#Supply Chain Attack#APT Analysis#Malware
Over a near-black teal-blue background, a weaponized legitimate analytics pipeline silently exfiltrates sensitive mnemonic data disguised as anomaly event fields; foreground: a dark door sprung open from a version-update package with copper-orange light leaking through the seams; midground: an APT silhouette straddling a multi-stage arrow staircase, a phased timeline, and a smoking trust-chain link; background: a leather wallet with glowing cracks and an anomalous cube hovering over a glass panel; corner: a copper-orange low-poly Trust Wallet shield logo — symbolizing the APT-level targeted supply chain attack that exfiltrated mnemonics via the PostHog channel in the v2.68 backdoor

Background

In the early hours of December 26, 2025 (Beijing time), @zachxbt reported on his channel that some Trust Wallet users found their funds drained. Shortly after, Trust Wallet’s official X account confirmed that version 2.68 of the Trust Wallet Browser Extension had a security issue, urging all users to immediately disable that version and upgrade to 2.69.

ZachXBT disclosure and Trust Wallet official confirmation

Upon receiving the intelligence, the SlowMist Security Team immediately began analyzing the relevant sample.

Code Diff

Let’s start by comparing the core code between the previously released v2.67 and the compromised v2.68:

v2.67 vs v2.68 Code Diff 1

v2.67 vs v2.68 Code Diff 2

Running a diff between the two versions reveals the malicious code the attacker injected:

v2.67 vs v2.68 Code Diff 3

Malicious Code

The backdoored code iterates through every wallet in the extension. For each wallet, it initiates a request to retrieve the encrypted seed phrase. It then decrypts the seed phrase using the password or passkeyPassword that the user entered when unlocking the wallet. If decryption succeeds, the seed phrase is sent directly to the attacker’s server.

Malicious code — exfiltration to attacker domain

Domain Analysis

A quick look at the attacker’s domain registration:

Domain registration lookup

The malicious domain metrics-trustwallet[.]com was registered on December 8, 2025 at 02:28:18, through NICENIC INTERNATIONAL.

The first recorded request to api.metrics-trustwallet[.]com appeared on December 21, 2025:

First recorded request — 2025-12-21

This timeline aligns closely with the code backdoor being inserted around December 22.

Attack Reproduction

We traced the code further to reproduce the full attack chain.

Dynamic analysis shows that after the wallet is unlocked, the attacker populates the seed phrase into an error field visible in the R1 debugger:

Seed phrase packed into error in R1

This error data originates from the GET_SEED_PHRASE function call. Trust Wallet currently supports two unlock methods: password and passkeyPassword. The attacker captures whichever the user provides during unlock, then calls GET_SEED_PHRASE to retrieve the wallet’s seed phrase (and the private key works the same way), packing everything into an errorMessage field.

password and passkeyPassword unlock methods

Here’s the code showing how emit calls GetSeedPhrase to grab the seed phrase and stuff it into the error object:

emit calling GetSeedPhrase

Traffic analysis through BurpSuite confirms that after obtaining the seed phrase, it is wrapped in the errorMessage field of the request body and sent to the attacker’s server at https://api[.]metrics-trustwallet[.]com, consistent with our earlier analysis:

BurpSuite traffic analysis

After this flow completes, the seed phrase and private key have been compromised. The attacker’s familiarity with the extension’s internals is further evidenced by their choice to abuse the PostHog JS analytics SDK — a legitimate open-source platform for full-stack product analytics — as their data exfiltration channel.

My Assessment

This backdoor originated from a malicious source code modification within Trust Wallet’s own extension codebase (specifically targeting the analytics service logic), not from a compromised third-party package (such as a malicious npm dependency). The attacker directly tampered with the application’s own code, hijacking the legitimate PostHog library to redirect analytics data to an attacker-controlled server.

We have strong reason to believe this is a professional APT operation. The attacker may have already compromised a Trust Wallet developer’s device or deployment infrastructure well before December 8.

Remediation

  1. If you have installed the Trust Wallet Browser Extension, disconnect from the network immediately before any investigation or recovery.
  2. Export your private keys / seed phrases right away and uninstall the extension.
  3. Once your keys are backed up, migrate all funds to a different wallet as quickly as possible.