※本記事は学習用途・自己所有環境のみを対象とし、他者環境への無断スキャンは不正アクセス禁止法に該当します。
サイバー攻撃というと、インターネットに公開されたWebサーバーやVPN装置が狙われるイメージを持つ人も多いかもしれません。しかし、実際の侵入事例を見ていくと、攻撃の主戦場は必ずしも「外部」だけではありません。
社内ネットワーク、いわゆるLANの内部には、利便性を優先した結果として残り続けている古いプロトコルや設定が存在します。それらは日常業務では問題にならない一方で、攻撃者にとっては極めて扱いやすい入口になります。
Responderは、そうした内部ネットワークの弱点を突き、ユーザーの操作をほとんど伴わずに認証情報を取得できてしまうことを可視化するツールです。脆弱性を直接突くわけではなく、プロトコルの仕様と運用上の甘さを利用する点が、このツールの特徴と言えます。
本記事では、Kali Linuxに標準搭載されているResponderを題材に、なぜ内部ネットワークで認証情報が漏れ得るのか、どのような環境でリスクが顕在化するのかを整理します。あわせて、攻撃手法の紹介にとどまらず、防御や設計見直しの観点で何を考えるべきかについても触れていきます。
Responderは「侵入を成功させるためのツール」であると同時に、内部ネットワークの健全性を測るリトマス試験紙でもあります。取得できた情報そのものよりも、「なぜそれが取得できてしまったのか」を理解することが、本記事の目的です。
Responderとは何か
Responderは、内部ネットワーク上で発生する名前解決通信の挙動を悪用し、認証情報を取得するためのツールです。Kali Linuxに標準搭載されており、特にWindows環境やActive Directoryを含むネットワークの侵入検証において、非常に高い頻度で利用されています。
一般的な攻撃ツールが「脆弱性を突く」ことを目的とするのに対し、Responderが狙うのはプロトコルの仕様と運用上の前提です。設定ミスやゼロデイ脆弱性を必要とせず、ネットワーク内に存在するだけで攻撃が成立する点が特徴と言えます。
Responderが注目するのは、DNSによる名前解決に失敗した際に利用される補助的なプロトコルです。具体的には、LLMNR（Link-Local Multicast Name Resolution） や NBT-NS（NetBIOS Name Service） といった仕組みが対象となります。これらは、利便性を高める目的で導入されたものであり、現在でも多くの企業ネットワークに残っています。
Responderは、こうした名前解決要求に対して正規サーバーになりすました応答を返すことで、クライアントを誘導します。その結果、クライアントは攻撃者を正規の通信相手だと誤認し、認証処理を開始してしまいます。これにより、NTLM認証に用いられるハッシュ情報などが取得可能となります。
重要なのは、この過程においてユーザーが特別な操作を行う必要がほとんどない点です。ファイルを開かせたり、リンクを踏ませたりといったソーシャルエンジニアリングを用いずとも、日常業務の通信の延長線上で情報が取得されてしまうケースがあります。
このようにResponderは、「侵入を試みるツール」というよりも、そのネットワークがどれだけ安全設計から逸脱しているかを示す可視化ツールと捉える方が適切です。使えてしまう環境そのものが、すでにリスクを内包していると言えるでしょう。
なぜ認証情報が取れてしまうのか
Responderを理解するうえで重要なのは、「なぜこのような手法が成立してしまうのか」をプロトコルの視点から把握することです。ここでは、Windows環境における名前解決の仕組みを整理しながら、その背景を見ていきます。
名前解決はDNSだけではない
多くの人は、ホスト名やサーバー名の解決はDNSだけで行われていると考えがちです。しかし、Windows環境ではDNSに加えて、複数の補助的な名前解決プロトコルが存在します。
代表的なものが、LLMNR（Link-Local Multicast Name Resolution） と NBT-NS（NetBIOS Name Service） です。これらは、DNSサーバーに問い合わせができない場合や、ローカルネットワーク内で迅速に名前解決を行うために利用されます。
問題は、DNSでの名前解決に失敗した後も、これらのプロトコルが自動的に使用される点にあります。ユーザーや管理者が明示的に操作しなくても、OSが内部的に処理を続行してしまうため、意識されにくい領域となっています。
LLMNR・NBT-NSの設計上の前提
LLMNRやNBT-NSは、「信頼できるローカルネットワーク」を前提として設計されています。そのため、これらのプロトコルには応答元が正規サーバーであるかを検証する仕組みがほとんど存在しません。
具体的には、クライアントはネットワーク上に対して「この名前のサーバーは存在しますか？」という問い合わせを投げ、最初に返ってきた応答を信じてしまいます。この挙動自体は仕様どおりであり、脆弱性というよりも設計思想の問題と言えます。
Responderはこの点を突き、正規サーバーよりも早く応答を返すことで、通信相手になりすますことを可能にします。
認証情報が送信される理由
クライアントが攻撃者を正規のサーバーだと誤認すると、次に行われるのが認証処理です。Windows環境では、SMBやHTTP通信において、NTLM認証が利用されるケースが多くあります。
このときクライアントは、ユーザー名やパスワードそのものではなく、NTLMハッシュ情報を用いて認証を試みます。Responderはこのやり取りを受け取り、ログとして保存します。
重要なのは、この一連の流れがユーザーの操作とは無関係に発生する点です。ファイル共有へのアクセス、プリンタ探索、スクリプトの実行など、日常業務の延長で認証通信が発生し、その結果として情報が取得されてしまいます。
「取れた＝突破された」ではないが
ここで注意すべきなのは、Responderによって取得されるのはあくまで認証用のハッシュ情報であり、即座にパスワードが漏洩したことを意味するわけではない点です。
しかし、ハッシュが取得できるという事実は、
-
ネットワーク内に攻撃者が存在できる
-
不正な応答を遮断できていない
-
認証プロトコルが適切に制御されていない
という複数の問題が同時に存在していることを示しています。
つまり、Responderが成立してしまう環境は、侵入後の横展開や権限昇格に対して非常に脆弱な状態にあると言えます。
Kali LinuxにおけるResponderの位置づけ
Responderは、Kali Linuxに標準で搭載されているツールの中でも、内部ネットワーク侵入検証の初動フェーズを担う代表的な存在です。Webアプリケーション診断や脆弱性スキャンとは異なり、「すでに内部に入った、もしくは入れた」という前提で使用される点が特徴です。
なぜKaliに標準搭載されているのか
Kali Linuxに収録されているツールは、単に攻撃が派手だからという理由では選定されていません。Responderが標準搭載されている理由は、実環境で成立しやすく、再現性が高いという点にあります。
多くの企業ネットワークでは、以下のような条件が揃っています。
-
Windowsクライアントが多数存在する
-
Active Directory環境が運用されている
-
LLMNR / NBT-NS が明示的に無効化されていない
このような環境では、Responderはほぼ設定不要で機能します。Kali側で特別な準備をせずとも、ネットワークの設計や運用の癖がそのまま結果として現れるため、環境診断ツールとしての価値が非常に高いと言えます。
侵入テストにおけるフェーズ上の役割
侵入テストの流れで整理すると、Responderはおおむね次の段階で利用されます。
-
初期侵入または内部ネットワークへの到達
-
ネットワーク内の挙動・設計の把握
-
認証情報取得の可能性確認
Responderはこのうち、2〜3の境界に位置するツールです。ポートスキャンや脆弱性診断のように「対象を叩く」のではなく、ネットワークが自ら漏らしてしまう情報を待つという性質を持っています。
そのため、実行するだけで即座に結果が出る場合もあれば、何も起きないこともあります。しかし、何も取得できなかった場合でも、それは「少なくともこの観点では対策が取られている」ことを示す重要な結果です。
後続ツールとの関係
Responder単体で完結するケースは多くありません。取得された情報は、後続の検証フェーズで活用されることが一般的です。
-
取得したNTLMハッシュを用いたパスワード強度検証
-
他ホストや他サービスへの横展開可能性の確認
-
認証方式やポリシー設定の妥当性評価
このように、Responderは侵入後攻撃の起点として位置づけられています。裏を返せば、ここで情報が取得できてしまう環境は、連鎖的にリスクが拡大しやすい状態にあると言えます。
攻撃ツールであり、評価ツールでもある
Kali LinuxにおけるResponderの最大の特徴は、「攻撃ができるかどうか」よりも、設計上の前提がどこまで安全側に寄せられているかを確認できる点にあります。
Responderが成立するかどうかは、
-
ネットワーク設計
-
認証方式の選択
-
運用ポリシー
といった複数の要素の積み重ねによって決まります。その意味でResponderは、単なる攻撃ツールではなく、内部ネットワークの成熟度を測る指標として捉えるのが適切でしょう。
Responderの基本的な使い方
Responderは、操作自体は非常にシンプルです。複雑な設定や事前準備を必要とせず、実行するだけでネットワークの状態がそのまま結果に表れる点が、このツールの特徴でもあります。
最小構成での実行
最も基本的な実行方法は、以下のとおりです。
sudo responder -I eth0-I オプションで、監視対象となるネットワークインターフェースを指定します。無線LANの場合は wlan0、有線LANの場合は eth0 が指定されることが一般的です。
この状態でResponderを起動すると、LLMNR、NBT-NS、mDNS などの名前解決要求を待ち受ける状態になります。特定のホストを狙い撃ちするのではなく、ネットワーク内で自然に発生する通信を受動的に観測・介入するというスタンスです。
よく使われるオプション
実務や検証でよく使われるオプションを組み合わせると、次のようになります。
sudo responder -I eth0 -wFb
主なオプションの意味は以下のとおりです。
-
-w：WPAD（Proxy自動設定）の偽応答を有効化 -
-F：LLMNR/NBT-NS 応答をより積極的に行う -
-b：SMB認証の取得を有効化
これらのオプションを指定することで、認証情報が送信される可能性を高めることができます。ただし、オプションを増やすほどネットワークへの影響も大きくなるため、検証目的や許可範囲を明確にした上で使用する必要があります。
実行中に起きること
Responderを起動した状態でネットワークに接続していると、以下のようなイベントが発生する可能性があります。
-
クライアントが存在しないホスト名を解決しようとする
-
プリンタ探索やファイル共有への自動アクセスが行われる
-
スクリプトやサービスが定期的に通信を試みる
これらの通信に対してResponderが応答すると、クライアント側は正規サーバーに接続したつもりで認証処理を開始します。その結果、Responderのコンソール上に ユーザー名、ドメイン名、NTLMハッシュ などが表示されます。
「何も起きない」場合の意味
Responderを実行しても、すぐに結果が出ないことは珍しくありません。この場合、「ツールが失敗している」と考えるのは早計です。
-
LLMNR / NBT-NS が無効化されている
-
SMB署名が強制されている
-
ネットワーク設計が比較的堅牢
といった可能性も十分に考えられます。つまり、何も取得できないこと自体が、一定の防御が機能している証拠になるケースもあります。
Responderは、攻撃の成否だけで評価するツールではなく、環境の安全性を測るための試金石として捉えるのが適切です。
実行すると何が取得できるのか
Responderを実行して通信が成立すると、コンソール上にはさまざまな情報が表示されます。ただし、表示される内容を正しく理解していないと、リスクを過大評価したり、逆に見逃したりする原因になります。ここでは、取得される情報の種類と、その意味を整理します。
Responderが取得する情報の正体
Responderによって取得される代表的な情報は、以下のとおりです。
-
ユーザー名
-
ドメイン名
-
認証に使用されたプロトコル（SMB / HTTP など）
-
NTLM認証に関連するハッシュ情報
重要なのは、Responderが平文のパスワードを直接取得するわけではないという点です。取得されるのはあくまで、NTLM認証に用いられるハッシュ値やチャレンジ・レスポンス情報です。
NTLMv1 と NTLMv2 の違い
Responderのログでは、NTLMv1 または NTLMv2 といった表記を見ることがあります。両者にはセキュリティ上の大きな差があります。
-
NTLMv1
古い方式であり、計算量的に弱く、現在では使用すべきではないとされています。取得されたハッシュは、比較的短時間でパスワードを特定できる可能性があります。 -
NTLMv2
NTLMv1に比べて強化されており、即座にパスワードが判明するわけではありません。ただし、依然として攻撃の起点になり得る点は変わりません。
NTLMv2が使われているから安全、というわけではなく、そもそも不正な相手に認証情報が送信されているという事実が問題になります。
取得できた＝侵入成功ではない
Responderの出力を初めて見ると、「認証情報が漏洩した」「すでに侵入された」と感じてしまうかもしれません。しかし、ここで一度冷静に整理する必要があります。
Responderが示しているのは、
-
認証要求が発生した
-
不正な応答を遮断できなかった
-
認証プロトコルがネットワーク内で露出している
という事実です。
即座にシステムが突破されたことを意味するわけではありません。
ただし、これらの条件が揃っている環境では、侵入後の攻撃が連鎖的に進みやすくなります。Responderは、その「最初の歪み」を可視化しているに過ぎません。
ログが示す本当の意味
Responderのログで本当に注目すべきなのは、取得されたハッシュそのものよりも、次の点です。
-
どの端末が
-
どのタイミングで
-
どのプロトコルを使って
-
認証を試みたのか
これらは、ネットワークの設計や運用を見直すための重要な材料になります。たとえば、想定外の端末が頻繁に認証を試みている場合や、不要なサービスが動作している場合、それ自体がリスク要因です。
Responderは「盗むためのツール」ではなく、ネットワークが自ら漏らしている情報を観測するツールだと捉える方が、本質に近いでしょう。
攻撃者視点で見たResponder
攻撃者の立場で見ると、Responderは非常に“都合の良い”ツールです。理由は単純で、コストが低く、成功条件が緩く、失敗しても痕跡が目立ちにくいからです。
なぜ初動で使われるのか
侵入テストや実際の攻撃シナリオにおいて、Responderはしばしば初期段階で実行されます。その背景には、次のような事情があります。
-
脆弱性を突く必要がない
-
標的ホストを特定する必要がない
-
成功すれば次の攻撃につながる情報が得られる
つまり、「何も失わずに試せる」ツールなのです。
ネットワークに接続できた時点で実行する価値があり、準備や下調べをほとんど必要としません。
ユーザー操作を必要としない強み
多くの攻撃手法は、ユーザーにメールを開かせる、リンクを踏ませる、ファイルを実行させるといった工程を必要とします。しかしResponderは、ユーザーの意思決定を介在させずに結果が出る可能性があります。
-
プリンタ探索
-
ファイル共有への自動接続
-
サービスやスクリプトの定期通信
こうした「日常的な挙動」がそのまま攻撃成立条件になるため、成功率が環境依存でありながらも決して低くありません。
横展開の起点としての価値
Responder単体で完結する攻撃は多くありませんが、横展開の起点としての価値は非常に高いと言えます。
-
どのユーザーが
-
どの端末から
-
どの認証方式で
通信しているかが分かるだけでも、攻撃者にとっては大きなヒントになります。特に、管理者権限を持つアカウントや、複数端末で使い回されている認証情報が見えた場合、次の手が打ちやすくなります。
「静かに失敗できる」点も重要
Responderが攻撃者に好まれる理由の一つに、失敗しても騒ぎになりにくい点があります。
-
ポートスキャンのように大量の通信を発生させない
-
明確なエラーやクラッシュを引き起こさない
-
ログ上は通常の通信と区別しにくい場合がある
このため、攻撃者は「とりあえず動かして様子を見る」という使い方ができます。成功すれば次に進み、何も起きなければ別の手段に切り替えるだけです。
攻撃者が見ているのは「設計の隙」
攻撃者にとってResponderは、「強引にこじ開ける道具」ではありません。ネットワーク設計の隙間を探すセンサーに近い存在です。
Responderが機能するという事実は、
-
内部通信を信用しすぎている
-
古い前提が残ったまま運用されている
-
防御が境界型に偏っている
といった構造的な問題を示しています。攻撃者はそこを起点に、より深い侵入へと進んでいきます。
防御者視点で見たResponder
Responderは攻撃者にとって有用なツールである一方、防御者にとっては内部ネットワークの設計や運用の甘さを可視化する指標になります。重要なのは、Responderを「止める」こと自体よりも、なぜ成立してしまうのかを理解し、構造的に潰すことです。
技術的対策の基本
Responderが成立する最大の要因は、LLMNRやNBT-NSといった補助的な名前解決プロトコルが有効になっている点にあります。これらは、現代の企業ネットワークでは必須とは言えません。
代表的な技術的対策は以下のとおりです。
-
LLMNRの無効化
グループポリシーを用いて無効化することで、Responderの成立条件を大きく削ぐことができます。 -
NBT-NSの無効化
NetBIOS over TCP/IP を不要な端末では無効にします。 -
SMB署名の強制
SMB通信に署名を必須とすることで、中間者による認証情報取得を困難にします。 -
NTLMの利用制限
NTLMv1の無効化、NTLM自体の利用範囲制限は、Responder後続のリスクを大きく下げます。
これらはいずれも新しい技術ではありませんが、運用負荷や互換性の問題から後回しにされがちな対策でもあります。
運用・監視の観点
技術的にすべてを完全に防ぐことが難しい場合でも、検知できる状態にしておくことは非常に重要です。
防御側が注目すべきポイントには、次のようなものがあります。
-
不審なLLMNR / NBT-NS 応答の増加
-
想定外の端末が名前解決応答を返している
-
SMB認証失敗や再試行の頻発
EDRやIDS/IPS製品の中には、Responder特有の挙動をシグネチャとして検知できるものもあります。重要なのは、「内部だから安全」という前提を置かないことです。
Responderをどう位置づけるべきか
防御者の立場では、Responderを単なる攻撃ツールとして忌避するのではなく、定期的な点検ツールとして活用する考え方も有効です。
-
内部侵入を想定した演習
-
新拠点・新セグメント追加時の健全性確認
-
ADポリシー変更後の影響確認
このような場面でResponderを実行し、「何も起きない」ことを確認できる状態が理想です。
「境界防御だけ」では足りない理由
Responderが成立する環境では、多くの場合、
-
外部境界の防御には力を入れている
-
内部通信は信頼している
という構造が見られます。しかし、内部侵入を前提とした攻撃が一般化した現在、この前提はすでに通用しません。
Responderは、ゼロトラスト的な設計思想の必要性を端的に示すツールとも言えます。内部であっても疑い、検証し、制御する。その発想がなければ、同様の手法は形を変えて繰り返されます。
Responderが使えてしまう環境の問題点
Responderが機能してしまう環境は、「たまたま設定が甘かった」という単純な話では終わりません。多くの場合、ネットワーク設計や運用方針そのものに共通した傾向が存在します。
「昔から動いている」を疑わない設計
LLMNRやNBT-NSが有効なまま残っている環境では、次のような判断が積み重なっているケースが少なくありません。
-
以前から問題なく動いている
-
無効化すると業務影響が出そう
-
どこで使われているか分からない
これらはいずれも現場では理解できる判断ですが、結果として不要になった前提が温存され続けることになります。Responderは、そうした“過去の判断の蓄積”を一気に表面化させます。
内部通信を信頼しすぎている
Responderが成立する最大の前提は、内部ネットワークは安全であるという暗黙の信頼です。
-
内部端末は攻撃者になり得ない
-
内部通信は改ざんされない
-
内部認証は盗聴されない
こうした前提が残っている限り、名前解決や認証プロトコルは最低限の防御しか施されません。しかし実際には、マルウェア感染端末や不正接続機器など、内部に攻撃者が存在する可能性は常にあります。
設計と運用の分断
Responderが有効な環境では、設計と運用が分断されているケースも目立ちます。
-
設計時点では想定されていなかった使われ方
-
運用中に追加された端末やセグメント
-
セキュリティ設定の例外運用の積み重ね
これらが重なると、誰も全体像を把握できない状態になります。その結果、「どこまでが安全で、どこからが危険か」が曖昧になり、Responderのようなツールが容易に成立してしまいます。
Responderは結果ではなく“兆候”
重要なのは、Responderが成功したかどうかそのものではありません。
Responderが使えてしまうこと自体が、すでに兆候であるという点です。
-
内部通信の信頼モデルが古い
-
認証方式の見直しが追いついていない
-
攻撃後の展開を想定していない
こうした構造的な問題は、Responderを塞いだだけでは解決しません。別の手法、別のプロトコル、別のツールによって、同じ本質が再び突かれる可能性があります。
本当に問うべきこと
Responderが示しているのは、「このツールをどう防ぐか」ではなく、
-
なぜ内部でなりすましが成立するのか
-
なぜ認証情報がネットワーク上に露出するのか
-
どこまでを信頼し、どこからを疑うべきか
という、設計思想そのものへの問いです。
この問いに答えられない限り、内部侵入を前提とした攻撃に対して、十分な耐性を持つことは難しいでしょう。
まとめ
Responderは、強力な攻撃ツールであると同時に、内部ネットワークの設計思想を映し出す鏡のような存在です。脆弱性を突くのではなく、プロトコルの仕様と運用上の前提を利用するという点に、このツールの本質があります。
本記事で見てきたとおり、Responderによって取得されるのはパスワードそのものではありません。しかし、認証情報が不正な相手に送信されてしまう環境は、侵入後の横展開や権限昇格に対して脆弱な状態にあります。重要なのは、「何が取れたか」ではなく、「なぜ取れてしまったのか」を理解することです。
Responderが成立するかどうかは、
-
内部ネットワークをどこまで信頼しているか
-
古いプロトコルや前提が残っていないか
-
認証と通信を適切に制御できているか
といった設計・運用の積み重ねの結果です。たとえ今回の検証で何も取得できなかったとしても、それは環境が一定の防御水準に達していることを示す、重要な成果と言えるでしょう。
Responderを単なる「危険なツール」として遠ざけるのではなく、内部侵入を前提とした健全性チェックの手段として捉えることが重要です。定期的な検証を通じて、自組織のネットワークがどの前提の上に成り立っているのかを見直すきっかけにすべきでしょう。
▼ 関連記事（Kali Toolsシリーズ）
▼ 関連記事（blog.b-son.net）
