WRAITH ― ブラウザフッキングとブラインドXSSページミラーリング – Darknet – Hacking Tools, Hacker News & Cyber Security

WRAITHは、BeEF方式のコマンドチャネルと、xsshunter-expressのようなツールが通常担う証拠収集機能を組み合わせたブラウザフッキングフレームワークです。JavaScriptフックがWebSocket経由でコールバックし、オペレーターコンソールに表示され、キャプチャ・ソーシャルエンジニアリング・ローカル偵察の各モジュールを受け取ることができます。

公開リポジトリは2026年8月1日に登場しました。3件のコミットはすべてその日のうちに行われており、初回のコード公開、メタデータの修正、ドキュメントの更新という内訳です。パッケージのバージョンは1.0.0と記載されていますが、GitHub上のリリースは存在せず、プロジェクト自体も開発途上（work in progress）であると説明されています。

Darknetは2006年10月にBeEFを初めて取り上げ、そのモジュール式コンソールと制御下にあるブラウザの一覧が話題となりました。BeEFは今もフック済みブラウザをコマンドモジュールの橋頭堡として利用しています。WRAITHはそのモデルを踏襲しつつ、ブラインドXSSツールに期待される一撃型の証拠収集機能を加え、さらにキャプチャしたページをナビゲート可能にしようと試みています。

フック自体は追いやすいほどコンパクトです。スクリプトのURLからコールバックアドレスを導き出し、公開されている/ws/hookエンドポイントに接続してブラウザフィンガープリントを送信します。オペレーターはその稼働中のブラウザにJavaScriptモジュールを展開でき、完了した結果は同じチャネルを通じて返送され、サーバー側に保存されます。

Page Captureはデフォルトで自動的に発火します。オリジン・URL・リファラを記録し、JavaScriptから参照可能なCookieを読み取り、DOMをシリアライズしてスクリーンショットの取得を試みます。実装では2つの重要な失敗要因を隠すのではなく明示しています。すなわち、HttpOnly Cookieはそもそも JavaScriptから取得できないこと、そしてコンテンツセキュリティポリシー（CSP）やクロスオリジン画像がスクリーンショットの取得を妨げる場合があることです。

Page Mirrorはこれとは異なるアプローチを取ります。オペレーターがリンクをたどると、そのコマンドはフック済みブラウザに中継されます。そのブラウザはクレデンシャルを含めてfetch()を呼び出し、レスポンスを読み取って返されたHTMLをWRAITHに送り返します。したがって、このリクエストにはJavaScriptが直接読み取れないCookie（HttpOnlyのセッションCookieを含む）も付与されます。ブラウザが対象条件を満たす同一オリジンリクエストに対して自動的にそれらを付与するためです。

それでもHttpOnlyは本来の役割を果たしています。Cookieの値自体はフックに対して露出しません。ただし、オリジン内で既に実行中のコードが、ブラウザに認証済みリクエストの発行を要求すること自体は防げません。WRAITHは実習用ラボでこの違いを可視化しており、そこではキャプチャされたCookie一覧は空でありながら、ミラーリングされたリクエストはセッションで保護されたページにアクセスできてしまいます。

オペレーターが被害者の元のタブを直接遠隔操作しているわけではありません。WRAITHは返却されたHTMLからスクリプトを除去し、ベースURLを挿入し、リンククリックをインターセプトし、サンドボックス化されたフレーム内でのフォーム送信をブロックします。選択された各リンクは、フック済みブラウザを経由した新たなクレデンシャル付きGETリクエストとなります。

有用なリンクを備えたサーバーレンダリング型のアプリケーションであれば、ナビゲート可能な証拠集合になり得ます。一方、インターフェースがJavaScriptに依存するクライアント重視型のアプリケーションは忠実には再現されず、フォーム送信を要するワークフローは意図的に停止されます。「ミラー」と呼ぶのは妥当ですが、完全なリモートブラウザセッションとして扱うのは適切ではありません。

レッドチーム演習における有用な運用手順は、認可済みのJavaScript実行が既に達成された後に始まります。Page Captureはブラインドペイロードがどこで発火したかを特定します。続いてPage Mirrorは、セッショントークンを先に抽出することなく、そのブラウザセッションから参照可能な同一オリジンのページを調査できます。クロスオリジンの読み取りは引き続きブラウザの同一オリジンポリシー（Same-Origin Policy）の制約を受けます。

検証内容

筆者は現行のmainブランチをクローンし、ロックされたNode依存関係をインストールしたうえで、WRAITHをループバック上で起動しました。オペレーターコンソール、デモページ、実習用ラボ、フックスクリプトはいずれもHTTP 200を返しました。12個すべてのJavaScriptファイルがNodeの構文チェッカーを通過しています。

公開バインドに対する保護機能も、文書通りに動作しました。オペレーターパスワードを設定せずに0.0.0.0でサーバーを起動すると、ステータス1で終了し、コンソールの公開が拒否されました。今回、筆者は2台目のブラウザを接続したり、オーバーレイを展開したり、同梱のローカルラボ以外を対象にPage Mirrorを実行したりはしていません。

インストール

文書化されているDocker方式には、Node.js 18以降、Docker、Docker Composeが必要です。リポジトリに記載されたセットアップ手順は次のとおりです。

setup.shは公開アドレスとオペレーターの認証情報を尋ね、セッション署名用のシークレットを生成し、保護された.envファイルを書き出したうえでコンテナを起動します。ローカル開発向けの手順として、npm installに続けてnpm startを実行する方法も記載されています。

このサービスはオペレーターパスワードなしでの公開バインドを拒否しますが、フックエンドポイントは設計上、外部から到達可能な状態を保つ必要があります。したがって実運用の展開には、パスワードだけでは不十分です。プロジェクトのデプロイガイドでは、TLSの利用、コホートごとの個別クレデンシャル、そして演習終了後にサービスを撤去することが推奨されています。

サーバー自体が証拠管理境界の一部になる

WRAITHは、キャプチャしたクレデンシャル、DOMコンテンツ、スキャン結果、ミラーリングされたページのHTMLをdata/sessions.json配下に保存します。セッションごとに最大60ページ分のミラーリング結果を保持し、保存されるHTMLは1ページあたり2メガバイトを上限としています。コンソール上でセッションを非表示にしても削除にはならず、オペレーターが恒久的に削除するための操作は別途用意されています。

この点から、認可済みの演習であってもWRAITHをホストするサーバー自体がセンシティブな存在になります。データディレクトリには、その演習で示そうとしていたアプリケーションのコンテンツやクレデンシャルそのものが含まれ得るからです。保持期間、アクセス制御、撤去手順は、最初のペイロードを配信する前にテスト計画の中で定めておくべきものであり、コンソールが証拠を収集し終えてから考えるべきことではありません。

WRAITHはまだBeEFの代替にはならない

BeEFは数千件のコミット、拡張機能の仕組み、そして豊富なコマンドモジュールのカタログを積み重ねてきました。これに対しWRAITHが現時点で備えるのは、はるかに小規模な機能セットです。3種類のログインオーバーレイ、ページキャプチャ、そしてミラー機能に加えたブラウザベースのポートスキャナーです。この比較は、設計上の系譜を示すという意味では有用ですが、機能面での対等性を示すものではありません。

ブラインドXSSツールは通常、ペイロードが実行されたことを証明し、スナップショットを返すものです。従来型のブラウザフックは対話的なコマンドチャネルを提供します。WRAITHはこれらの段階を統合し、HttpOnly Cookieを盗み取ったと主張することなく、クレデンシャル付きの同一オリジンリンク巡回機能を加えています。

この境界線自体は目新しいものではありません。Darknetは2025年7月にevilreplayを取り上げています。これも、オリジン内で既に実行中のJavaScriptを利用し、Cookieの値を読み取ることなく認証済みブラウザセッションを介して動作するという点で共通しています。違いは運用面にあります。evilreplayが対話的なポストエクスプロイテーション制御を狙うのに対し、WRAITHのPage Mirrorは意図的に守備範囲を絞り込み、クレデンシャル付きの同一オリジンGET巡回に特化させ、スクリプトを除去しフォームをブロックします。WRAITHはこの巡回機能をブラインドXSSキャプチャや永続的なモジュールチャネルと並べてパッケージ化しているのであって、新たなセッション乗っ取り手法を確立しているわけではありません。

未解決の課題は、時間の経過に伴うブラウザの挙動です。WRAITH自体のネットワークスキャンに関する注記でも、信頼性の高いループバックチェックと、新しいブラウザ制御の影響を受けるLANモードとを既に区別しています。Page Mirrorも同様に、fetchの挙動、セッションポリシー、ミラーリング対象アプリケーションの構造に直接左右されます。自動テストスイートが存在せず、公開以降コードの改訂もない現状では、こうした境界は実際の演習で使用するブラウザやアプリケーション上で改めて検証される必要があります。

WRAITHをダウンロードし、GitHubでソースコードを確認する。