サイバー脅威
ブラウザに潜む危険：拡張機能の悪用事例とリスクから対策を考える
ブラウザの利便性を格段に高めるブラウザ拡張機能。その一方でサイバー攻撃に悪用されるなどリスク要因にもなり得ます。セキュリティを確保しつつ、利便性も享受するにはどうすべきでしょうか？
はじめに
Webブラウザ拡張機能（以下、ブラウザ拡張機能）は利便性が高く、クラウドサービスや生成AIとあわせて広く利用されている一方で、組織としてのセキュリティ対策が困難であるという側面があります。
一般的な組織におけるブラウザ拡張機能への対応は、「全面禁止(拒否)」または「利用者判断」のいずれかに二分されているように見受けられます。本記事では、ブラウザ拡張機能の構成とリスクについて整理したうえで、この二分化に対する第三の道として、利便性とセキュリティ対策の共生を実現する運用モデルを検討しました。
ブラウザ拡張機能によるセキュリティリスクが顕在化した事例
直近5年間（2020年～2025年）でChromiumベースのブラウザ拡張機能においてセキュリティリスクが顕在化した事例を取り上げます。攻撃者に悪用された事例と、正規の開発元により提供されたもののうちセキュリティリスクが指摘された事例について記載します。
2020年〜2025年：Chromium 拡張機能の悪用による大規模スパイ活動
2020年に発覚したChrome ウェブストア上の大規模スパイ活動型拡張機能キャンペーンでは、Cisco Duo SecurityおよびAwake Securityの調査によれば、500件以上の悪質な拡張機能が累計3,000万回以上ダウンロードされていたことが確認されました。被害規模としてはGoogle Chrome（以下、Chrome）の拡張機能を悪用された事例において史上最大級でした。対象の拡張機能は広告ブロッカーやPDF変換ツールを装い、ユーザの閲覧履歴や認証情報を外部へ送信していたことが確認されています。
対象の拡張機能は正規のChrome ウェブストア 審査を通過しており、通常の機能を備える一方で、攻撃者はバックグラウンドスクリプト（当時主流であったManifest V2の仕様）内にデータ収集コードを潜ませ、C&C（C2）サーバと通信を行っていました。企業ネットワーク環境では通信を抑制するなど、検知回避機能も備わっていました。また、拡張機能の開発者情報や登録ドメインは偽装されており、背後に1.5万以上の関連ドメインが登録されていたことから、高度に組織化されたオペレーションであることが示唆されています。
2021年〜2024年：「Earth Kumiho（別名：Kimsuky）」によるスパイ活動での拡張機能悪用（SHARPEXT・TRANSLATEXT）
2021年以降、北朝鮮背景とされる標的型攻撃グループ（APTグループ）である「Earth Kumiho（別名：Kimsuky）」によるスパイ活動の一環として、GmailなどのWebメールを標的とした悪意あるChromeおよびMicrosoft Edge（以下、Edge）の拡張機能が確認されました（参考：Volexity社のブログ）。この攻撃は「SHARPEXT」と呼ばれる特徴的な拡張機能を用いて外交官・研究者・政策専門家など、北朝鮮に関する情報を扱う個人を主な標的としていました。
また、2024年3月にあるリサーチャーの調査により判明したEarth Kumihoによる攻撃では、Powershellを用いてChromeのブラウザ拡張機能に関するレジストリを操作し、悪意のある拡張機能「TRANSLATEXT」を強制的に端末へインストールした事例が確認されています。Powershell経由でレジストリに登録することで、ユーザが認知しない状態でブラウザ拡張機能を追加することが可能です。公開情報から確認したmanifest.jsonには過剰な権限の記載や、アップデート元としてGitHubを指定していることを確認しました。
対象のレジストリ：HKCU\Software\Policies\Google\Chrome\ExtensionInstallForcelist
これらの事例から、国家レベルの諜報活動においてもブラウザ拡張機能が悪用されているといえます。
＜参考記事＞
2024年～2025年：RedDirection（大規模なブラウザ拡張機能ハイジャック／追跡キャンペーン）
2025年7月にKoi Security社が公開した調査内容では、ChromeおよびEdgeにおいて、合計18個の悪意のあるブラウザ拡張機能を観測したことが明らかになりました。本オペレーションは「RedDirection」と呼称され、被害者ユーザの数は2025年7月時点で少なくとも230万ユーザに上ると報告されています。該当の拡張機能は一見正規に見受けられ、公式ストアから「定評のあるパブリッシャー」「おすすめ」バッジや高評価レビューを多数獲得していたものも含まれていました（参考：Koi Security社のブログ）。
これらの拡張機能は、長期間正常に機能したのちに更新を通じて悪性コードを含むようになった「スリーパー型（後入れ型）の悪性拡張機能」と推定されています。悪性化後は、ユーザの閲覧URLや識別子を外部サーバへ送信し、指令に基づいて任意サイトへのリダイレクトやフィッシングページへの誘導を行うなど、追跡・リダイレクトを中心とする挙動が確認されています。一部の報道では、攻撃者が開発者アカウントを侵害して正規の拡張機能をアップデートし悪用した可能性も指摘されています。
2025年7月～2025年12月：正規開発元の拡張機能によるデータ収集
2025年12月に Koi Security 社が公開した記事では、ユーザ数が 600 万人を超える Chrome および Edge向けの無償 VPN 機能を有する拡張機能において、2025年7月9日にリリースされたバージョン以降、主要な AI アシスタントとのチャットや会話ログが収集されていたことが明らかになりました。
本事例では、2025年 12月17日時点において 第三者による明確な悪用は確認されていないものの、Chrome ウェブストア上で「おすすめ」バッジが付与された正規開発元の拡張機能であっても、利用状況や設計次第ではセキュリティリスクにつながり得ることを示唆しています。
ブラウザ拡張機能のリスク要因
悪用事例をふまえ、ブラウザ拡張機能のリスク要因について整理を行います。リスク要因としては以下4点に大別できます。
① 公式ストア以外からの拡張機能追加・利用
Earth Kumihoによる攻撃事例では、特定のレジストリを編集することで、ユーザ操作を介さずに拡張機能を強制インストールする手法が確認されています。
また、ユーザ自身が .crx や .zip ファイルをローカルから読み込むことで、ストアを経由せずに拡張機能を追加することも可能です。これらの導入経路では、ストアの審査や署名検証を回避できるため、悪意あるコードを含む拡張機能が混入するリスクが存在します。
② 自動更新での悪性化リスク
Chrome ウェブストアは、拡張機能の初回登録申請時および更新申請時に自動化された審査、または一部手動による審査を行いますが、定期的な再審査や常時監視は行われていません（参照）。Edgeにおいても同様であり、初回登録時以降の更新において審査は必須ではありません（参照）。
2024年12月セキュリティ会社のCyberhavenが公表した、Chrome向けに提供していた拡張機能の汚染事例があります（ソフトウェアサプライチェーン攻撃）。同社によると、サイバー攻撃者は同社のプラグイン開発者を標的にしたフィッシング攻撃を行い、第三者からでウェブストアにプログラムをアップロードできる状況を作り出しました。アカウントを窃取した上で、悪意のあるバージョンのChrome拡張機能を公開しました（Chromeウェブストアの審査プロセスもクリア）。この悪意あるプログラムは、感染コンピュータからFacebookの認証情報を窃取する機能を持っていました。公開翌日にはこのプログラムは同社によって削除されています。
＜参考情報＞
- Cyberhaven’s Chrome extension security incident and what we’re doing about it （2024年12月27日。Cyberhaven）
- Cyberhaven’s preliminary analysis of the recent malicious Chrome extension （2024年12月27日。Cyberhaven）
上記のような例もあり、審査を経た拡張機能であっても後日更新によって悪性化するケースが存在します。実際の脅威事例においても、認証バッジ取得済の拡張機能が侵害されているケースも確認できており、公式ストアやプラットフォーム側の信頼スコアがリアルタイムなセキュリティ評価と繋がらないことを裏付けています。
① 広域な権限付与
manifest.jsonに定義されるpermissions、host_permissions、matchesにおいて、必要以上の権限を要求する構成はリスクとなり得ます。特に "*://*/*" のように全ドメインを許可する設定や、cookies、tabs、webRequestBlockingなど機密情報や通信制御に関わる権限の組み合わせは、ユーザセッションや通信内容の不正取得を許す可能性があります。
RedDirectionやEarth KumihoによるTRANSELATEXTの解析事例においても、過剰な権限要求が共通の特徴として確認されています。
② 挙動の見え辛さ
拡張機能は利便性が高く広く利用されている一方で、その権限内容やデータ共有範囲は利用者から把握しづらい構造を持っています。
例えば、パスワード管理や生成 AI と連携する拡張機能において、入力情報が外部へ送信される仕様を十分に認識しないまま利用され、機密情報や認証情報の漏洩につながる事例も報告されています。
このように、拡張機能が正規の機能として動作しているのか、想定外の挙動や悪用が生じているのかを判断しにくい点が、リスク要因の一つとなっています。
対策：拡張機能を利用しつつセキュリティを確保するには？
前項で述べたリスク要因に対し、技術面・運用面の双方の観点で対策を検討しました。
一般的にブラウザ拡張機能は高い利便性を持ち、かつその挙動の多様さや連携先サービスの広さから、一律の対策が難しいものです。本稿では拡張機能を全面的に拒否(禁止)しない状態でセキュリティレベルを担保する設計を前提として検討しました。
まずは技術観点での制御・監視方法を記載したうえで、最終的に組織的な管理モデルについて述べます。
技術的対策
前述したリスク要因に対し以下3点について技術的対策として紹介します。実施難易度が低く、即効性があると判断したものから順に記載しました。
公式ストア外からのインストールの防止（公式ストア以外からの拡張機能追加・利用）
前述した通り、ユーザ自身で拡張機能を公式ストア以外からインストールすることが可能です。対策として、拡張機能のインストール元を制御することが考えられます。Chromeでは公開情報に記載の内容から、ADMXファイルを構成し、グループポリシー（以下、GPO）により配布することで拡張機能の設定を制御できることがわかります。本項では、ローカルパス経由でのカスタマイズされた拡張機能のインストールを拒否する設定および、強制インストール設定の無効化設定を記載します。
※例示する内容においてはChromeを対象としたもののみ記載していますが、Edgeでも同様の設定が可能です。
ストア以外からのインストールの拒否：ローカルパス経由での拡張機能インストールをすべて拒否します。
● ADMXポリシー名：BlockExternalExtensions（外部拡張機能のインストールをブロックする）
● 型：Boolean
● 設定値：有効
強制インストールの拒否：強制インストール設定を無効化します。
● ADMXポリシー名：ExtensionInstallForcelist（自動インストールするアプリと拡張機能のリストの設定）
● 型：List
● 設定値：空欄
自動更新の制御（自動更新での悪性化リスク）
拡張機能の自動更新も同様にADMXファイルの構成とGPOによる制御が可能です。
本項では自動更新の無効化と、公式ストアのみから自動更新を可能にする二つの制御方法を記載します。
自動更新の無効化：全拡張機能の自動更新を無効化します。
● ADMXポリシー名：ExtensionSettings（拡張機能の管理設定）
● 型：JSON
● 設定値：{"*": {"update_url": "none"}}
更新元の制限：許可したURLからの更新のみを有効とします。例として、公式ストアのみを指定した設定を記載します。
● ADMXポリシー名：ExtensionInstallSources（拡張機能、アプリ、ユーザスクリプトのインストールソースを設定する）
● 型：List
● 設定値：（以下両方とも設定します）
https://clients2.google.com/service/update2/*
https://chrome.google.com/webstore/*
manifest.jsonの静的解析（過剰な権限の付与）
ブラウザ拡張機能の中枢ファイルである、manifest.jsonにおいてセキュリティ観点で注視すべき5項目を述べます。
ブラウザ拡張機能の構成要素と役割
前段として、まずは拡張機能の構成要素とその役割について整理します。本記事においては、一般的に主流となっているChromiumベースのブラウザ（例：Google Chrome、Microsoft Edge、Brave、Opera、Vivaldiなど）に対応する拡張機能のManifest V3（現行仕様）を対象範囲として記載します。
Chromiumベースのブラウザに対応する拡張機能は、主に以下の要素で構成されています。
- manifestファイル（manifest.json）：拡張機能全体の設定や権限、構成要素を定義する必須の中核ファイル。
- service_worker：拡張機能自体の実際の処理を行う、イベント駆動で動作するスクリプト。
- content_scripts：Webページ内で情報取得を行うスクリプト。
manifest.jsonは拡張機能において唯一ファイル名称が固定されており、このファイル内でservice workerや content scriptsのパス、拡張機能が動作する条件、ならびに拡張機能に付与される権限が定義されています。拡張機能全体の構成や動作範囲を統括する役割を担う、中枢のファイルです。
特にmanifest.jsonでは、以下のような項目によって拡張機能が「何にアクセスできるのか」「どこで動作するのか」が決定されます。
- Permissions：拡張機能が利用可能なブラウザ機能や API（例：タブ情報、ストレージ、通信制御など）を定義します。ここに指定された権限の範囲によって、拡張機能が実行できる操作の幅が決まります。
- host_permissions：拡張機能がアクセス可能な Web サイトや URL の範囲を定義します。特定ドメインのみを対象とする場合もあれば、ワイルドカード指定によって広範な Web サイトにアクセス可能となる場合もあります。
- matches：content scripts が注入・実行される Web ページの URL 条件を定義します。どのページで情報取得や処理が行われるかを決定する重要な項目です。
このように、manifest.jsonを確認することで、拡張機能がどの権限を持ち、どのWebサイト上で、どのような処理を行い得るのかを把握することが可能です。そのため、本記事では manifest.jsonの解析を起点として拡張機能の挙動やリスクを評価します。
① バックグラウンドでの実行スクリプト本体の特定（background.service_worker）
ブラウザ拡張機能として動作するjsファイルの本体を特定します。
importScriptsや外部URL参照がないかを確認します。
② サイト介入範囲と注入タイミング（content_scripts.matches）
matchesの内容を確認します。「*://*/*」が含まれている場合、全ページへの注入リスクが存在します。
③ ホストアクセス権限（host_permissions / optional_host_permissions / <all_urls>）
実際にアクセス可能な外部サイト範囲を確認します。目的（説明文）とアクセス範囲が一致しているかを照合します。
optionalにより後から拡張される設計は注意を払いましょう。
④ 外部連携・通信経路（externally_connectable / update_url / key）
Webサイトから拡張間通信を許可する範囲（externally_connectable.matches）が広すぎないか確認します。
update_urlが独自ドメインの場合、勝手なアップデートで挙動を書き換える可能性があります。
固定keyによる横展開（不正再利用）の兆候も確認します。
⑤ permissionsの記載
permissionsの項目では、既知の文字列のリスト内からAPIの操作権限を指定するため（参照）、リスク評価の指標に含むことが可能です。セキュリティ観点で高リスクの値と、低リスクの値についてそれぞれ次の表にまとめました。
上記に記載した内容を踏まえ、RedDirectionにおける、ブラウザ拡張機能ファイルの解析結果を抜粋して以下に記載します。
manifest.jsonの解析
manifest.jsonのservice_workerの構文から、「javascript/worker.js」がservice_workerとして動作していることが確認できます。同様に「javascript/content.js」がcontent_scriptsであることが確認できました。
繰り返しになりますが、service_workerは拡張機能自体の実際の処理を行う、イベント駆動で動作するスクリプトで、content_scriptsはWebページ内で情報取得を行うスクリプトです。
manifest.jsonのmatchesの末尾には、すべてのドメインを意味する “*://*/*” が記載されていました。matchesはcontent_scriptsがアクセス可能なURLを記載する項目であり、大量に記載されたURLリストの末尾に記載されていることから、後から追記された可能性や、解析を潜り抜ける意図が考えられます。
host_permissionsには “\u003Call_urls” が指定されていました。\003C は「 < 」を意味しており、<all_urls>は全てのURLの全てのファイルに対してアクセス権を持つことを示しています。
また、permissionsでは、スクリプトを実行可能な “scripting”、cookie情報を取得可能である “cookies” や、HTTPリクエストヘッダの書き換えが可能になる “declarativeNetRequest” が含まれていました。
組織が行うべき対策
組織が実施できる対策として、前項の技術的対策を踏まえたうえで、導入前審査の観点と許可/拒否ベースの運用プロセスについて例示します。
導入前審査
Chrome ウェブストアでは一定水準を満たしていると判断された場合に、「おすすめ」または「定評のあるパブリッシャー」のバッジアイコンがそれぞれ付与されます（参照）。「おすすめ」のバッジはGoogleのベストプラクティスに沿っている場合に各拡張機能単位に付与されます。「定評のあるパブリッシャー」のバッジは提供元の身元が確認済であり、デベロッパープログラムポリシーを満たしている場合に付与されます。これらのバッジが完全にセキュリティレベルを担保するとは言えませんが、リスク評価における指標として活用できます。
そのほかにも、Chrome ウェブストア上で確認可能な項目や、前項で記載したmanifestファイルの内容を踏まえてリスクスコアリングのモデルを作成しました。
許可/拒否ベースの運用プロセス
評価または調査の結果、登録を明示的に許可/拒否する方法として、一意の拡張機能IDを用いて制御可能できます。
拡張機能の許可/拒否の管理については、ADMXとGPOを使用することで登録が可能です。
特定拡張機能の拒否登録：例として、解析結果を記載したRedDirectionの拡張機能IDを記載しました。
● ADMXポリシー名：ExtensionInstallBlocklist（拡張機能インストールの拒否リストを設定する）
● 型：List
● 設定値：kpilmncnoafddjpnbhepaiilgkdcieaf
特定拡張機能の許可登録：例として、トレンドマイクロツールバー for Enterpriseの拡張機能IDを記載しました。
● ADMXポリシー名：ExtensionInstallAllowlist（拡張機能インストールの許可リストを設定する）
● 型：List
● 設定値：iiipkionnkhdcficbbpionjlfmnjgnlg
ストア上から追加を許可されていない拡張機能の画面へアクセスした際には以下の警告メッセージが表示され、「Chromeに追加」をクリックすることができない状態になります。
拒否リストに登録した時点で既に追加されていた拡張機能については、動作が無効化され、ユーザ自身の操作により有効化できない状態で拡張機能の一覧画面に残存します。削除する場合はユーザ自身で削除処理を行う必要があります。組織内でのポリシー違反や悪性拡張機能の追加が確認できた場合には個別に削除を依頼することでユーザへの注意喚起へと繋げられる効果が期待できます。
