ラベル Kali Linux の投稿を表示しています。すべての投稿を表示

Kali Tools #015｜Netdiscover：ARPスキャンで内部ネットワークを可視化する偵察ツール

※本記事は学習用途・自己所有環境のみを対象とし、他者環境への無断スキャンは不正アクセス禁止法に該当します。

外部からの侵入を防ぐことに注目が集まりがちだが、実際のインシデント対応では「内部ネットワークがどこまで見えてしまうか」が被害の広がりを大きく左右します。

一度ネットワーク内に侵入されると、攻撃者はまず「誰が同じネットワークに存在しているのか」を把握しようとします。

その初動偵察で使われる代表的なツールが Netdiscover です。

Netdiscoverは、ARP（Address Resolution Protocol）を利用して、同一セグメント内に存在する端末を高速に洗い出すシンプルな偵察ツールです。

特徴的なのは、特別な認証や脆弱性を突かなくても、ネットワーク構成によっては端末一覧が容易に可視化できてしまう点にあります。

これは攻撃者だけでなく、防御側にとっても「内部ネットワークがどのように見えているのか」を理解するうえで重要な示唆を与えます。

本記事では、Netdiscoverの仕組みと役割を整理しつつ、なぜこのような古典的手法が今もなお有効なのか、そして防御側は何を意識すべきかについて解説していきます。

1. Netdiscoverとは何か

Netdiscoverの概要

Netdiscoverは、ARP（Address Resolution Protocol）を利用して、同一ネットワークセグメント内に存在する端末を検出・列挙するための偵察ツールです。
Kali Linuxに標準搭載されており、内部ネットワークにおける初動調査で広く利用されています。

動作は非常にシンプルで、ARPリクエストをブロードキャスト送信し、その応答からIPアドレス・MACアドレス・ベンダー情報などを収集します。
ポートスキャンや脆弱性スキャンのような挙動は伴わず、「誰がそこにいるのか」を把握することに特化しています。

内部ネットワーク偵察における位置づけ

Netdiscoverが使われる場面は、いわゆる「侵入後の初動フェーズ」です。
外部からの侵入に成功した攻撃者は、次に以下のような情報を把握しようとします。

同一セグメントに存在する端末の数
サーバやネットワーク機器の有無
管理対象外と思われる端末の存在

Netdiscoverは、この段階で最小限の操作でネットワーク全体像を可視化できる点が特徴です。
その意味で、Nmapのような詳細調査ツールとは役割が異なり、「地図を描くためのツール」と位置づけることができます。

なぜ今でもNetdiscoverが使われるのか

ARPは古くから存在する基本的なプロトコルであり、多くのネットワーク環境で現在も使用されています。
その設計上、同一セグメント内ではブロードキャスト通信が成立するため、条件が揃えば認証なしで端末情報が取得可能です。

この挙動は脆弱性というよりも仕様に近い性質であり、
ネットワーク分離やアクセス制御が不十分な環境では、今もなお有効な偵察手段となっています。

Netdiscoverが現在も現役で使われている理由は、
「高度な攻撃をしなくても、内部構成が見えてしまう環境が少なくない」という現実を反映していると言えるでしょう。

攻撃・防御の両視点で理解すべきツール

Netdiscoverは攻撃ツールとして語られがちですが、防御側にとっても重要な意味を持ちます。
自組織のネットワークがどのように見えるのかを把握することは、設計や運用上の課題を洗い出す第一歩だからです。

想定外の端末が存在していないか
セグメント分離は適切か
侵入後に一気に可視化される構成になっていないか

Netdiscoverは、そうした点を確認するための「現実を映すツール」として理解する必要があります。

2. Netdiscoverの開発背景と役割

内部ネットワーク偵察という発想

Netdiscoverが想定しているのは、インターネット越しの攻撃ではありません。
あくまで「すでに内部ネットワークに到達している」という前提に立ったツールです。

この前提は、マルウェア感染、VPNアカウントの侵害、持ち込み端末（BYOD）など、現実のインシデントでは珍しいものではありません。
一度内部に足場ができると、次に問題となるのは内部構成がどこまで見えてしまうかです。

Netdiscoverは、この「侵入後に何が分かってしまうのか」を可視化する目的で生まれたツールと言えます。

ARPを利用するという割り切り

Netdiscoverの最大の特徴は、ARPという非常に基本的な仕組みに完全に依存している点にあります。
ARPは、同一ネットワーク内でIPアドレスとMACアドレスを対応付けるために不可欠なプロトコルであり、多くの環境で常時使用されています。

この仕組みを利用することで、Netdiscoverは以下のような「割り切り」を実現しています。

認証情報を必要としない
ポートスキャンやエクスプロイトを行わない
通信量が比較的少ない

結果として、低コストかつ高速にネットワーク全体像を把握することが可能になります。

Nmapとの役割の違い

同じ偵察ツールとしてNmapが挙げられることがありますが、両者の役割は明確に異なります。

Netdiscover：
同一セグメント内に「誰が存在しているか」を把握するためのツール
Nmap：
対象ホストに対して「どのサービスが動いているか」を調査するツール

NetdiscoverはL2（データリンク層）寄り、NmapはL3／L4以上を扱うことが多く、
Netdiscoverは調査の出発点、Nmapは詳細調査という関係になります。

なぜ現在でも価値があるのか

ネットワーク技術は進化していますが、すべての環境が最新の設計・運用になっているわけではありません。
特に以下のような環境では、Netdiscoverの有効性は今も高いままです。

セグメント分離が甘い社内LAN
一時的に構築された検証・開発環境
OT／IoT機器を含む混在ネットワーク

これらの環境では、「同一ネットワークにいる」というだけで情報が露出するケースが少なくありません。

攻撃者と防御者、双方にとっての意味

Netdiscoverは、攻撃者にとっては最短距離で地図を得る手段です。
一方、防御者にとっては、内部ネットワーク設計の甘さを突きつける鏡でもあります。

「外部から守っているから安全」という考え方は、内部偵察という視点を欠いたものです。
Netdiscoverが示すのは、侵入後の世界がどれだけ無防備になり得るかという現実です。

3. ARPスキャンの仕組みを簡単に理解する

ARPとは何か

ARP（Address Resolution Protocol）は、IPアドレスとMACアドレスを結び付けるための基本的な仕組みです。
同一ネットワーク内で通信を行う際、相手のIPアドレスは分かっていても、実際に通信を行うにはMACアドレスを知る必要があります。

その対応関係を解決するために使われるのがARPであり、LAN環境では日常的に利用されています。
この仕組み自体は、ネットワークが正常に動作するために欠かせないものです。

ブロードキャスト通信という前提

ARPの特徴的な点は、ブロードキャスト通信を前提としていることです。
ARPリクエストは「このIPアドレスを持っている端末は誰か？」という問いかけを、同一セグメント内の全端末に送信します。

この問いかけに対し、該当する端末がARPリプライを返すことで通信相手が特定されます。
重要なのは、このやり取りが同一セグメント内の全端末に見えているという点です。

なぜ端末一覧が取得できてしまうのか

Netdiscoverは、このARPの仕組みをそのまま利用しています。
特定のIP範囲に対してARPリクエストを送信することで、応答してきた端末を一覧として収集します。

ここで行われているのは、脆弱性の悪用ではありません。
ARPという仕様に従った正規の通信だけで、以下の情報が取得可能になります。

IPアドレス
MACアドレス
ネットワーク機器のベンダー情報

そのため、条件が揃えば特別な権限がなくても、ネットワーク全体像が可視化されてしまいます。

「同一セグメントにいる」という意味

ARPスキャンが成立するかどうかは、「同一セグメントに存在しているか」に大きく依存します。
ルータやVLANで分離された別セグメントには、ARPブロードキャストは届きません。

逆に言えば、内部ネットワークの分離が不十分な場合、
「内部にいるだけで見えてしまう」範囲が想定以上に広がることになります。

これは設計や運用の問題であり、Netdiscoverはその結果を可視化しているに過ぎません。

ARPスキャンが示す現実

ARPスキャンは古典的な手法ですが、現在でも多くの環境で成立します。
それは、利便性と管理コストの都合から、内部ネットワークがフラットなまま運用されているケースが少なくないためです。

Netdiscoverは、こうした環境において
「侵入後、最初に何が見えるのか」
を極めて分かりやすく示すツールだと言えるでしょう。

4. Netdiscoverで何が分かるのか

検出される主な情報

Netdiscoverを実行すると、同一ネットワークセグメント内に存在する端末の情報が一覧として表示されます。
取得できる情報は一見すると限定的ですが、初動偵察としては十分な内容です。

主に以下のような情報が確認できます。

IPアドレス
MACアドレス
MACアドレスから推定されるベンダー情報

これらはいずれもARP通信から得られる情報であり、特別な権限や認証を必要としません。

一覧化されることの意味

個々の情報は断片的に見えるかもしれませんが、「一覧として可視化される」ことに大きな意味があります。
Netdiscoverの出力を見ることで、ネットワークの規模や構成の傾向が一目で把握できます。

たとえば以下のような点が読み取れます。

想定していたより端末数が多い
サーバと思われる常時稼働端末の存在
特定のベンダー機器が集中している

これらは次の調査や攻撃対象の選定に直結する情報です。

管理されていない端末・想定外端末の発見

Netdiscoverは、管理者が把握していない端末を浮き彫りにすることがあります。
私物端末、検証用に一時的に接続された機器、古いネットワーク機器などがその典型例です。

こうした端末は、以下の理由からリスクになりやすい傾向があります。

セキュリティパッチが適用されていない
監視やログ取得の対象外
管理責任が曖昧

攻撃者にとっては、こうした端末が次の足がかりになり得ます。

他ツールとの組み合わせで広がる情報

Netdiscover単体で取得できる情報は限定的ですが、他のツールと組み合わせることで価値が高まります。

Netdiscoverで端末一覧を取得
Nmapで特定端末を詳細調査
ResponderやSMB系ツールにつなげる

このように、Netdiscoverは調査チェーンの起点として機能します。

防御側から見た「分かってしまうこと」

防御側の視点で見ると、Netdiscoverの結果は
「どこまでが侵入後に即座に把握されるのか」を示す指標になります。

内部ネットワークがどこまでフラットか
端末管理がどの程度徹底されているか
想定外の機器が存在しないか

これらを把握するための自己診断ツールとしても、Netdiscoverは有効です。

5. Netdiscoverの代表的な使いどころ

内部ネットワーク侵入後の初動偵察

Netdiscoverが最も典型的に使われるのは、内部ネットワークへの侵入直後です。
この段階では、詳細な調査を行う前に、まず全体像を把握することが優先されます。

Netdiscoverを使うことで、短時間で以下の情報が得られます。

同一セグメントに存在する端末数
サーバやネットワーク機器と思われる端末
常時稼働している可能性の高いホスト

これにより、次にどこを調査すべきか、どの端末が優先対象になるかの判断材料が揃います。

Responder実行前の下準備

Netdiscoverは、Responderのような内部攻撃ツールを使用する前段階でも有効です。
Responderは同一ネットワーク上の端末が存在して初めて成立するため、事前に環境を把握しておく必要があります。

Netdiscoverで端末の存在や規模を把握しておくことで、

攻撃が成立し得る環境かどうか
想定より対象が少ない／多いか
不要な実行を避ける判断

といった事前判断が可能になります。

管理者視点でのネットワーク可視化

Netdiscoverは攻撃用途だけでなく、防御側・管理者側の視点でも利用価値があります。
特に以下のような場面で有効です。

端末棚卸しが十分に行われていない環境
一時的な端末接続が発生しやすい職場
検証・開発用途のネットワーク

「意図せず見えてしまうもの」を確認することで、設計や運用上の問題点が浮き彫りになります。

インシデント対応時の状況把握

インシデント対応の初期段階では、影響範囲の特定が重要になります。
Netdiscoverを用いることで、該当セグメントにどの程度の端末が存在するかを迅速に把握できます。

これは、対応優先度の判断や、追加調査範囲の決定に役立ちます。

教育・検証環境での理解促進

Netdiscoverは挙動が分かりやすいため、教育用途にも適しています。
ARPや内部ネットワークの仕組みを、実際の通信結果とともに確認できる点が特徴です。

セキュリティ研修や検証環境で使用することで、

内部ネットワークの「見え方」
設計次第でリスクが変わること

を直感的に理解させることができます。

6. 攻撃者視点：なぜNetdiscoverは危険なのか

認証なしで全体像が把握できる

Netdiscoverの最大の危険性は、認証や脆弱性悪用を必要としない点にあります。
内部ネットワークに接続できさえすれば、ARPの仕様に従った通信だけで端末一覧が取得できます。

これは攻撃者にとって非常に都合が良く、侵入直後から次のような判断が可能になります。

このネットワークは広いのか、狭いのか
調査・攻撃対象になり得る端末はどれか
想定以上にフラットな構成になっていないか

侵入の成功・失敗を左右する初期判断が、ほぼ無条件で行えてしまいます。

攻撃対象の優先順位を即座に決められる

Netdiscoverの出力は、次の行動を決めるための材料になります。
特に、以下のような端末は攻撃者の関心を引きやすくなります。

常時応答している端末
ネットワーク機器やサーバと思われるベンダー
数が少なく目立つ端末

これにより、無差別な探索ではなく、効率の良い攻撃ルート選定が可能になります。

侵入の深さが露呈する

Netdiscoverの結果を見ることで、攻撃者は
「どこまで内部に入り込めているのか」
を客観的に把握できます。

もし想定より多くの端末が見えている場合、それはネットワーク分離が不十分である可能性を示します。
逆に、ほとんど見えない場合は、別の侵入経路やセグメント移動を検討する判断材料になります。

いずれにしても、Netdiscoverは侵入の成否を測る指標として機能します。

検知されにくい初動行為

ARPスキャンは、多くの環境で日常的に発生する通信と区別がつきにくい傾向があります。
そのため、以下のような状況が起こり得ます。

ログに残らない、もしくは見逃される
IDS／IPSの検知対象になりにくい
管理者に違和感を与えない

攻撃者にとっては、目立たずに環境を把握できる点が大きな利点です。

次の攻撃フェーズへの足がかりになる

Netdiscover自体は、情報を「見る」だけのツールです。
しかし、その結果は次のフェーズに直結します。

Responderによる認証情報取得
Nmapによる詳細スキャン
SMB／AD系ツールによる横展開

つまり、Netdiscoverは単体で危険なのではなく、
攻撃チェーンの起点として機能することが問題なのです。

単純さゆえの危険性

Netdiscoverは高度な操作を必要としません。
この単純さは、熟練した攻撃者だけでなく、経験の浅い攻撃者でも容易に扱えることを意味します。

結果として、
「内部に入られた時点で、誰でも同じように全体像を把握できてしまう」
というリスクが生じます。

7. 防御者視点：Netdiscoverを前提にした対策

「見えない前提」を捨てる

Netdiscoverが成立する環境では、
「内部ネットワークは外部から見えない」
という前提がすでに崩れています。

防御側がまず認識すべきなのは、侵入後は一定範囲が必ず可視化されるという事実です。
そのうえで、どこまで見えても問題ない設計・運用になっているかを考える必要があります。

ネットワーク分離の徹底

ARPスキャンは同一セグメント内でしか成立しません。
そのため、セグメント分離は最も基本的かつ効果的な対策です。

具体的には以下が挙げられます。

利用者端末とサーバの分離
業務系と検証・開発系の分離
IoT機器やネットワーク機器の隔離

「同一セグメントに置かない」こと自体が、Netdiscoverの有効範囲を大きく制限します。

NAC・接続制御の重要性

Netdiscoverが機能する前提は、「内部ネットワークに接続できること」です。
NAC（Network Access Control）や802.1Xなどを導入することで、
未認証端末の接続自体を制限できます。

これにより、

私物端末の無断接続
不正持ち込み機器
侵害済み端末の拡散

といったリスクを抑えることが可能になります。

ARP通信の監視と可視化

ARP通信は見落とされがちですが、監視対象に含めることで異常の兆候を捉えられる場合があります。

短時間に大量のARPリクエストが発生していないか
通常と異なる送信元からのARP通信
不審なMACアドレスの出現

完全な防止は難しくても、「気付ける状態」にしておくことは重要です。

端末管理と棚卸しの継続

Netdiscoverで発見される未管理端末は、設計だけでなく運用の問題を反映しています。
定期的な棚卸しと台帳管理を行うことで、
「見えてはいけない端末」が存在しない状態を維持することが重要です。

「侵入後」を想定した設計思想

Netdiscover対策の本質は、ツールを封じることではありません。
侵入を前提にした設計と運用に切り替えることです。

見られても致命的でない構成か
初動で被害拡大を抑えられるか
次の攻撃フェーズに進ませない仕組みがあるか

Netdiscoverは、その設計思想が問われていることを示すツールだと言えます。

8. Responderとの関係性

NetdiscoverとResponderの役割の違い

NetdiscoverとResponderは、どちらも内部ネットワークで使われるツールですが、役割は明確に異なります。

Netdiscover：
同一セグメント内に「誰が存在しているか」を把握するための偵察ツール
Responder：
名前解決の挙動を悪用し、認証情報の取得を狙う攻撃ツール

Netdiscoverは「見る」ためのツールであり、Responderは「奪う」ためのツールと言えます。

攻撃チェーンとしてのつながり

実際の攻撃では、これらのツールが単独で使われることは多くありません。
Netdiscoverによって内部ネットワークの全体像を把握したうえで、Responderの実行可否を判断する流れが一般的です。

Netdiscoverで端末数・規模を把握
対象が存在することを確認
Responderで名前解決通信を待ち受ける

この順序により、無駄な実行や検知リスクを下げつつ攻撃が成立します。

なぜセットで理解すべきなのか

Netdiscover単体では直接的な被害は発生しません。
しかし、Responderと組み合わさることで、情報取得から侵害へとフェーズが進みます。

この点を理解せずに
「Netdiscoverは危険だがResponderが問題」
と切り分けて考えると、本質を見誤ります。

重要なのは、内部ネットワークが“見える”設計になっていること自体が、Responderの成立条件を満たしているという点です。

防御側が見るべきポイント

防御側の視点では、NetdiscoverとResponderは切り離せない関係にあります。

Netdiscoverが成立する環境か
LLMNR／NBT-NSが有効になっていないか
名前解決が不要にブロードキャストに依存していないか

これらをセットで見直すことで、攻撃チェーン全体を断ち切ることが可能になります。

9. まとめ：Netdiscoverが示す内部ネットワークの現実

Netdiscoverは、高度な攻撃を行うツールではありません。
ARPという基本的な仕組みを利用し、同一ネットワーク内に「誰が存在しているか」を可視化するだけの、非常にシンプルなツールです。

しかし、そのシンプルさこそが、内部ネットワークの現実を浮き彫りにします。
特別な脆弱性を突かなくても、内部に入りさえすれば全体像が把握できてしまう環境は、決して少なくありません。

本記事で見てきたように、Netdiscoverが示すのはツールの危険性そのものではなく、
内部ネットワーク設計や運用に潜む前提の甘さです。

内部は安全だという思い込み
フラットなネットワーク構成
未管理端末の放置

こうした要素が重なることで、侵入後の被害拡大が容易になります。

防御側に求められるのは、Netdiscoverの使用を想定し、
「見られても問題のない構成になっているか」
「侵入後の動きをどこで止められるか」
を常に問い続けることです。

Netdiscoverは、その問いを突きつけるためのツールだと言えるでしょう。

▼ 関連記事（Kali Toolsシリーズ）

Kali Tools #014｜Responder：内部ネットワークで認証情報を引き出す定番ツール

※本記事は学習用途・自己所有環境のみを対象とし、他者環境への無断スキャンは不正アクセス禁止法に該当します。

サイバー攻撃というと、インターネットに公開された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）

Kali Tools #013｜Gobuster：ディレクトリ・DNS・VHostを高速探索する定番ツール

※本記事は学習用途・自己所有環境のみを対象とし、他者環境への無断スキャンは不正アクセス禁止法に該当します。

Kali Linuxに含まれるツールの多くは、「攻撃用」「解析用」といった単純なラベルでは語れません。重要なのは、それぞれのツールがどのフェーズで、何を明らかにするために使われるのかです。

Gobusterは、その中でも「探索（列挙）」という地味だが極めて重要な役割を担うツールです。Webサイトやサーバは、見えているものだけで構成されているとは限りません。公開設定の漏れや使われていないはずのディレクトリ、想定外の仮想ホストなどは、表からは確認できないまま残っていることが多くあります。

Gobusterは、そうした「見えていないリソース」を高速に洗い出すためのツールです。攻撃者にとっては侵入口を探すための手段であり、防御側にとっては自分たちの公開範囲を確認するためのチェック手段でもあります。

本記事では、Gobusterがどのような思想で作られ、Kali Linuxの中でどのような位置づけにあるツールなのかを整理しながら、その本質的な役割を解説していきます。

Gobusterとは何か

Gobusterは、WebサーバやDNSに対して既知の単語リスト（ワードリスト）を用いたブルートフォース型の探索を行うツールです。主な目的は、ディレクトリやファイル、サブドメイン、仮想ホストといった「表からは見えないリソース」を洗い出すことにあります。

Webサイトは、トップページやリンクで辿れる範囲だけが全てではありません。管理用ディレクトリ、過去に使われていたファイル、設定ミスにより残されたバックアップなどが、意図せず公開されたままになっているケースは少なくありません。Gobusterは、そうしたリソースの存在を機械的かつ高速に列挙するために使われます。

Gobusterの特徴は、その割り切った設計にあります。脆弱性を直接突くツールではなく、「何が存在しているか」を淡々と確認することに特化しています。そのため、結果として得られるのは侵入そのものではなく、次の判断に使うための材料です。この点で、Gobusterは偵察フェーズに位置づけられるツールだと言えます。

また、GobusterはGo言語で実装されており、高速な並列処理が可能です。大量のリクエストを短時間で投げることができるため、対象が限定されている状況では非常に効率よく探索を進められます。一方で、探索結果の質はワードリストに大きく依存するため、「何を探したいのか」を意識した使い方が求められます。

Gobusterは攻撃者専用のツールではありません。防御側が自組織のWeb資産を棚卸しし、想定外に公開されているリソースがないかを確認する用途でも有効です。攻撃と防御の境界ではなく、「見える状態にするためのツール」として理解することが、Gobusterを正しく使うための第一歩と言えるでしょう。

Gobusterの歴史と開発背景

Gobusterは、WebアプリケーションやDNSの偵察フェーズを効率化する目的で開発されたツールです。登場当初から一貫して重視されてきたのは、「余計な機能を持たず、列挙処理を高速に行う」という設計思想でした。

従来、ディレクトリ探索やサブドメイン列挙には、複数のツールやスクリプトを使い分ける必要があり、処理速度や安定性に課題がありました。Gobusterはそうした課題を解消するため、Go言語を採用し、並列処理を前提とした軽量な構造で実装されています。この選択により、環境差による動作不安定さが少なく、高速かつ再現性の高い探索が可能になりました。

また、Gobusterは単なる「ディレクトリ総当たりツール」として設計されたわけではありません。開発の過程で、DNSサブドメイン探索や仮想ホスト探索といった機能が追加され、「名前を列挙して存在を確認する」という共通概念のもとに整理されてきました。この結果、現在のGobusterは、探索対象は異なっても同じ操作感で使えるツールへと進化しています。

セキュリティツールの世界では、新しいツールが次々に登場する一方で、使われなくなるものも少なくありません。その中でGobusterが長く定番として残っている理由は、流行りの技法に寄せすぎず、偵察という普遍的な工程に焦点を当て続けてきた点にあります。

Gobusterは「何かを突破するためのツール」ではなく、「状況を把握するためのツール」として成熟してきました。この背景を理解しておくことで、Gobusterをどのタイミングで、どの程度使うべきかが見えてきます。

Kali LinuxにおけるGobusterの位置づけ

Kali Linuxには数多くのセキュリティツールが収録されていますが、Gobusterはその中でも偵察（Reconnaissance）フェーズに特化した列挙系ツールとして位置づけられます。対象システムに対していきなり攻撃を仕掛けるのではなく、「何が存在しているのか」を事前に把握するための役割を担います。

Kali Linuxの典型的な作業フローでは、まずNmapなどでネットワークやポートの全体像を把握し、その後にWebサービスが確認できた段階でGobusterの出番となります。Gobusterは、ポートスキャンの結果を受けて、Web層をもう一段深く掘り下げるためのツールだと言えます。

また、GobusterはWhatWebやWappalyzerのような「技術スタックを識別するツール」とも役割が異なります。これらが「何で作られているか」を調べるのに対し、Gobusterは「どこまで公開されているか」を調べます。技術情報ではなく、リソースの存在そのものに焦点を当てている点が特徴です。

Kali Linuxに標準搭載されている理由も明確です。Gobusterは設定がシンプルで、実行結果が分かりやすく、再現性が高いという特性を持っています。そのため、演習環境から実務に近い検証まで、幅広い場面で扱いやすいツールとなっています。

Gobusterは単体で完結するツールではありません。他の偵察・解析ツールと組み合わせることで真価を発揮します。Kali LinuxにおけるGobusterの位置づけを理解することは、ツール単体の使い方以上に、全体の作業設計を考える上で重要な視点となります。

Gobusterでできること（機能別整理）

Gobusterは、探索対象ごとにモードが分かれており、「名前を列挙して存在を確認する」という共通の仕組みを、異なる対象に適用できるよう設計されています。ここでは代表的な機能を整理します。

まず、最も利用されるのがディレクトリ／ファイル探索（dir）です。Webサーバに対してワードリストを用い、存在するディレクトリやファイルを列挙します。管理画面、バックアップファイル、開発中に使われていたパスなど、リンクされていないリソースを発見する用途で使われます。

次に、DNSサブドメイン探索（dns）があります。これは、www や admin といった一般的なサブドメイン名を総当たりし、名前解決できるものを洗い出す機能です。Webアプリだけでなく、API用や社内向けに用意されたサブドメインの存在を把握する際に有効です。

さらに、VHost探索（vhost）もGobusterの重要な機能です。同一IPアドレス上で複数の仮想ホストが動作している場合、ホスト名を切り替えてリクエストを送り、応答の差異から有効なVHostを特定します。DNSに登録されていないが、Webサーバ上では有効なホストを見つけられる点が特徴です。

これらの機能に共通するのは、Gobusterが「中身を解析する」ツールではないという点です。レスポンスの有無やステータスコードといった表層的な情報を高速に収集し、次の判断につなげるための材料を集めることに徹しています。

Gobusterは万能ツールではありませんが、探索対象を明確にした上で使えば、短時間で状況を整理できる強力な補助ツールとなります。機能ごとの役割を理解して使い分けることが、効率的な偵察につながります。

Gobusterが「高速」な理由

Gobusterが定番ツールとして評価されている最大の理由の一つが、その処理速度です。同じ目的を持つ探索系ツールと比較しても、Gobusterは短時間で結果を出せる場面が多く、実務でも扱いやすい特性を持っています。

この高速性を支えているのが、Go言語による実装です。Gobusterは最初から並列処理を前提に設計されており、多数のリクエストを同時に投げることができます。これにより、ワードリストが大きい場合でも、探索にかかる時間を大きく短縮できます。

また、Gobusterは機能を絞り込んだ設計になっています。レスポンスの詳細解析やコンテンツの検査といった処理は行わず、「存在するかどうか」という一点に集中します。この割り切りによって、処理のオーバーヘッドが抑えられ、安定した速度が維持されます。

設定項目が比較的シンプルである点も、間接的に速度に寄与しています。不要なオプションを試行錯誤する必要がなく、目的に応じた最低限の設定で実行できるため、ツールの扱いに慣れていなくても効率よく使えます。

ただし、高速であるがゆえに注意すべき点もあります。短時間に大量のリクエストを送信するため、対象環境によっては負荷やログの増加が顕著になります。Gobusterの速度は強みである一方、使う側に配慮と設計判断を求める性能でもあることを理解しておく必要があります。

攻撃にも防御にも使われる理由

Gobusterはしばしば「攻撃ツール」として紹介されますが、その本質は攻撃そのものではなく、情報を可視化するための列挙ツールです。この性質が、攻撃側・防御側のどちらの立場でも利用される理由になっています。

攻撃者の視点では、Gobusterは侵入の足がかりを探すための手段です。公開されているはずのないディレクトリや管理画面、想定外のサブドメインやVHostを見つけることで、次の行動につながる情報を得ることができます。ただし、Gobuster自体が何かを破壊したり、脆弱性を突いたりするわけではありません。

一方、防御側にとってGobusterは、自分たちが何を公開してしまっているのかを確認するためのチェックツールになります。設定変更やシステム更改の後に実行することで、不要なリソースが残っていないか、意図しない公開範囲が広がっていないかを確認できます。外部からどう見えるかを擬似的に再現できる点が重要です。

このように、Gobusterは「攻撃用」「防御用」と単純に分類できるツールではありません。使う目的と文脈によって、その意味合いが変わります。重要なのは、ツールの存在ではなく、どう使い、どう結果を解釈するかです。

Gobusterを理解することは、攻撃手法を学ぶことと同時に、防御の視点を鍛えることにもつながります。攻撃と防御の境界に立つツールだからこそ、Kali Linuxに標準で含まれていると言えるでしょう。

実行例（基本）

Gobusterはコマンドラインから直感的に実行でき、機能ごとにモードを切り替えて利用します。ここでは、代表的な機能について、基本的な実行例とオプションの意味を整理します。

ディレクトリ／ファイル探索（dir）

Webサーバ上に存在するディレクトリやファイルを列挙する、最も基本的な使い方です。

gobuster dir -u http://example.com -w wordlist.txt -t 10 -x php,html -o results.txt

この例では、-u オプションで探索対象のURLを指定し、-w オプションで使用するワードリストを指定しています。
-t はスレッド数を指定するオプションで、ここでは10並列でリクエストを送信します。
-x では探索対象とする拡張子を指定しており、.php や .html といったファイルの存在も確認します。
最後に、-o オプションで探索結果をファイルに保存しています。

ディレクトリ探索では、管理画面やバックアップ、開発用パスなどが見つかることがあります。結果の数よりも、用途が推測できるパスが含まれているかに注目することが重要です。

DNSサブドメイン探索（dns）

ドメイン配下のサブドメインを総当たりで確認する場合は、dnsモードを使用します。

gobuster dns -d example.com -w subdomains.txt -t 20 -o dns_results.txt

-d で対象ドメインを指定し、-w でサブドメイン用のワードリストを指定します。
ディレクトリ探索と同様に、-t で並列数を調整し、結果は -o でファイルに保存しています。

この探索により、Webサイトとして公開されていないAPI用や管理用のサブドメインが見つかることがあります。防御側の視点では、把握できていなかった公開点の確認として有効です。

VHost探索（vhost）

同一IPアドレス上で稼働している仮想ホストを調べる場合は、vhostモードを使用します。

gobuster vhost -u http://192.0.2.1 -w vhosts.txt -o vhost_results.txt

この例では、IPアドレスを直接指定し、Host ヘッダを切り替えながらリクエストを送信します。
DNSに登録されていないが、Webサーバ上では有効な仮想ホストが存在する場合、ここで検出されます。

VHost探索は、検証環境や内部向けに用意されたWebサイトがそのまま残っているケースを発見しやすく、設定管理の確認という観点でも重要な機能です。

Gobusterの実行例から分かる通り、操作自体は非常に単純ですが、結果の解釈には文脈が必要です。

Gobusterは「答えを出すツール」ではなく、判断材料を揃えるためのツールであることを意識して使う必要があります。

Gobuster利用時の注意点

Gobusterは非常に高速で扱いやすいツールですが、その特性ゆえに注意すべき点もいくつか存在します。結果を正しく解釈し、意図しないトラブルを避けるためにも、事前に理解しておくことが重要です。

まず注意すべきなのは、負荷とログへの影響です。Gobusterは短時間に大量のリクエストを送信するため、対象サーバに一定の負荷を与えます。また、WebサーバやWAF、IDS/IPSのログには明確に痕跡が残ります。検証環境や許可された範囲で実行することを前提とし、本番環境では実行タイミングやスレッド数に配慮が必要です。

次に、結果の過信は禁物という点です。Gobusterで検出されたパスやホストが、必ずしも脆弱性やリスクを意味するわけではありません。認証が適切にかかっている場合や、実害のない静的リソースであるケースも多くあります。検出結果はあくまで「存在確認」であり、評価や判断は別工程になります。

ワードリスト依存のツールであることも重要なポイントです。Gobusterは、指定したワードリストに含まれない名称を見つけることはできません。そのため、結果が出なかった場合でも「何も存在しない」と断定することはできず、ワードリストの選定次第で結果が大きく変わることを理解しておく必要があります。

また、環境によっては誤検知が発生することもあります。すべてのリクエストに対して同じレスポンスを返す設定や、カスタムエラーページを使用している場合、存在しないパスが「存在するように見える」ことがあります。ステータスコードやレスポンスサイズなどを併せて確認し、冷静に見極める姿勢が求められます。

Gobusterは便利で強力なツールですが、「速いからとりあえず回す」という使い方は危険です。目的、対象、影響範囲を整理した上で実行することが、Gobusterを正しく、安全に使うための前提条件となります。

どんな場面で使うべきツールか

Gobusterは、すべての状況で使う万能ツールではありません。強みがはっきりしているからこそ、使うべき場面と使わない判断を明確にすることが重要です。

まず、Gobusterが最も力を発揮するのは、対象がある程度絞り込めている状況です。Nmapなどでポートやサービスの存在が確認でき、Webサービスが稼働していることが分かった段階で使うと、探索の効率が大きく高まります。闇雲に広範囲を探す用途には向いていません。

次に、公開範囲の棚卸しを行いたい場面でも有効です。システム更改後や設定変更後に、想定外のディレクトリやサブドメインが露出していないかを確認する用途では、防御側のツールとして非常に有用です。外部からどう見えるかを確認できる点が大きな価値になります。

一方で、Gobusterが向いていない場面もあります。アプリケーションの内部ロジックを理解したい場合や、入力値の検証、認証・認可の不備を調べたい場合には、別のツールや手作業が必要になります。Gobusterは「入口を探す」ツールであり、「中身を分析する」ツールではありません。

また、時間や負荷に制約がある環境では、無条件に実行すべきではありません。探索対象やワードリストを絞らずに実行すると、不要なノイズを増やすだけでなく、関係者に誤解を与える可能性もあります。

Gobusterは、偵察フェーズにおいて「何を次に調べるべきか」を判断するためのツールです。使うタイミングと目的を誤らなければ、少ない労力で大きな示唆を与えてくれる、非常にコストパフォーマンスの高いツールと言えるでしょう。

まとめ

Gobusterは、WebアプリケーションやDNSに対して「何が存在しているのか」を高速に洗い出すことに特化した、偵察フェーズの代表的なツールです。脆弱性を直接突くのではなく、次の判断に必要な材料を揃えるという点に、その本質的な価値があります。

Go言語による軽量かつ高速な実装、機能を絞り込んだ設計、そしてシンプルな操作性により、Gobusterは現在でも多くの現場で使われ続けています。一方で、その結果はワードリストや実行条件に強く依存するため、出力された情報をどう解釈し、どう活用するかは使い手に委ねられます。

Gobusterは攻撃者だけのツールではありません。防御側が自らの公開範囲を把握し、設定ミスや想定外の露出を確認するためのチェックツールとしても有効です。攻撃と防御の境界に立つツールだからこそ、Kali Linuxに標準で含まれていると言えるでしょう。

重要なのは、Gobusterを単体で完結させないことです。他の偵察・解析ツールと組み合わせ、全体の流れの中で使うことで、初めてその真価が発揮されます。Gobusterは「速く、広く、淡々と確認する」ための道具であり、その役割を正しく理解することが、効果的なセキュリティ検証への第一歩となります。

▼ 関連記事（Kali Toolsシリーズ）

▼ 関連記事（blog.b-son.net）

Kali Tools #012｜Nmap：ネットワーク探索とポートスキャンの基本ツール

※本記事は学習用途・自己所有環境のみを対象とし、他者環境への無断スキャンは不正アクセス禁止法に該当します。

ネットワーク診断や脆弱性調査を行う上で、最も基礎となるのが「Nmap（Network Mapper）」です。

ポートスキャン、サービス検出、OS推定など、攻撃者も防御者も必ず使う定番ツールで、Kali Linuxに標準搭載されています。

この記事では、Nmapの基本的な使い方と代表的なスキャン手法を、初学者にも分かりやすく解説します。

Nmapとは何か

歴史

Nmap（Network Mapper）は、1997年に Gordon Lyon（通称 Fyodor）氏によって公開されたネットワークスキャナです。登場当初から UNIX 系システム管理者やセキュリティ専門家に支持され、のちに Windows や macOS 版も整備されることで一気に普及しました。Nmap はオープンソースとして活発に開発が続けられ、現在では世界中の企業・研究機関・教育機関で日常的に使われる“事実上の標準ツール”となっています。

Kali Linuxでの位置づけ

Kali Linux は情報セキュリティ向けディストリビューションとして、多数の調査・攻撃ツールを標準搭載しています。その中で Nmap は情報収集フェーズを支える基盤ツールとして扱われています。

ポートスキャン、サービス検出、OS推定といった機能は、多くの高度ツール（Metasploit、OpenVAS、Nessus など）の前段階として不可欠であり、Kali Linux の利用者はほぼ例外なく Nmap を使用します。

その意味で Nmap は「Kali の基本操作を習得する上で最初に理解すべき重要ツール」と言ってよい存在となっています。

防御／攻撃どちらにも使われる理由

Nmap が攻撃者にも防御者にも利用されるのは、「ネットワークの実態を正確に把握できる」という中立的な機能を持つためです。

防御側（ブルーチーム）

　・不要なサービスや危険なポートの洗い出し

　・構成情報の棚卸し

　・脆弱なバージョンの発見

攻撃側（レッドチーム／ペンテスター）

　・侵入可能な入口（attack surface）の特定

　・公開サービスの種類とバージョン確認

　・後続の攻撃に使える情報の収集

どちらも「対象ネットワークの地図を描き、弱点を把握する」という目的であり、Nmap はそのための事前偵察の中心ツールとして活用されています。

Nmapの特徴

フレキシブル：IPフィルタ、ファイアウォール、ルータなどの障害物で満たされたネットワークをマッピングするための何十もの高度な技術をサポートします。これには、多くのポートスキャンメカニズム（TCPとUDPの両方）、OS検出、バージョン検出、Pingスイープなどが含まれます。ドキュメントのページをご覧ください。
パワフル：Nmapは、文字通り何十万台ものマシンからなる巨大なネットワークのスキャンに使われてきた。
ポータブル：Linux、Microsoft Windows、FreeBSD、OpenBSD、Solaris、IRIX、Mac OS X、HP-UX、NetBSD、Sun OS、Amigaなど、ほとんどのOSに対応している。
簡単：Nmapはパワーユーザ向けの高度な機能を豊富に備えているが、最初は「nmap -v -A targethost」程度の簡単な操作で始められる。従来のコマンドライン版とグラフィカル(GUI)版の両方が用意されているので、好みに応じて使い分けることができる。Nmapをソースからコンパイルしたくない人のために、バイナリも用意されている。
フリー：Nmapプロジェクトの主な目標は、インターネットの安全性を少しでも高めること、および管理者／監査人／ハッカーにネットワークを調査するための高度なツールを提供することである。Nmapは無料でダウンロードでき、完全なソースコードも付属しているので、ライセンスの条件に従って変更したり再配布したりすることができる。
ドキュメントが充実：包括的で最新のマニュアルページ、ホワイトペーパー、チュートリアル、さらには書籍に至るまで、多大な努力が払われている。複数の言語で提供されていますので、ぜひご覧ください。
サポート：Nmapには保証がついていないが、開発者とユーザの活気あるコミュニティによって十分にサポートされている。サポートのほとんどは、Nmapのメーリングリストで行われている。ほとんどのバグレポートや質問は、nmap-devメーリングリストに送るべきですが、ガイドラインを読んだ後にしてください。すべてのユーザーには、トラフィックの少ないnmap-hackersアナウンスメントリストを購読することをお勧めします。また、NmapはFacebookやTwitterでもご覧いただけます。リアルタイムのチャットは、FreenodeまたはEFNetの#nmapチャンネルに参加してください。
賞を受賞：Nmapは、Linux Journal、Info World、Codetalker Digestの「Information Security Product of the Year」など、数多くの賞を受賞している。また、何百もの雑誌記事、いくつかの映画、何十冊もの書籍、1つのコミックシリーズでも紹介されている。詳細はプレスページをご覧ください。
人気がある：毎日、何千人もの人々がNmapをダウンロードしており、多くのオペレーティングシステム（Redhat Linux、Debian Linux、Gentoo、FreeBSD、OpenBSDなど）に搭載されている。また、Freshmeat.Netのリポジトリでは、（30,000個のうちの）上位10個のプログラムに入っている。このことは、Nmapの開発およびユーザサポートコミュニティが活発であることを意味している。

基本コマンド

ターゲットIP(59.152.32.35)の解放ポート検索例

# nmap 59.152.32.35
Starting Nmap 7.91 ( https://nmap.org ) at 2021-04-07 20:02 JST
Nmap scan report for 59.152.32.35
Host is up (0.052s latency).
Not shown: 993 closed ports
PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  open     http
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
179/tcp open     bgp
443/tcp open     https
445/tcp filtered microsoft-ds

Nmap done: 1 IP address (1 host up) scanned in 2.71 seconds

ターゲットIP(59.152.32.35)の検索例　※バージョン情報も取得するパターン

# nmap -sV 59.152.32.35
Starting Nmap 7.91 ( https://nmap.org ) at 2021-04-07 20:03 JST
Nmap scan report for 59.152.32.35
Host is up (0.050s latency).
Not shown: 993 closed ports
PORT    STATE    SERVICE      VERSION
22/tcp  open     ssh          OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp  open     http         nginx
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
179/tcp open     tcpwrapped
443/tcp open     ssl/http     nginx
445/tcp filtered microsoft-ds
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.81 seconds

ー2021/12/29追記ー

A little bit about Nmap

Nmapコマンドを簡単にまとめます。

Scan type	Command
Discovery - ARP Scan	`sudo nmap -PR -sn Target_IP/24`
Discovery - ICMP Echo Scan	`sudo nmap -PE -sn Target_IP/24`
Discovery - ICMP Timestamp Scan	`sudo nmap -PP -sn Target_IP/24`
Discovery - ICMP Address Mask Scan	`sudo nmap -PM -sn Target_IP/24`
Discovery -TCP SYN Ping Scan	`sudo nmap -PS22,80,443 -sn Target_IP/30`
Discovery - TCP ACK Ping Scan	`sudo nmap -PA22,80,443 -sn Target_IP/30`
Discovery - UDP Ping Scan	`sudo nmap -PU53,161,162 -sn Target_IP/30`
Port Scan - TCP Connect Scan	`nmap -sT Target_IP`
Port Scan - TCP SYN Scan	`sudo nmap -sS Target_IP`
Port Scan - UDP Scan	`sudo nmap -sU Target_IP`
Port Scan - TCP Null Scan	`sudo nmap -sN Target_IP`
Port Scan - TCP FIN Scan	`sudo nmap -sF Target_IP`
Port Scan - TCP Xmas Scan	`sudo nmap -sX Target_IP`
Port Scan - TCP Maimon Scan	`sudo nmap -sM Target_IP`
Port Scan - TCP ACK Scan	`sudo nmap -sA Target_IP`
Port Scan - TCP Window Scan	`sudo nmap -sW Target_IP`
Port Scan - Custom TCP Scan	`sudo nmap --scanflags URGACKPSHRSTSYNFIN Target_IP`
Port Scan - Spoofed Source IP	`sudo nmap -S SPOOFED_IP Target_IP`
Port Scan - Spoofed MAC Address	`sudo nmap -sT --spoof-mac SPOOFED_MAC Target_IP`
Port Scan - Decoy Scan	`sudo nmap -D DECOY_IP,Target_IP`
Port Scan - Idle (Zombie) Scan	`sudo nmap -sI ZOMBIE_IP Target_IP`
Port Scan - Fragment IP data into 8 bytes	`-f`
Port Scan - Fragment IP data into 16 bytes	`-ff`
Port Scan - Service Detection	`sudo nmap -sV --version-light Target_IP`
Port Scan - OS Detection	`sudo nmap -sS -O Target_IP`
Port Scan - Traceroute	`sudo nmap -sS --traceroute Target_IP`
Port Scan - Default scripts	`sudo nmap -sS -sC Target_IP`
Port Scan - FTP Brute force scripts	`sudo nmap -sS -n --script "ftp-brute" Target_IP`

すべての有用なパラメータの概要、パラメータを含む表。

Option	Meaning
`-sn`	host discovery only
`-n`	no DNS lookup
`-R`	DNS lookup for all hosts
`-p-`	scan all ports
`-p1-1023`	port range, from 1 to 1023
`-F`	top 100 most common ports
`-r`	scan ports in consecutive order
`-T<0-5>`	scan timing, T0 - slowest, T5 fastest
`--max-rate 20`	rate <= 20 packets/sec
`--min-rate 10`	rate >= 15 packets/sec
`-v`	verbose mode
`-vv`	very verbose mode
`-d`	debugging
`-dd`	detailed debugging
`--reason`	add more info from Nmap about decision it takes
`-sV`	version of service detected on open port
`-sV --version-light`	amount of version probes (2)
`-sV --version-all`	all available probes (9)
`-O`	detect OS
`--traceroute`	run traceroute to target
`--script=SCRIPTS`	Nmap scripts to run
`-sC` or `--script=default`	run default scripts
`-A`	equivalent to `-sV -O -sC --traceroute`
`-oN`	save output in normal format
`-oG`	save output in grepable format
`-oX`	save output in XML format
`-oA`	save output in normal, XML and Grepable formats

使用例

# sudo nmap -O -sV --version-intensity 5 --traceroute -oA /tmp/scan_output 192.168.1.1

ー2024/3/18追記ー

▼ 関連記事（Kali Toolsシリーズ）