結論：拡張のブロックだけでは止まらない。入口は「人」、突破口は「正規機能」
Zscaler ThreatLabzは2026年6月23日、Microsoft Edgeの拡張機能を悪用する新たな攻撃「Edgecution」を報告しました（出典：Zscaler ThreatLabz、2026年6月23日）。この攻撃が情報システム部門・セキュリティ担当にとって厄介なのは、二つの理由が重なっているためです。
第一に、ブラウザのサンドボックス（拡張機能を隔離する仕組み）を破るために、不正な脆弱性ではなく「Native Messaging」という正規の標準機能を悪用している点です。Native Messagingは本来、拡張機能から外部のネイティブアプリと通信させるための仕組みで、Chromium系ブラウザ（Edgeを含む）が公式にサポートしています。Zscalerは「Chrome系ブラウザはNative Messagingをサポートし、サードパーティ製アプリがサンドボックス外で動作し、ファイルシステムやOSにアクセスできるようにしている」と説明しています（出典：同レポート）。つまり、ブラウザに「禁じ手」を使わせるのではなく、ブラウザが正しく備えている橋を渡られているのが本質です。
第二に、その入口が技術ではなく「人」である点です。攻撃はMicrosoft Teams上で自社のIT担当者になりすまし、従業員を偽のサポートページへ誘導するソーシャルエンジニアリングから始まります（出典：同レポート）。攻撃者は初期アクセスブローカー（IAB）であり、Zscalerはこの活動をPayouts Kingランサムウェアと関連づけています（出典：同レポート）。すなわちEdgecutionは「侵入の足場づくり」であり、その先にランサムウェア被害が控えている、というのが警戒すべき構図です。
したがって防御の結論は明確です。拡張機能のブロックという一点だけでは不十分で、(1)入口である従業員教育、(2)正規機能であるNative Messagingホストの統制、(3)実行された不審プロセスを捉えるEDR、この三層を同時に回す必要があります。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
攻撃の流れ：Teams詐称から「見えないEdge」でのコード実行まで
Zscalerの報告にもとづく攻撃チェーンは、おおむね次の順序です。
| 段階 | 攻撃者の行動 | 利用される弱点 |
|---|---|---|
| 1. 接触 | Microsoft Teamsで自社IT担当者を詐称してメッセージを送る | 「社内ITからの連絡」という信頼 |
| 2. 誘導 | 偽の「Outlook Updates Management Console」ページへ誘導し、スパムフィルタ更新やOutlook更新を装ったダウンロードを促す | 正規アップデートと見分けにくいUI |
| 3. 投下 | AutoHotKeyスクリプト・バッチ・PowerShellの3通りのいずれかで実行 | 実行ファイルへの警戒の薄さ |
| 4. 脱獄 | Native Messaging用のマニフェストを作成し、拡張とネイティブアプリ（バックドア）を橋渡しする構成を用意 | 正規機能であるNative Messaging |
| 5. 隠蔽実行 | プロンプトや警告を出さずに、ヘッドレス（非表示）のEdgeウィンドウで拡張を読み込む | ユーザーから見えない |
| 6. 制御 | 拡張がC2へビーコンし、ホスト上のコマンドをPythonバックドアへ中継して実行 | C2との常時通信 |
注目すべきは段階5です。Zscalerは、拡張がユーザーに一切のプロンプトや警告を出さず、隠れたブラウザウィンドウで読み込まれるため、被害者からは不可視になると述べています（出典：同レポート）。通常、ユーザーが画面上で異変に気づくチャンスがここで失われます。
C2インフラについては、4つのAWS CloudFront上にホストされたサーバーがWebSocketエンドポイントを持つと報告されています（出典：同レポート）。正規のクラウドCDNを経由するため、宛先ドメインだけで悪性と判断しにくい点も対処を難しくしています。
Edgecutionの2つの部品：拡張は「連絡係」、Pythonバックドアが「実行部隊」
Edgecutionは役割の異なる2つのコンポーネントで構成されます（出典：同レポート）。
- Microsoft Edge拡張機能：C2サーバーへビーコン（定期通信）し、ホストで実行すべきコマンドをPythonバックドアへ中継する「連絡係」。
- Pythonバックドア：実際の悪性機能を担う「実行部隊」。
Zscalerによれば、Pythonバックドアはシェルコマンドの実行、PowerShellコマンドの実行、Pythonコードの実行、ファイルのディスクへの書き込み、実行中プロセスの一覧取得、システム情報の収集が可能です（出典：同レポート）。これは「任意コード実行＋情報収集＋永続化の足場」という、IABが侵入後に求める機能をほぼ網羅しています。
ここから導ける独自の示唆は、Edgecutionを単独の「悪性拡張インシデント」として扱うと対処を誤る、ということです。拡張はあくまで通信の中継役であり、実害（任意コード実行）はOSネイティブのPythonプロセス側で起きます。したがって、ブラウザ層の検知（不審な拡張の有無）だけを見て「拡張を消したから収束」と判断すると、ネイティブ側に残った足場やC2通信を見落としかねません。検知と封じ込めは、ブラウザ層とエンドポイント層（プロセス・ネイティブメッセージングホスト・C2通信）の両面で行うべきです。
自社への翻訳：多層防御チェックリスト
Edgecutionは「人（Teams詐称）」「正規機能（Native Messaging）」「ネイティブ実行（Pythonバックドア）」の三層にまたがります。防御も同じ三層で設計します。Zscaler自身も、ブラウザ拡張機能のインストール監視、Native Messagingホスト構成への厳格な統制、そしてIT管理者になりすました不審な指示を見抜くための従業員教育を組み合わせた「多層防御（defense-in-depth）」の姿勢を推奨しています（出典：同レポート）。本記事ではこれに、実行されたネイティブプロセスを捉える検知層としてEDRを補完策として加えて整理します。以下は実務に落とすためのチェックリストです。
入口（人・教育）
- Teamsで「社内IT」を名乗る外部からの連絡を、正規の社内窓口で折り返し確認する運用を周知したか
- 「スパムフィルタ更新」「Outlook更新」をうたうダウンロード指示は、IT部門の正規配布経路以外では実行しないルールを明文化したか
- 外部組織からのTeamsチャット（外部参加）を許可するか、許可する場合の表示・警告を見直したか
技術統制（拡張・ネイティブホスト）
- Edgeの拡張機能をグループポリシー等で許可リスト方式（明示的に許可した拡張のみ）に統制しているか
- 開発者モードでのサイドロードや、コマンドラインからの拡張読み込みを制限しているか
- Native Messagingホストの登録（マニフェストの作成・レジストリ登録）を監視・制限の対象にしているか
- 業務に不要なAutoHotKey・スクリプト実行を端末ポリシーで抑制しているか
検知・対応（EDR・運用）
- ヘッドレス／非表示でのブラウザ起動や、ブラウザから子プロセスとしてPythonやPowerShellが起動する挙動をEDRで検知できるか
- CloudFront等の正規CDN経由でも、WebSocketによる継続的なC2通信を異常として捉えられるか
- 侵害が疑われた際、拡張の削除だけでなくネイティブ側の足場とC2通信まで封じ込める手順が整備されているか
このチェックリストの肝は、どれか一つでは止まらないという点です。教育を徹底しても誰かは踏みます。拡張を統制してもNative Messaging自体は正規機能です。だからこそ、最後にEDRで「ブラウザから不審なネイティブプロセスが起動する」という異常挙動を捉える層が要ります。
いつGXOに相談すべきか
次のような状態にあるなら、Edgecutionのような複合攻撃に対する備えを点検するタイミングです。
- EDRは導入したが、ブラウザ起点の子プロセスやNative Messaging悪用を検知・運用できているか自信がない
- 拡張機能やスクリプト実行の端末ポリシーが整理されておらず、どこから手をつけるべきか分からない
- 万一侵入された場合の封じ込め・復旧手順（インシデント対応体制）が決まっていない
まずは現状の検知・統制の抜けを洗い出すところから始められます。EDRや拡張・端末統制を含む防御の現在地を把握したい場合は、セキュリティ運用の現状診断から検討できます。検知ルールの調整や脅威動向の追従を社内だけで回し切れない場合は、月額で運用を伴走するセキュリティ運用の伴走（リテイナー）が選択肢になります。すでに不審な挙動や侵害の兆候がある場合は、被害が広がる前にインシデント対応の相談へつないでください。Edgecutionは初期アクセスブローカーによる足場づくりであり、初動の速さがランサムウェア被害の有無を分けます。
FAQ
Q. 拡張機能をすべて禁止すれば防げますか。 A. 入口の一部は塞げますが十分ではありません。Edgecutionが悪用するNative Messaging自体は正規機能であり、攻撃の起点はTeamsでのIT部門詐称という人の脆弱性です。拡張統制に加え、教育とEDRによる挙動検知を組み合わせる必要があります（攻撃手法はZscalerの報告による）。
Q. ユーザーが画面で気づけますか。 A. Zscalerは、拡張がプロンプトや警告を出さず、ヘッドレス（非表示）のEdgeウィンドウで読み込まれるため被害者からは不可視になると報告しています。画面上の気づきに依存せず、エンドポイント側の検知が前提になります。
Q. Microsoft Edge特有の問題ですか。 A. 報告された攻撃はEdgeを使いますが、Native MessagingはChromium系ブラウザが共通でサポートする仕組みです。Edgeだけの固有欠陥ではなく、正規機能の悪用という性質上、他のChromium系ブラウザでも同種の発想が成立し得る点に留意してください（一般的な仕組みの説明であり、他ブラウザでの実例の有無は本記事では断定しません）。
