287種のChrome拡張が閲覧履歴を外部送信——3,740万インストール、見えないブローカー網が企業の“行動データ”を吸い上げます

今日の深掘りポイント

• 閲覧履歴は「社内の現在地」をほぼリアルタイムで示す戦略情報です。誰がどのSaaSを触り、どのサプライヤーの見積りページを見て、どの脆弱性ノートに殺到しているか——断片の集合が企業活動の輪郭を描きます。
• 今回の拡張群は、無害を装いながらブラウザAPI経由で収集・送信を行うため、EDRやプロキシの一般的なC2検知をすり抜けやすい構造です。対症療法ではなく「拡張機能の原則禁止＋厳格許可」の設計に寄せることが近道です。
• Manifest V3移行やストア審査は万能ではありません。ホスト権限やhistory権限を得た拡張は、ポリシーに触れない範囲で“正規のWeb通信”として送信できます。技術対策は「権限最小化」「外部送信先の封じ込め」「運用監査」の三点セットで考えるべきです。
• リスクの“即応性”が高い案件です。Chromeの企業ポリシーで拡張のブロックリスト／許可リストを即時適用でき、在庫（インベントリ）を可視化し、ネットワーク側で既知の送信先を遮断するだけでも大きな流出を止血できます。

はじめに

報道によれば、セキュリティ研究者が287種のChrome拡張機能を特定し、合計約3,740万回インストールされていること、そしてこれらがユーザーの閲覧履歴を複数のデータブローカーへ送信していたと指摘しています。送信先は30以上の受信先に及ぶとされ、相当規模の行動データが分散的に集約されていた可能性があります。プライバシーポリシーに明記されないまま、無害に見える拡張が機能の一部として履歴・訪問先URLなどの機微データにアクセスし、外部へ移送していた点が問題の核です。詳細は二次情報ですが、数字と構造が示すものは重い事実です［出典: The Registerの報道］（The Register）。

編集部としては、この案件を「個人のプライバシー侵害」に留まらず「企業の行動データの外部依存化」と捉えます。部門のSaaS移行状況、取引交渉のタイミング、事故対応の兆候が、拡張経由の“合法データ流通”の背後に滲み出るからです。緊急対応の余地が大きく、現場で動かしやすい打ち手が揃っています。

深掘り詳細

事実関係（確認できるファクト）

• 287種のChrome拡張が、合算で約3,740万回インストール。閲覧履歴（訪問URL等）を外部に送信していたと報じられています。送信先は30超の受信先に分散していたとされます［出典: 報道］（The Register）。
• 多くの拡張は「便利機能」をうたいながら、履歴やホスト権限など広いアクセス許可を要求。プライバシーポリシーにデータの扱いが十分明記されていない例が含まれていたとされています［出典: 報道］（同上）。
• Chrome Web Storeの開発者ポリシーはユーザーデータの最小収集と用途の明示、第三者共有の制限などを求めていますが、実装の実態や後段のブローカー網まで完全に担保できるわけではありません（Chrome Web Store Program Policies: User Data）。

上記は公開情報から確認できる範囲の事実です。拡張の具体的なリストや全送信先の詳細は研究者の一次資料がなければ断定できないため、本稿では構造的リスクと対策の深掘りにフォーカスします。

インサイト（編集部の見立て）

• 閲覧履歴は、企業活動の“温度”を映すテレメトリです。たとえば、RFPサイトや競合製品の価格ページ、脆弱性アドバイザリ、VPN・IdPの設定ドキュメントへのアクセスが時系列で観測されれば、意思決定や事故対応のフェーズが外部から推定できます。データブローカーがこの粒度の行動データを集合・再販すれば、競争戦略、投資判断、さらには影響工作のターゲティングに使われうるのが本件の怖さです。
• Manifest V3は権限の見直しやバックグラウンドの制約強化を進めていますが、拡張が正規のAPIとHTTPSで外部に送る限り、「ネットワーク的には良性」に見えます。つまり、検知の主戦場は「拡張が何を許可され、どこに送っているか」を把握・抑制するエンドポイント／ブラウザ管理にあります。
• セキュリティ・メトリクス観点では、影響範囲の広さと現場で打てる対策の具体性の高さが目立つ事案です。すなわち、重大性は高いが、企業側のポリシーレバー（拡張の許可・強制・ブロック、送信先制御、在庫可視化）で短期にリスクを大幅に引き下げられる類型です。迅速な初動と、その後の継続的な棚卸し運用が勝負を分けます。

脅威シナリオと影響

以下は、公開情報を踏まえた仮説シナリオです。MITRE ATT&CKに沿って整理します（技術名はATT&CK参照）。

• シナリオA：拡張を介した“合法テレメトリ”のスパイ化

  • パス: ユーザーが利便性の高い拡張を自発的に導入（User Execution）。拡張がブラウザ権限を取得し、閲覧履歴・訪問URL・リファラ等を収集（Collection）。データブローカーにHTTPSで送信（Exfiltration over Web Service）。
  • ATT&CK対応:
    • Persistence/Defense Evasion: Browser Extensions（T1176）
    • Initial Access/Execution: User Execution（T1204）, JavaScript実行
    • Exfiltration: Exfiltration Over Web Service（T1567）
  • 影響:
    • 競合・投資家・犯罪者が“行動データ”を購入し、商談タイミングやベンダー選定、インシデントの兆候を特定。標的型フィッシングや価格交渉の不利化、買収・提携の裏読みなど、経済的スパイ活動の基盤になりえます。

• シナリオB：影響工作の精緻化

  • パス: ブローカー経由で、特定業界・特定企業所属者の閲覧傾向をセグメント化。SNS広告やフィッシングを極端にパーソナライズして心理的浸透を図る。
  • ATT&CK対応（主に運用面）: Resource Development/Reconnaissanceで得たセグメントを使い、Deliveryでソーシャルエンジニアリングを最適化。
  • 影響: 社内世論や技術選定に影響を与える“ナッジ”の増加、意思決定の攪乱。

• シナリオC：内部資産の間接露出

  • パス: 履歴に含まれる社内FQDNや管理ポータルのパス断片から、攻撃者が攻撃面を構築（Discovery）。後続のパスワードスプレーやフィッシングの踏み台に。
  • ATT&CK対応: Discovery（環境の把握）、Follow-on Exfiltration/Collection。
  • 影響: 攻撃の初動偵察が“購入データ”で省力化され、侵入コストが低下します。

検知・妨害の勘所は、技術的C2検知ではなく「ブラウザ拡張という正規実行環境での権限と送信先の見える化・制御」です。ネットワーク的には良性に見えるため、ポリシーと在庫のマネジメントが主役になります。

参考（ATT&CKテクニックの定義）

• Browser Extensions（T1176）: https://attack.mitre.org/techniques/T1176/
• Exfiltration Over Web Service（T1567）: https://attack.mitre.org/techniques/T1567/

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

即動できる項目から中長期の運用強化まで、優先度順に整理します。

• 24–48時間（止血フェーズ）

  • 会社PCの拡張機能インベントリを即時収集。Chrome管理下であれば拡張の許可／禁止／強制インストールを一元管理するポリシーを適用します。特に以下の2つを軸に「原則禁止・許可制」へ舵を切るのが近道です。
    • ExtensionInstallBlocklist（原則ブロック）
    • ExtensionInstallAllowlist（業務で必要なもののみ許可）
      公式ポリシー仕様: ExtensionInstallBlocklist, ExtensionInstallAllowlist
  • 既知の不審拡張（社内で確認できたもの）を強制アンインストールし、再導入を技術的にブロックします。
  • プロキシ／DNSで、確認済みの送信先ドメイン（研究レポートや自社トラフィック解析で抽出）を暫定ブロック。HTTPSのSNI/JA3や送信先ASの粒度でも封じ込めます。
  • 監査ログを遡及検索し、アクセス先URLの異常（社内で一般的でない価格比較サイト群、匿名化中継など）をサンプリング調査。個人特定を避けつつ、部門別にリスクヒートマップを作ります。

• 1–2週間（安定化フェーズ）

  • 許可リストの策定基準を明文化。必須条件として「最小権限」「プライバシーポリシーの明示」「第三者提供の有無と送信先開示」「過去のインシデント歴の確認」を採用します。
  • ブラウザの権限リクエストを再設定。可能な限り「サイトごとに許可・クリック時許可」の運用を徹底し、history権限等の広範アクセスを原則不許可にします。
  • DLP/Proxyで“URLのみ・クエリ文字列のみ等の一見非機微データ”の外部送出も監査対象に。閲覧履歴はPIIでなくとも企業機微になり得る前提で検知ルールを追加します。
  • セキュリティ広報を実施。なぜ「原則禁止＋許可制」へ変更するのか、利便性とのトレードオフを誠実に説明し、例外申請のSLAを定義します。

• 30–90日（仕組み化フェーズ）

  • 継続的な拡張監査のループを構築。新規導入時の審査、四半期ごとの再評価、権限ドリフトの検出を定常化します。
  • ネットワーク側では、データブローカー・広告計測・テレメトリのカテゴリ別ドメインを戦略的にブロックまたは遅延。業務必要性があるものはピンポイント許可します。
  • 供給網ガバナンスに“ブラウザ拡張”を組み込み、ベンダー利用の拡張（RMM、サポート用など）に対しても契約でデータ送信の透明性を要求します。
  • 監査・法務と連携し、個人情報保護（GDPR/CCPA/APPI）の観点だけでなく「企業行動データ」の域外移転・第三者提供に対する社内基準を定義します。

• 技術的補助線（追加の手当て）

  • Safe Browsingの強化保護や不審サイト警告を企業ポリシーで有効化し、未知の送信先との初回接触を減らします（SafeBrowsing関連ポリシー一覧）。
  • 社内標準ブラウザの統一または“拡張許可ポリシーの同等性”確保。EdgeなどChromium系でも同趣旨のポリシーで運用を揃えます。
  • SOCでの検知観点として、端末から特定ドメイン群への高頻度・低ボリュームHTTP(S) POST、就業時間に依存しない定期バースト、User-Agentがブラウザ標準と微差（拡張注入）などのヒューリスティクスを追加します（仮説ベース）。

最後に——今回の件は、“ブラウザは最も配備の進んだエンドポイントアプリケーション”だという当たり前を、嫌でも思い出させます。検知の前に設計で勝つ。拡張の原則禁止と許可制、送信先の封じ込め、在庫の見える化。この三つの歯車が噛み合えば、同種の流出は確実に減らせます。現場が今すぐ動かせるレバーが用意されているのが、このニュースの数少ない救いです。

参考情報

• The Register: 287 Chrome extensions leaking users’ browser histories to data brokers（2026/02/11報道）: https://go.theregister.com/feed/www.theregister.com/2026/02/11/security_researcher_287_chrome_extensions_data_leak/
• MITRE ATT&CK: Browser Extensions（T1176）: https://attack.mitre.org/techniques/T1176/
• MITRE ATT&CK: Exfiltration Over Web Service（T1567）: https://attack.mitre.org/techniques/T1567/
• Chrome Enterprise ポリシー: ExtensionInstallBlocklist / Allowlist: https://chromeenterprise.google/policies/?policy=ExtensionInstallBlocklist, https://chromeenterprise.google/policies/?policy=ExtensionInstallAllowlist
• Chrome Web Store Program Policies（User Data）: https://developer.chrome.com/docs/webstore/program_policies/#user-data