Responder-BrowserListener の使い方

目次

はじめに

Responder は、ネットワークペネトレーションテストやセキュリティ評価において広く利用されている強力なツールです。主に LLMNR (Link-Local Multicast Name Resolution)、NBT-NS (NetBIOS Name Service)、MDNS (Multicast DNS) のポイズニング攻撃を通じて、ネットワーク上の認証情報（特に NTLM ハッシュ）を窃取することを目的としています。

Responder は多機能であり、HTTP/SMB/MSSQL/FTP/LDAP などの偽の認証サーバーを起動する機能を持っています。これにより、クライアントが誤ってこれらの偽サーバーに接続しようとした際に、認証情報を取得できます。

この記事では、Responder の数ある機能の中でも、特に BrowserListener モジュールに焦点を当てて解説します。BrowserListener は、主に Web ブラウザのトラフィックをターゲットとし、特に WPAD (Web Proxy Auto-Discovery Protocol) を悪用してプロキシ設定を乗っ取り、ブラウザ経由での認証情報を取得しようとします。この機能は、特に企業ネットワーク環境など、プロキシが利用されている環境で効果を発揮することがあります。

この記事を通して、Responder の BrowserListener がどのように動作し、どのように利用できるのか、そしてそれに対する防御策について理解を深めていきましょう。

注意: Responder のようなツールは、許可されたネットワーク環境でのセキュリティ評価やペネトレーションテストの目的でのみ使用してください。許可なく他者のネットワークで使用することは、法律に違反する可能性があります。倫理的な利用を心掛けてください。

Responder と BrowserListener の概要

Responder は、Laurent Gaffie によって開発されたオープンソースのツールで、主に Windows ネットワーク環境における名前解決プロトコルの脆弱性を突くことで知られています。具体的には、DNS サーバーが応答しない、あるいは設定されていない場合にフォールバックとして使用される LLMNR や NBT-NS といったプロトコルに対して偽の応答を送信します（ポイズニング）。これにより、本来接続すべきサーバーの代わりに攻撃者のマシンに接続させ、認証情報を窃取します。

Responder は、以下のような様々な偽のサーバー機能を提供します:

  • HTTP/HTTPS サーバー
  • SMB サーバー
  • MSSQL サーバー
  • FTP サーバー
  • LDAP サーバー
  • DNS サーバー
  • WPAD プロキシサーバー
  • その他 (POP3, IMAP, SMTP など)

BrowserListener モジュールは、これらの機能の一部、特に WPAD プロキシサーバー機能と密接に関連しています。このモジュールの主な目的は、ネットワーク上のドメインコントローラー（PDC – Primary Domain Controller）を「ステルスモード」で発見することにあると説明されていますが、実際には WPAD の悪用に関連する動作を担っていると考えられます。

WPAD は、クライアント（特に Internet Explorer などの Web ブラウザ）がネットワーク上のプロキシ設定を自動的に検出するためのプロトコルです。クライアントは通常、DHCP または DNS を通じて `wpad.dat` という設定ファイル（PAC – Proxy Auto-Config ファイル）の場所を問い合わせます。攻撃者は Responder を使用してこの問い合わせに応答し、偽の `wpad.dat` ファイルを提供します。この偽ファイルは、ブラウザのトラフィックを攻撃者のマシン（Responder が動作しているマシン）を経由するように指示します。

ブラウザが攻撃者のプロキシサーバーを経由して通信しようとすると、Responder はプロキシ認証を要求することができます。ユーザーが気付かずに（あるいは騙されて）ドメインの認証情報を入力すると、Responder はそれをキャプチャします。これが WPAD を悪用した中間者攻撃 (MITM) の基本的な流れです。

BrowserListener (WPAD プロキシ機能) の仕組み

Responder が WPAD プロキシとして機能し、認証情報を取得するプロセスは、いくつかのステップに分けられます。

  1. WPAD 要求の待機: クライアントマシン（特に Windows）のブラウザが「プロキシ設定を自動的に検出する」ように構成されている場合、ネットワークに接続した際などに WPAD 設定ファイルの場所を問い合わせます。これは通常、DNS で `wpad.domain.com` のような名前解決を試みるか、DHCP オプション 252 を通じて行われます。
  2. 名前解決のポイズニング: 多くの組織では `wpad.domain.com` という DNS レコードが存在しません。DNS で解決できなかった場合、Windows は LLMNR や NBT-NS を使ってローカルネットワークに `WPAD` という名前のホストを探す問い合わせをブロードキャスト/マルチキャストします。Responder はこれらの問い合わせをリッスンしており、正規のサーバーよりも早く「自分が WPAD サーバーだ」と応答します（レースコンディションを利用）。
  3. 偽 PAC ファイルの提供: クライアントは、Responder が指定した偽の WPAD サーバー（つまり Responder 自身）に対して `wpad.dat` ファイルを要求します。Responder は、あらかじめ用意された、あるいは設定ファイル (`Responder.conf`) でカスタマイズされた PAC ファイルをクライアントに送信します。
  4. プロキシ設定の適用: クライアントのブラウザは受け取った PAC ファイルを実行し、その指示に従ってプロキシサーバーを設定します。この PAC ファイルは、特定の URL（ローカルホストなど）を除くほとんどの Web トラフィックを、Responder が動作している攻撃者のマシンの特定のポート（デフォルトでは 3141 や 3128）に向けるように記述されています。
  5. プロキシ認証の要求と認証情報のキャプチャ: ブラウザが Responder プロキシ経由でインターネットにアクセスしようとすると、Responder はプロキシ認証（通常は Basic 認証や NTLM 認証）を要求する応答を返します。多くのブラウザ（特に Internet Explorer や Edge）は、ユーザーに認証ダイアログを表示します。ユーザーがドメインのユーザー名とパスワードを入力すると、その認証情報（Basic 認証なら平文、NTLM ならハッシュ形式）が Responder に送信され、キャプチャ・記録されます。

Responder は、-F オプションを使用することで、`wpad.dat` ファイルの取得自体に対しても NTLM 認証を強制することができます。これにより、ユーザーがブラウザで Web サイトにアクセスする前であっても、認証情報を取得できる可能性があります (ただし、このオプションはデフォルトでは無効です)。

ポイント: WPAD 攻撃は、クライアント側の「プロキシ設定を自動的に検出する」オプションが有効になっていることが前提となります。これは多くの Windows 環境でデフォルトで有効になっています。

Responder-BrowserListener の使い方

Responder を使用して WPAD プロキシ攻撃を実行し、ブラウザ経由の認証情報を取得する基本的な手順を説明します。通常、Kali Linux などのペネトレーションテスト用ディストリビューションには Responder がプレインストールされています。もしインストールされていない場合は、GitHub からクローンしてセットアップできます。 

# GitHub から Responder をクローンする場合
git clone https://github.com/SpiderLabs/Responder.git
cd Responder

基本的な起動方法

最も基本的な起動コマンドは以下のようになります。 

sudo python Responder.py -I eth0 -w -b -v

各オプションの意味は以下の通りです。

  • sudo: Responder はネットワークインターフェースをリッスンし、特権ポートを使用するため、管理者権限が必要です。
  • python Responder.py: Responder スクリプトを実行します。環境によっては単に responder コマンドで実行できる場合もあります。
  • -I eth0: リッスンするネットワークインターフェースを指定します。eth0 は環境に合わせて適切なインターフェース名（例: ens33, wlan0 など）に変更してください。
  • -w: WPAD 不正プロキシサーバーを開始します。これが BrowserListener 機能の核心部分です。
  • -b: HTTP Basic 認証を要求します。これにより、ユーザー名とパスワードが平文でキャプチャされる可能性があります。（NTLM 認証を狙う場合は、このオプションを付けないか、Responder.conf で設定します）
  • -v: 詳細モード (Verbose) で実行し、より多くの情報を表示します。

このコマンドを実行すると、Responder は指定されたインターフェースで LLMNR/NBT-NS の問い合わせと WPAD 要求を待ち受けます。クライアントが WPAD を解決しようとし、Responder が応答に成功すると、クライアントのブラウザは Responder をプロキシとして使用し始めます。そして、ユーザーが Web サイトにアクセスしようとした際に認証プロンプトが表示され、入力された認証情報が Responder のコンソールに表示され、ログファイルにも記録されます。

Responder.conf の設定

Responder の動作は Responder.conf ファイルで詳細にカスタマイズできます。WPAD プロキシに関連する主な設定項目には以下のようなものがあります。

設定項目説明デフォルト値 (例)
WPADProxyServerWPAD プロキシサーバーを有効にするかどうか。-w オプションで上書き可能。On / Off
WPADResponsePortWPAD プロキシサーバーがリッスンするポート。3128
WPADAuthWPAD プロキシで要求する認証タイプ (NTLM, Basic)。-b オプションで Basic 認証を強制可能。NTLM
WPADConfigScriptクライアントに提供する PAC スクリプトのテンプレート。ここでプロキシとして動作するサーバーのアドレスやポートを指定します。(スクリプト内容)
Serve-Html認証要求の代わりに、カスタム HTML ページを提供するかどうか。Off
HtmlFilenameServe-Html = On の場合に提供する HTML ファイル名。payload.html
Serve-Exe認証要求や HTML の代わりに、実行可能ファイルを提供するかどうか。（悪意のあるファイルの配布に使用される可能性あり）Off
ExeFilenameServe-Exe = On の場合に提供する実行可能ファイル名。payload.exe

例えば、カスタムの PAC ファイルを使用したい場合や、認証プロンプトの代わりに特定の HTML ページを表示させたい場合（フィッシング目的など）は、この設定ファイルを編集します。

その他のオプション

  • -F: WPAD (`wpad.dat`) ファイルの取得要求に対して NTLM 認証を強制します。これにより、ブラウザが実際に Web アクセスを行う前に認証情報（ハッシュ）を取得できる可能性があります。デフォルトは無効です。
  • -r: Workstation Service (WKSSVC) の NBT-NS 要求にも応答します。デフォルトはファイルサーバーサービス (FSRV) 要求のみに応答します。
  • --lm: LM ハッシュのダウングレードを強制します (古い Windows XP/2003 などが対象)。セキュリティが向上した現代の環境ではあまり効果がないか、推奨されません。

実行例と出力

Responder を起動すると、以下のようなログがコンソールに出力されます。 

$ sudo responder -I eth0 -wbv __ .----.-----.-----.-----.-----.-----.--| |-----.----. | _| -__|__ --| _ | __|-----| | | | _| |__| |_____|_____| __|_____|__|__|__|__|__|__|__| |__| NBT-NS, LLMNR & MDNS Responder 3.1.1.0 Author: Laurent Gaffie (laurent.gaffie@gmail.com) To kill this script hit CTRL-C
[+] Poisoners: LLMNR [ON] NBT-NS [ON] MDNS [ON] DNS [ON] DHCP [OFF]
[+] Servers: HTTP server [ON] HTTPS server [ON] WPAD proxy [ON] <-- WPAD プロキシが有効 Auth proxy [OFF] SMB server [ON] Kerberos server [ON] SQL server [ON] FTP server [ON] IMAP server [ON] POP3 server [ON] SMTP server [ON] DNS server [ON] LDAP server [ON] RDP server [ON] DCE-RPC server [ON] WinRM server [ON]
[+] HTTP Options: Always serving EXE [OFF] Serving EXE [OFF] Serving HTML [OFF] Upstream Proxy [OFF]
[+] Poisoning Options: Analyze Mode [OFF] Force WPAD auth [OFF] Force Basic Auth [ON] <-- Basic 認証が有効 Force LM Downgrade [OFF] Fingerprinting [OFF]
[+] Generic Options: Responder NIC [eth0] Responder IP [192.168.1.100] <-- 攻撃者のIP Challenge [Random] Don't Respond To Self [ON]
[+] Listening for events...
[+] verbose] WPADServer: Listening for WPAD connection on port 3128
...
[WPAD] [192.168.1.150] WPAD File request from: 192.168.1.150:51234 (User-Agent: ...)
[HTTP] Basic Client : 192.168.1.150
[HTTP] Basic Username : DOMAIN\User1
[HTTP] Basic Password : Password123 <-- 認証情報がキャプチャされた！

上記の例では、IP アドレス 192.168.1.150 のクライアントが WPAD ファイルを要求し、その後 Basic 認証でユーザー名 DOMAIN\User1 とパスワード Password123 を送信してきたことがわかります。

キャプチャされた認証情報は、コンソールに出力されるだけでなく、logs/ ディレクトリ内のログファイル（例: Responder-Session.log、HTTP-NTLMv2-192.168.1.150.txt など）や SQLite データベースにも保存されます。NTLM ハッシュが取得された場合は、Hashcat や John the Ripper などのツールを使ってオフラインでのパスワードクラッキングを試みることができます。

攻撃の悪用と影響

Responder による WPAD プロキシ攻撃が成功すると、以下のような影響が考えられます。

  • 認証情報の窃取: 最も直接的な影響は、ユーザーのドメイン認証情報（パスワードまたは NTLM ハッシュ）が攻撃者に漏洩することです。これにより、攻撃者はそのユーザーになりすまして他のシステムやリソースにアクセスできる可能性があります。特に管理者権限を持つアカウントの認証情報が窃取された場合、被害は甚大になります。
  • 中間者攻撃 (MITM): 攻撃者はプロキシとして動作するため、暗号化されていない HTTP 通信の内容を盗聴したり、改ざんしたりすることが可能です。HTTPS 通信も、クライアントが証明書のエラーを無視すれば、解読される可能性があります（Responder は自己署名証明書を使用するため）。
  • フィッシングとマルウェア配布: Responder.conf で設定を変更することで、正規の認証プロンプトの代わりに偽のログインページ（フィッシングサイト）を表示させたり、悪意のある実行可能ファイル（マルウェア）をダウンロードさせたりすることも可能です。
  • 内部ネットワーク情報の探索: ユーザーのブラウジング履歴やアクセス先から、内部ネットワークのサーバーやアプリケーションに関する情報を収集できる場合があります。

対策と緩和策

Responder による WPAD 攻撃や、それに類似した LLMNR/NBT-NS ポイズニング攻撃からネットワークを保護するためには、以下の対策が有効です。

  • WPAD の無効化:
    • 組織内でプロキシの自動検出機能 (WPAD) を使用していない場合は、グループポリシー (GPO) を使用してクライアント PC の「設定を自動的に検出する」オプションを無効にします。
    • Windows サービス `WinHttpAutoProxySvc` (WinHTTP Web Proxy Auto-Discovery Service) を無効化することも有効です。
  • LLMNR と NBT-NS の無効化:
    • 現代のドメイン環境では DNS が主要な名前解決手段であり、LLMNR や NBT-NS は不要な場合が多いです。可能であれば、グループポリシーを使用してこれらのレガシープロトコルを無効化します。
  • DNS での WPAD レコード設定 (WPAD を利用する場合):
    • WPAD を legitimately 使用している場合は、DNS サーバーに `wpad` という名前のホストレコードを正しく登録し、正規の PAC ファイルの場所を指すようにします。これにより、クライアントが LLMNR/NBT-NS にフォールバックするのを防ぎます。
    • Windows Server 2008 以降では、DNS のグローバルクエリブロックリストから `wpad` を削除する必要がある場合があります。
  • ネットワークセグメンテーションとファイアウォール: 適切なネットワークセグメンテーションを行い、不要なブロードキャスト/マルチキャストトラフィックがセグメントを越えないように設定します。
  • 侵入検知/防止システム (IDS/IPS): Responder のようなツールの活動（LLMNR/NBT-NS ポイズニング試行など）を検知・ブロックできる IDS/IPS ソリューションを導入します。
  • 強力なパスワードポリシーと多要素認証 (MFA): 万が一 NTLM ハッシュが漏洩しても、パスワードクラッキングを困難にするために、複雑で長いパスワードの使用を強制します。また、重要なシステムへのアクセスには MFA を導入します。
  • SMB 署名の有効化: SMB トラフィックに対するリレー攻撃を防ぐために、SMB 署名を有効化します (これは NTLM リレー攻撃への対策であり、ハッシュ取得自体を防ぐものではありませんが、取得されたハッシュの悪用を制限します)。
  • エンドポイントセキュリティ: 最新のエンドポイントセキュリティソリューションは、Responder のようなツールの動作や、それによって配布される可能性のあるマルウェアを検知・ブロックできる場合があります。
  • ユーザー教育: 不審な認証プロンプトが表示された場合に、安易に認証情報を入力しないようユーザーに教育します。特に、通常表示されないはずの場面でのプロンプトには注意が必要です。
ベストプラクティス: 可能であれば、WPAD、LLMNR、NBT-NS を無効化することが最も効果的な対策となります。

まとめ

Responder の BrowserListener 機能 (主に WPAD プロキシ機能) は、特に設定が不十分なネットワーク環境において、Web ブラウザを経由してユーザーの認証情報を窃取するための強力な手法です。LLMNR/NBT-NS ポイズニングと WPAD プロトコルの悪用を組み合わせることで、攻撃者は中間者攻撃を仕掛け、機密情報を入手する可能性があります。

この脅威に対抗するためには、不要なレガシープロトコル (LLMNR, NBT-NS) や機能 (WPAD) の無効化、適切なネットワーク設定、そして多層的なセキュリティ対策（強力な認証、ネットワーク監視、ユーザー教育など）を講じることが不可欠です。

セキュリティ専門家は、Responder のようなツールを理解し、その攻撃手法をテスト環境で再現することで、自組織のネットワークの弱点を発見し、より堅牢な防御策を構築することができます。ただし、その利用は常に倫理的な範囲に留め、法規制を遵守する必要があります。

参考情報

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

前の記事

Python ASGI Webフレームワーク「Responde…

次の記事

[Fortranのはじめ方] Part1: Fortranの歴…