稼働中のChromeやEdgeから認証セッションを奪取、DevTools機能を悪用する新手法が判明

要点

• Windows上で稼働しているGoogle ChromeやMicrosoft Edgeのプロセス内部から、開発者向けデバッグ機能（CDP）を直接有効化する攻撃手法が報告された。

• 本手法はすでに端末内でコード実行が可能な状態を前提とする「ポストエクスプロイト（侵入後活動）」の手法であり、ブラウザ自体の未知の脆弱性を突くものではない。

• Googleが導入したデータ暗号化や起動オプションの制限を迂回し、ディスク上のファイルを直接読まずにCookieや保存パスワードを抽出できる。

• 攻撃者は有効化されたデバッグポートを介して、被害者のログインセッションや企業向け認証状態を保持したままブラウザを遠隔操作できる。

• 防御側においては、Sysmonなどのイベントログを用いてブラウザプロセスへの不審なインジェクションを監視することで検知が可能とされる。

• サイバーセキュリティ企業のSpecterOpsなどの調査により、Windows上で実行中のGoogle ChromeおよびMicrosoft Edgeの内部プロセスを操作し、認証済みセッションやCookie情報を窃取する新たな攻撃手法の詳細が明らかになった。

• 本手法はブラウザ自体のセキュリティ欠陥を直接突くものではなく、すでに端末へ侵入した攻撃者がブラウザ内部のデバッグインターフェースを有効化することで、保護されたデータを取得する侵入後の攻撃アプローチだという。海外セキュリティメディアのThe Hacker Newsが報じた。

侵入後のプロセス操作と前提条件

今回報告された手法は、攻撃者が対象のWindows端末上で何らかの手段によりすでにコードを実行できる権限を持っていることを前提としている。外部からリモートで直接ブラウザの脆弱性を突いて侵入する攻撃とは異なり、侵入後の侵害拡大や情報収集（ポストエクスプロイト）のフェーズで利用される。

SpecterOpsによると、この攻撃は稼働中のブラウザプロセスに対して外部から干渉を行うため、防御側はWindowsのログ監視ツール「Sysmon」のイベントID 8（リモートスレッド作成）やイベントID 10（プロセスアクセス）などを確認することで、chrome.exeやmsedge.exeを標的としたプロセスインジェクション（他のプロセスへ不正にコードを注入する行為）の兆候を検知できると説明している。

ブラウザ側の防御策とそれを迂回するアプローチ

Googleは以前より、ブラウザに保存されたCookieなどのデータを保護するため「App-Bound Encryption（ABE：アプリケーション境界による暗号化保護技術）」などの防御機構を導入してきた。しかし、ABEの導入以降、攻撃者が保護を回避するために「Chrome Remote Debugging（リモートデバッグ機能）」を悪用してCookieを抜き取る手口が増加したと、Googleは2025年3月の投稿で言及している。

こうした悪用を防ぐため、GoogleはChrome 136以降でリモートデバッグの挙動を変更した。通常のデータディレクトリを対象とする場合、非標準のユーザーデータディレクトリ（--user-data-dir）が明示的に指定されていない限り、起動オプションである --remote-debugging-port や --remote-debugging-pipe を無視する仕様とした。異なるディレクトリを指定させることで別の暗号化キーが適用され、正規データの保護を図る仕組みだ。

これに対し、今回公開された「CDP-Enable-BOF」と呼ばれるツールは、起動オプション経由ではなく、すでに起動しているブラウザプロセス（chrome.exeまたはmsedge.exe）の内部から直接デバッグサーバーを強制的に起動させるという別のアプローチをとる。これにより、ブラウザが保持している正規のコンテキストをそのまま開発者向けインターフェースである「Chrome DevTools Protocol（CDP）」のポートとして外部へ公開してしまう。

内部関数を呼び出す仕組み

この手法は、セキュリティ研究者のDeathFlamingo氏が2025年12月に発表したMicrosoft EdgeへのCDP注入に関する研究や、Cedric Van Bockhaven氏のセッションハイジャック研究を基礎として構築された。

公開されたツール「CDP-Enable-BOF」は、ペネトレーションテスト等で用いられるCobalt Strikeなどのフレームワークで動作する拡張モジュール（BOF：Beacon Object File）として実装されており、以下の手順でデバッグサーバーを起動する。

1. 実行中のChromeまたはEdgeのプロセスとトップレベルウィンドウを特定する。
2. ロードされている chrome.dll または msedge.dll モジュールのアドレスを特定する。
3. マスクされたバイトシグネチャを用いてChromium内部のシンボル（関数情報）を解決する。
4. プロセス内に2つの小さなスタブコードとコンテキストブロック用のメモリ領域を割り当てる。
5. 一時的にリモートウィンドウプロシージャをインストールする。
6. ブラウザのユーザーインターフェース（UI）スレッド上で最終的な呼び出しを実行する。
7. 指定されたポート番号でChromium内部の関数「StartRemoteDebuggingServer」を実行する。

ツールの開発元によると、呼び出しをブラウザのUIスレッド上で実行することで、CFG（Control Flow Guard）やTLS、CET（Control-flow Enforcement Technology）といった最新のWindows環境における各種メモリ保護機構が存在する場合でも、安定して動作させることができるという。なお、このツールは64ビット（x64）環境を対象としており、動作させるためには対象のブラウザがすでに起動している必要がある。管理者権限が常に必須であるかどうかについてはリポジトリ上に明記されておらず、詳細の確認が進められている。

CDPを経由したセッション奪取とデータ抽出

デバッグポートが開かれると、連携ツールである「CDP-Toolkit」を用いてブラウザ内部の様々なデータへアクセスしたり、操作を自動化したりすることが可能になる。元記事では、主な攻撃ワークフローとして以下の4点が挙げられている。

• Cookieの収集: CDPのコマンド（Storage.getCookies）を用いることで、ディスク上に保存されたCookieデータベースファイルを読み取ることなく、ブラウザのメモリ内から直接Cookie状態を取得する。
• ブラウザデータの収集: 閲覧履歴、ブックマーク、インストール済み拡張機能の一覧、画面のスクリーンショット、保存されたパスワードのメタデータなどを、CDP経由および描画されたWebUIページを通じて取得する。
• 保存パスワードの復元: Chromiumの自動入力（autofill）機能を特定のオリジンに対して作動させ、入力されたユーザー名とパスワードの値をCDP経由で読み取る。
• ブラウザの乗っ取りとプロキシ利用: バックグラウンドや画面外にブラウザターゲットを生成して対話的な画面ストリーミングを行ったり、被害者の認証状態を引き継いだブラウザターゲットを経由させてHTTP/HTTPSリクエストをプロキシ送信したりする。

画面共有（スクリーンキャスト）やプロキシを利用するモードでは、Cookieやローカルストレージ、企業向けの認証状態、WebAuthnの認証セッション、拡張機能の動作などが、侵害された端末上の正規ブラウザインスタンス内に保持されたまま処理される。攻撃者は被害者の正規なログイン環境をそのまま流用する形で、Webサービスや社内システムへのアクセスを行える状態になるという。