Trust Wallet拡張2.68で約700万ドル流出──「正規分析ライブラリを抜け道」にしたサプライチェーン型インシデントです

今日の深掘りポイント

• ブラウザ拡張の自動更新を逆手に取ったサプライチェーン型汚染が、非保管型ウォレットの根幹リスクを顕在化させた事案です。
• 正規の分析ライブラリ（PostHog）をデータ抽出チャネルとして悪用した点が、防御側の可視性・検知を難しくしています。
• 影響ユーザーは最大約100万人規模の母集団に及ぶ可能性がある一方、実被害は約700万ドルにとどまっており、発生条件が限定的だった蓋然性があります（仮説）。
• 攻撃者は中央集権型取引所（CEX）を経由して資金洗浄を進めており、ブロックチェーン監視だけでなく取引所・規制当局との連携が鍵になります。
• 現場は緊急度と実行可能性が高い局面です。拡張の強制アップデート、資産の即時退避、CI/CD・署名・配布パイプラインの見直しを同時並行で進めるべき局面です。

はじめに

Trust WalletのChrome拡張機能バージョン2.68に悪意あるコードが混入し、約700万ドル相当の暗号資産（BTC/ETH/SOL等）が流出しました。影響は拡張ユーザー最大約100万人に波及し得る規模で、Trust Walletは2.69への更新を促し、被害者への返金を約束しています。攻撃者はCEX経由での洗浄を進めており、ウォレット単体の問題にとどまらず、エコシステムの横断的な対応が問われるインシデントです。報道では、正規の分析ライブラリ（PostHog）がデータ流出チャネルに転用されたとされ、サプライチェーン＋正規サービス悪用という複合リスクが露呈しました［出典: The Hacker News］。

参考: The Hacker Newsの報道

深掘り詳細

事実整理（確認できるポイント）

• 対象はTrust WalletのChrome拡張機能 v2.68。該当バージョンに悪意あるコードが導入され、暗号資産の不正流出が発生したと報じられています。
• 被害総額は約700万ドル。銘柄はビットコイン、イーサリアム、ソラナなどに及びます。
• 影響母集団は拡張の利用者約100万人規模。Trust Walletはv2.69への更新を呼びかけ、影響ユーザーへの返金を約束しています。
• 攻撃者は中央集権型取引所（CEX）を経由して資金を洗浄しているとされます。
• 報道では、正規の分析ライブラリ（PostHog）がデータ抽出チャネルとして悪用された点が指摘されています。
  出典: The Hacker News

編集部のインサイト（背景・含意）

• 「自動更新×拡張」という分配チャネルの危うさ
  ブラウザ拡張は自動更新が一般的で、配布側が汚染されるとユーザー側の操作なしに広範な展開が起きます。エンドポイントの制御が十分でも、配布側の信頼崩壊には脆弱で、エンタープライズにおける“リング配信／カナリア運用／配信ゲートの事前検証”が不可欠であることを示します。

• 「正規分析の皮を被ったデータ流出」
  分析SDKやテレメトリは“許容されやすい外向き通信”です。これを外部流出のチャネルとして転用されると、プロキシやDNSフィルタでの検知・遮断が難しくなります。分析イベントに擬態した高感度データ（ウォレット情報）の持ち出しは、従来のDLPやSIG/IOC中心の検知をすり抜ける設計です。

• 被害総額と母集団の非対称性
  影響母集団の規模に比べ被害総額が限定的に見える点は、（仮説）特定操作時のみ機密データが収集された、または攻撃者が段階的に現金化しているといった条件制約を示唆します。すべてのユーザーが即座に致命的な漏えいを受けたわけではない可能性があり、インシデントレスポンスでは「高リスク操作の特定」と「影響範囲の条件切り分け」が重要になります。

• CEXを経由した洗浄とスピード勝負
  匿名型ミキサーだけでなく、KYC済みのCEXへの一時退避が早期段階で観測されるのは、アカウント乗っ取りまたは弱い監視体制を突いた短時間決済が背景にある可能性があります。被害アドレスの共有と早期ブラックリスト化、サードパーティ分析の速報トリアージは、時間との戦いになります。

• メトリクスからの所見
  本件は緊急性が非常に高く、現場で即時に打てる手が多いタイプのインシデントです。一方で新規性は限定的で、既知のサプライチェーン×正規サービス悪用の延長線上にあります。信頼性は高い部類に見え、運用チームは“まず動く”ことを優先し、のちに粒度の高い原因究明へ移行する二段構えが適切です。

脅威シナリオと影響

以下はMITRE ATT&CKに基づく仮説シナリオです（確定情報ではありません）。

• シナリオA：配布アカウント（Chrome Web Store等）乗っ取りによる改ざん配信

  • 想定テクニック
    • Valid Accounts（T1078）：開発者アカウントの不正利用
    • Supply Chain Compromise（T1195.001/002）：クライアント配布物の汚染
    • Masquerading（T1036）：正規更新に偽装
    • Exfiltration Over Web Service（T1567）：分析SaaS経由のデータ持ち出し
  • 影響
    • 自動更新で広範囲に展開、短時間で大量曝露。エンドポイント側の制御を迂回。

• シナリオB：CI/CD・リポジトリの汚染（開発環境の侵害）

  • 想定テクニック
    • Compromise Software Dependencies and Development Tools（T1195.001）
    • Obfuscated/Compressed Files and Information（T1027）
    • Signed Binary Proxy Execution（T1218）相当の“正規署名の悪用”に近い態様
  • 影響
    • ソースと配布物の不整合、再現ビルド不可につながり検証が困難化。復旧にはビルドパイプラインの完全な棚卸しが必要。

• シナリオC：高感度操作時のみの収集・遅延ドレイン

  • 想定テクニック
    • Browser Extensions（T1176）：コレクション／永続化の媒体
    • Input Capture（T1056）またはCredentials from Input/Formsに相当する収集
    • Exfiltration Over Unencrypted/Encrypted Channel（T1041/T1567）
  • 影響
    • 即時の全滅ではなく、特定操作（新規作成・インポート・署名時）で秘密情報を収集し、タイムラグを置いて資産を段階的に流出。検知・相関が難化。

• セカンダリリスク

  • 偽サポートや返金を騙るフィッシング拡散（T1566 Spearphishing）。公式以外のDMに注意。
  • 盗難キーを利用したさらなるdApp悪用や承認乱用。ホットウォレットの連鎖的リスク拡大。

セキュリティ担当者のアクション

• 緊急（0〜24時間）

  • 組織内でTrust Wallet拡張2.68使用可能性がある端末を即時特定。拡張を無効化または2.69へ強制更新。
  • 2.68使用者のウォレット資産を新規生成ウォレット（別デバイス／ハードウェア推奨）へ即時退避。既存シードは再利用しない。
  • 影響が疑われるアドレスの入出金を監視し、取引所・カストディアンに被害申告とブラックリスト化依頼。
  • 社内外コミュニケーション方針を確立（偽サポート対策、公式チャネル周知）。

• 短期（24〜72時間）

  • エンドポイント監視
    • Chrome拡張ディレクトリの改変監査（Windows: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions、macOS: ~/Library/Application Support/Google/Chrome/Default/Extensions、Linux: ~/.config/google-chrome/Default/Extensions）。
    • プロキシ／DNSでの分析系ドメイン（例：ベンダー提供のテレメトリ終端）への異常イベント量・ペイロードサイズ異常を調査（具体ドメインはベンダーのIOC提供を待つことを推奨）。
  • dApp連携の権限棚卸し（EVM系の不要承認の取り消し等）。鍵が漏えいした場合は根本解決にならないが、二次被害を抑制。
  • 財務・法務・IRと連携し、資産影響と対応状況をステークホルダーに説明可能な形で整理。

• 中期（7〜30日）

  • ブラウザ拡張のガバナンス
    • Chrome Enterpriseのポリシー（ExtensionSettings等）で業務端末の拡張を厳格管理。重要ロール端末では原則禁止または限定ホワイトリスト。
    • ベンダーの拡張更新を“カナリアリング＋段階配信＋事前静的解析”でゲート。
  • 供給網対策（自社/ベンダー双方）
    • SLSA等に準拠したCI/CD強化、コミット署名、再現ビルド、Sigstore/cosignによるアテステーション検証を契約要件化。
    • 開発者アカウントの強固な多要素（物理キー/パスキー）、権限最小化、監査ログの定期レビュー。
  • ウォレット運用基準の見直し
    • ホットウォレットのリスク予算化（1ウォレットあたり上限）、資金の階層分離（コールド/ウォーム/ホット）、マルチシグ/ポリシーベース署名の標準化。
    • 重要送金は別経路承認（二経路原則）と時間遅延を設け、ドレイン速度に対抗。

• ロール別示唆

  • CISO
    • ベンダーリスク管理に“クライアント配布物（拡張/モバイルSDK）のサプライチェーン要件”を追加。重大インシデント時のSLA（通知、IOC提供、補償）を契約明文化。
  • SOCマネージャー
    • “正規SaaS経由のデータ外送”検知ユースケースを拡充（イベントレート異常、データサイズ/フィールド異常、時間帯相関）。
    • ブラウザ拡張改変の端点テレメトリ（ファイル作成・更新・署名情報）を収集し、Sigma/KQL化。
  • Threat Intel
    • ベンダー提供の被害アドレス/トランザクションIOCを収集し、チェーン横断の資金フローをトリアージ。取引所・トラベルルール枠組みとの連携を推進。
    • 二次被害（偽返金・サポート詐欺）キャンペーンのドメイン/インフラ監視を強化。

• ユーザー教育

  • 「公式以外のDM/サポート」への対応原則を再周知。返金・補償は公式ドメイン/アプリ内告知のみで案内することを徹底。
  • シードフレーズは一度漏えいしたら永続的に危険、使い回さない——を改めて浸透。

参考情報

• The Hacker News: Trust Wallet Chrome Extension Bug Leads to $7M Crypto Theft; Malicious Code in v2.68, Users Urged to Update to v2.69
  https://thehackernews.com/2025/12/trust-wallet-chrome-extension-bug.html

本稿は報道ベースの事実に基づき、サプライチェーン侵害と正規サービス悪用の複合リスクという観点から仮説を含めて分析したものです。確定した技術的詳細（IOC、具体ドメイン、ビルド/署名手順の破綻点等）は、ベンダーの公式開示に基づき逐次アップデートすることを推奨します。