Trust Wallet Hack: Inside the Code That Stole $7M on Christmas Eve

Back

Trust Wallet Compromised: Inside the Code That Stole $7M on Christmas Eve

Oren Yomtov

Yuval Ronen

December 26, 2025

Christmas Eve 2024, the Cyberhaven Chrome extension, used by 400,000 people, was compromised. Attackers pushed a malicious update that stole user credentials and session tokens from Facebook, ChatGPT, and other platforms.

Christmas Eve 2025, it happened again.

This time the target was Trust Wallet, a crypto wallet owned by Binance with over 1 million Chrome users. The attack followed the same playbook: push a malicious update while everyone's on holiday, harvest credentials while security teams are short-staffed, and cash out before anyone notices.

The result: approximately $7 million drained from user wallets in under 48 hours.

We analyzed the compromised extension. What we found goes beyond what's been publicly reported, and reveals just how calculated this attack was.

What Happened

On December 24, 2025, Trust Wallet version 2.68.0 was published to the Chrome Web Store. Within hours of users updating, wallets started draining. On-chain investigator ZachXBT flagged the pattern on December 25. Security researcher Akinator traced it to the extension update.

By December 26, Trust Wallet confirmed the breach. Binance co-founder Changpeng Zhao (CZ) announced that affected users would be fully reimbursed:

The compromised version was pulled. Version 2.69 was pushed as a fix. Users were advised to migrate funds to fresh wallets.

That's the public story. Here's what actually happened inside the code.

What Everyone Got Wrong

Most reporting described the attack as targeting users who "imported their seed phrases" into the extension. This understates the blast radius.

The malicious code triggers on every unlock - not just seed phrase import. Whether you authenticated with a password or biometrics, whether you'd used the wallet for months or just opened it once during the compromised window, your seed phrases were exfiltrated.

Anyone who unlocked Trust Wallet while version 2.68.0 was installed should assume their wallet is compromised.

The Technical Breakdown

The attack operated through two files working in tandem.

Hijacking the Analytics Endpoint

File: 4482.js (lines 33129-33130)

The extension uses PostHog for analytics. The attacker modified the SDK initialization to point to their own server:

The attacker leveraged PostHog to exfiltrate seed phrases

The domain api.metrics-trustwallet.com looks like legitimate Trust Wallet infrastructure. It isn't. It's attacker-controlled, designed to receive stolen data disguised as telemetry.

The Exfiltration Logic

File: 8423.js (lines 467-492 and 520-548)

The actual theft happens in the wallet unlock flow. The code was injected into both authentication paths - password and biometrics - ensuring complete coverage.

Here's the password unlock path:

The malicious code injected to Trust Wallet

Three things make this effective:

Multi-wallet enumeration. The code loops through every wallet in the user's account, not just the active one. If you had multiple wallets configured, all of them were compromised.

The errorMessage disguise. Seed phrases are stuffed into a field called errorMessage inside what looks like standard unlock telemetry. A casual code review sees an analytics event tracking unlock success with some error metadata. Nothing suspicious - unless you notice the "errors" are 12-word mnemonic phrases.

Dual auth path coverage. Both password and biometrics unlock flows contain the same malicious injection. No escape hatch.

What the Payload Looks Like

Here's the data structure sent to the attacker's server:

Example payload from the malware pretending to be an error message

Twelve words. That's all it takes to drain a wallet.

Signs of Repackaging

Beyond the exfiltration code, we found two structural changes suggesting the attacker repackaged the extension rather than injecting code into Trust Wallet's build pipeline.

The Missing Key Field

The manifest.json in version 2.67 included a key field containing the extension's public key signature. In version 2.68, this field was removed.

The key field pins an extension's identity. Removing it allows the extension to be repackaged with a different cryptographic identity. This suggests the attacker either didn't have access to Trust Wallet's original signing key, or deliberately removed it to avoid signature-based detection.

Either way: if you're monitoring extensions and a key field disappears between versions, investigate.

New WASM Cryptographic Module

Version 2.68 introduced a new file that doesn't exist in 2.67:

File: 4f8cd8a01d2966c5de9b.module.wasm (1.2MB)

This is a secp256k1 elliptic curve cryptography library - the same curve used by Bitcoin and Ethereum for transaction signing. The module exports functions including:

sign
signRecoverable
privateAdd
pointFromScalar

These capabilities would allow the extension to sign transactions directly, derive keys, and manipulate private key material. Whether this was actively used or served as a backup mechanism (in case the PostHog exfiltration failed), it represents additional attack surface that wasn't present in the clean version.

Attacker Infrastructure

The exfiltration domain metrics-trustwallet.com resolved to IP address 138.124.70.40, running nginx/1.24.0 on Ubuntu. The IP is hosted on Stark Industries Solutions (AS44477), a bulletproof hosting provider based in Ukraine that has previously been associated with cybercriminal infrastructure.

Port 5000 on the same server exposes a Synology DiskStation (DSM 6.2) login page - suggesting the attacker is using a NAS device, either their own or compromised, as exfiltration infrastructure.

When queried directly, the server returned:

Dune references are trendy among attackers lately

A Dune reference. In context, the "spice" is seed phrases - control them, control the funds.

The Last-Modified header reveals the infrastructure was staged by December 8 - over two weeks before the malicious update was pushed on December 24. This wasn't opportunistic. It was planned.

The Dune calling card echoes similar references seen in other supply chain attacks, including the recent Shai-Hulud npm incident. We haven't established a technical link between the actors, but the thematic overlap is notable.

Timeline

Dec 8, 2025: Attacker infrastructure staged (metrics-trustwallet.com configured)
Dec 24, 2025: Malicious version 2.68.0 pushed to Chrome Web Store
Dec 25, 2025: Users report wallet drains; ZachXBT flags the pattern
Dec 25, 2025: Akinator traces issue to extension update
Dec 26, 2025: Trust Wallet confirms breach; version 2.69 released
Dec 26, 2025: CZ announces full reimbursement via SAFU fund

The Open Question

How did the attacker push a malicious update through official Chrome Web Store channels?

Possibilities include:

Compromised developer credentials
CI/CD pipeline attack
Insider access
Social engineering of a team member

Trust Wallet has stated they're still investigating. The answer matters - not just for Trust Wallet, but for every extension publisher relying on the same distribution infrastructure.

Takeaways

For security teams:

Implement version update cooldowns. Delaying extension updates by 48-72 hours lets new versions go through public scrutiny before reaching your organization. In this case, the malicious version was flagged within 24 hours - a cooldown policy would have prevented exposure entirely.
Christmas Eve is now a known attack window for extension supply chain compromises. Two years running. Plan accordingly.
Monitor for manifest changes between extension versions, particularly removal of the key field.

For extension publishers:

Audit your build and release pipeline. If you don't know how an update gets from your repo to the Web Store, you have a blind spot.
Implement signing verification that would detect unauthorized repackaging.

For users:

If you unlocked Trust Wallet Chrome extension between December 24-26, assume your seed phrases are compromised. Transfer funds to a fresh wallet immediately.
Browser extensions are high-risk software. Wallet functionality belongs in dedicated applications or hardware, not browser contexts.

Final Thoughts

A year ago, Cyberhaven. Now Trust Wallet. Both on Christmas Eve. Both through the Chrome Web Store's official update mechanism. Both caught by the community within 24 hours - but not before real damage was done.

The pattern is clear, and so is the lesson: you don't need to catch every malicious update yourself. You just need to not be first in line.

Version update cooldowns are the simplest defense against supply chain attacks like this one. If your organization delays extension updates by 48-72 hours, you let the broader security community serve as an early warning system. By the time the update reaches your users, it's either been vetted or flagged.

The question isn't whether another Christmas Eve attack is coming. It's whether you'll be ready for it.

This writeup was authored by the research team at Koi.

If you want to learn more about how version update cooldowns and other policies can protect your organization from extension supply chain attacks, book a demo.

Stay safe out there.