2024年のクリスマスイブ、40万人が利用するChrome拡張機能Cyberhavenが侵害されました。攻撃者は悪意あるアップデートを配信し、Facebook、ChatGPTなど各種プラットフォームの認証情報やセッショントークンを盗み出しました。
2025年のクリスマスイブ、同じ手口が再び繰り返されました。
今回の標的は、Binanceが所有し100万人を超えるChromeユーザーを抱える暗号資産ウォレット「Trust Wallet」でした。攻撃の手口は前年と同じです。誰もが休暇中で、セキュリティチームの人員が手薄になっているタイミングを狙って悪意あるアップデートを配信し、認証情報を収集し、発覚する前に資金を換金するというものです。
結果として、48時間足らずでユーザーのウォレットからおよそ700万ドルが流出しました。
私たちは侵害された拡張機能を解析しました。その結果、これまで公に報じられてきた内容を超える事実が判明し、この攻撃がいかに計算し尽くされたものであったかが明らかになりました。
何が起きたのか
2025年12月24日、Trust Walletのバージョン2.68.0がChromeウェブストアに公開されました。ユーザーがアップデートしてから数時間のうちに、ウォレットからの資金流出が始まりました。オンチェーン調査員のZachXBT氏が12月25日にこのパターンを指摘し、セキュリティ研究者のAkinator氏がその原因を拡張機能のアップデートに突き止めました。
12月26日までにTrust Walletは侵害を確認しました。Binanceの共同創業者であるChangpeng Zhao(CZ)氏は、被害を受けたユーザーへの全額補償を発表しました。
侵害されたバージョンは取り下げられ、修正版であるバージョン2.69が配信されました。ユーザーには資金を新しいウォレットへ移すよう呼びかけられました。
ここまでが公表されている内容です。ここからは、コードの内部で実際に何が起きていたのかを見ていきます。
誤解されていた点
多くの報道は、この攻撃を「シードフレーズを拡張機能にインポートした」ユーザーを標的にしたものと説明していました。しかし、これでは被害の範囲を過小評価してしまいます。
悪意あるコードはロック解除のたびに実行されるものであり、シードフレーズのインポート時だけに限られませんでした。パスワードで認証したか生体認証を使ったかにかかわらず、また何カ月も利用していたか侵害期間中に一度開いただけかにかかわらず、シードフレーズは外部に送信されていました。
バージョン2.68.0がインストールされている間にTrust Walletのロックを解除したことがある人は、自分のウォレットが侵害された可能性があると考えるべきです。
技術的な内訳
この攻撃は、連携して動作する2つのファイルによって実行されていました。
アナリティクスエンドポイントの乗っ取り
ファイル: 4482.js(33129~33130行目)
この拡張機能はアナリティクスにPostHogを利用しています。攻撃者はSDKの初期化処理を改変し、自分たちが管理するサーバーを参照するようにしました。
ドメインapi.metrics-trustwallet.comは、一見するとTrust Walletの正規インフラのように見えます。しかし実際はそうではなく、テレメトリを装って盗んだデータを受け取るために攻撃者が管理しているものです。
データ窃取のロジック
ファイル: 8423.js(467~492行目および520~548行目)
実際の窃取処理は、ウォレットのロック解除フロー内で行われていました。このコードはパスワード認証と生体認証の両方の経路に注入されており、完全な網羅を狙ったものでした。
以下はパスワードによるロック解除の経路です。
この手口を効果的なものにしている要素は3つあります。
複数ウォレットの列挙。このコードは、アクティブなウォレットだけでなく、ユーザーアカウント内のすべてのウォレットを対象にループ処理を行います。複数のウォレットを設定していた場合、そのすべてが侵害されていたことになります。
errorMessageを使った偽装。シードフレーズは、一見すると標準的なロック解除テレメトリのように見えるデータ構造の中で、errorMessageというフィールドに詰め込まれていました。通常のコードレビューでは、これはエラーに関するメタデータを含んだロック解除成功のアナリティクスイベントとして見えます。「エラー」の中身が12単語のニーモニックフレーズであると気づかない限り、怪しい点は何もありません。
両方の認証経路のカバー。パスワードと生体認証、どちらのロック解除フローにも同じ悪意あるコードが埋め込まれていました。逃げ道はありませんでした。
送信されるペイロードの中身
攻撃者のサーバーに送信されるデータ構造は以下のとおりです。
わずか12個の単語。それだけでウォレットの資金を根こそぎ奪うことができるのです。
再パッケージ化の痕跡
データ窃取用のコードに加え、私たちは攻撃者がTrust Walletのビルドパイプラインにコードを注入したのではなく、拡張機能そのものを再パッケージ化したことを示す2つの構造的な変化を発見しました。
消えていたkeyフィールド
バージョン2.67のmanifest.jsonには、拡張機能の公開鍵署名を含むkeyフィールドが存在していました。ところがバージョン2.68では、このフィールドが削除されていました。
keyフィールドは拡張機能の識別情報を固定する役割を持ちます。これを削除すると、異なる暗号鍵の識別情報を使って拡張機能を再パッケージ化できるようになります。つまり攻撃者はTrust Walletの元の署名鍵にアクセスできなかったか、あるいは署名ベースの検知を回避するために意図的にこのフィールドを削除した可能性があります。
いずれにせよ、拡張機能を監視していてバージョン間でkeyフィールドが消えていることに気づいたら、その時点で調査を行うべきです。
新たに追加されたWASM暗号モジュール
バージョン2.68では、バージョン2.67には存在しなかった新しいファイルが追加されていました。
ファイル: 4f8cd8a01d2966c5de9b.module.wasm(1.2MB)
これはsecp256k1楕円曲線暗号ライブラリであり、BitcoinやEthereumがトランザクション署名に使用するのと同じ曲線です。このモジュールがエクスポートする関数には、以下のものが含まれます。
- sign
- signRecoverable
- privateAdd
- pointFromScalar
これらの機能があれば、拡張機能はトランザクションに直接署名し、鍵を導出し、秘密鍵情報を操作することが可能になります。これが実際に使われていたのか、それとも(PostHogによるデータ窃取が失敗した場合の)バックアップ手段として用意されていたのかは不明ですが、いずれにせよ正規版には存在しなかった追加の攻撃対象領域であることに変わりありません。
攻撃者のインフラ
データ窃取先のドメインmetrics-trustwallet.comは、IPアドレス138.124.70.40に紐づいており、UbuntuでNginx/1.24.0を稼働させていました。同じサーバーのポート5000ではSynology DiskStation(DSM 6.2)のログインページが公開されており、攻撃者が自身の所有物か、あるいは侵害したNAS機器をデータ窃取用インフラとして利用していることがうかがえます。
このサーバーに直接問い合わせたところ、以下のような応答が返ってきました。
『デューン 砂の惑星』を思わせる表現です。この文脈における「スパイス」とはシードフレーズを指しており、それを支配する者が資金を支配することになります。
Last-Modifiedヘッダーから、このインフラが12月8日までに準備されていたことが分かります。悪意あるアップデートが配信された12月24日より2週間以上も前のことです。これは決して偶発的なものではなく、計画的に準備されたものでした。
この『デューン』にちなんだ符丁は、直近のShai-Hulud npm事件をはじめとする他のサプライチェーン攻撃で見られたものと通じるものがあります。両者の間に技術的なつながりがあると断定するには至っていませんが、テーマ上の共通点は注目に値します。
タイムライン
- 2025年12月8日:攻撃者のインフラが準備される(metrics-trustwallet.comの設定)
- 2025年12月24日:悪意あるバージョン2.68.0がChromeウェブストアに配信される
- 2025年12月25日:ユーザーがウォレットからの資金流出を報告、ZachXBT氏がこのパターンを指摘
- 2025年12月25日:Akinator氏が原因を拡張機能のアップデートに特定
- 2025年12月26日:Trust Walletが侵害を確認、バージョン2.69をリリース
- 2025年12月26日:CZ氏がSAFUファンドによる全額補償を発表
残された疑問
攻撃者は、どのようにして正規のChromeウェブストアの経路を通じて悪意あるアップデートを配信できたのでしょうか。
考えられる可能性としては、以下のようなものが挙げられます。
- 開発者の認証情報の侵害
- CI/CDパイプラインへの攻撃
- 内部関係者によるアクセス
- チームメンバーを狙ったソーシャルエンジニアリング
Trust Wallet側は現在も調査を継続中であるとしています。この答えは、Trust Wallet自身にとってだけでなく、同じ配信インフラに依存しているすべての拡張機能提供者にとって重要な意味を持ちます。
教訓
セキュリティチート向け:
- バージョンアップデートのクールダウン期間を導入すること。拡張機能のアップデート適用を48~72時間遅らせることで、新バージョンが組織に届く前に、外部の目による検証を経ることができます。今回のケースでは、悪意あるバージョンは24時間以内に発覚しており、クールダウンポリシーがあれば被害そのものを完全に防げていた可能性があります。
- クリスマスイブは、拡張機能のサプライチェーン侵害における既知の攻撃時期となりつつあります。2年連続での発生です。それを踏まえた対策を計画すべきです。
- 拡張機能のバージョン間でのmanifestの変更、特にkeyフィールドの削除を監視すること。
拡張機能の提供者向け:
- ビルド・リリースパイプラインを監査すること。リポジトリからウェブストアへアップデートがどのように届くのかを把握していない場合、そこには死角があります。
- 不正な再パッケージ化を検知できる署名検証の仕組みを導入すること。
ユーザー向け:
- 12月24日から26日の間にTrust WalletのChrome拡張機能のロックを解除したことがある場合は、シードフレーズが漏洩したものと想定し、直ちに資金を新しいウォレットへ移してください。
- ブラウザ拡張機能はリスクの高いソフトウェアです。ウォレット機能は、ブラウザという環境ではなく、専用のアプリケーションやハードウェアに置くべきものです。
おわりに
1年前はCyberhaven、そして今回はTrust Wallet。どちらもクリスマスイブに、どちらもChromeウェブストアの正規のアップデート機能を通じて発生しました。そしてどちらも、24時間以内にコミュニティによって発見されました。とはいえ、実害が出た後のことでした。
このパターンは明らかであり、そこから学ぶべき教訓もまた明らかです。悪意あるアップデートをすべて自分自身で見つけ出す必要はありません。ただ、一番乗りにならなければよいのです。
バージョンアップデートのクールダウン期間は、この種のサプライチェーン攻撃に対する最もシンプルな防御策です。組織が拡張機能のアップデート適用を48~72時間遅らせるようにすれば、より広いセキュリティコミュニティを早期警戒システムとして活用できます。アップデートがユーザーに届く頃には、それはすでに検証済みか、あるいは危険であると指摘されているはずです。
問題は、次のクリスマスイブに再び攻撃が起きるかどうかではありません。その時に備えができているかどうかです。
本稿はKoiのリサーチチームによって執筆されました。
バージョンアップデートのクールダウンをはじめとするポリシーが、拡張機能のサプライチェーン攻撃から組織をどのように守ることができるかについて詳しく知りたい方は、 デモを予約してください。
どうか安全にお過ごしください。
IOC(侵害指標)
- 拡張機能ID: egjidjbpglichdcondbcbdnbeeppgdph
- 侵害されたバージョン: 2.68.0
- 悪意あるドメイン: metrics-trustwallet.com
- データ窃取先IP: 138.124.70.40
- PostHog APIキー: phc_b7MQeJq5OhCBJDKHWLA2c1ubYhbY5L97ZsZ66RGwq6O
- 悪意あるファイル: 4482.js, 8423.js
- WASMモジュール: 4f8cd8a01d2966c5de9b.module.wasm
