recon-a-domain-passively

ドメインを受動的に調査する

1 つのドメインから、組織のインターネット公開資産と、その所有者について、根拠のあるマップを作成します。手法はほかのスキルで扱います。このワークフローで重要なのは、順序、インベントリ、停止ルールです。最初から避けるべき失敗は 2 つあります。何時間も列挙し、帰属情報や日付、優先度のないホスト名を 400 件並べること。これではマップとはいえません。もう 1 つは、受動的な調査だと気づかないうちに能動的な調査へ移行することです。「稼働しているか確認するだけ」のプローブを 1 回行えば、受動的という主張は成り立たなくなります。ステップ 2 の途中ではなく、その前に受動的調査の境界を決めてください。

順序の考え方

各ステージの結果を次のステージで活用します。最も安価で目立ちにくいものから順に進めます。

順序	ステージ	この順序にする理由
1	登録情報と DNS	範囲を定義します。apex ドメインと登録者がわからなければ、何が対象範囲内なのかわかりません
2	名前の拡張	アーカイブソースのみを使用します。コストも接触もなく、ほかのすべての工程で使う候補リストを作成できます
3	名前解決とインベントリ	名前をアドレスに変換します。インフラストラクチャの検索にはアドレスが入力として必要です
4	インフラストラクチャとサービス	ステージ 3 のアドレスが必要です。サードパーティのスキャンデータのみを使用します
5	コンテンツ、履歴、コード、技術スタック	先行ステージで得たホスト名と組織名を検索語として使い、収集済みの情報も再利用します
6	所有者の帰属確認	上記で見つかった登録者、テナント、組織名を入力として使います

ステージ 1～5 は一方向ではなく、ループとして実行します。各ステージで新たな検索条件が得られたら、ステージ 1 または 2 に戻します。ステップ 7 の停止ルールを満たしたら、ループを終了します。

ステップ 1 — 許可された範囲

対象（対象となるドメインとネットブロック、および明示的に除外する隣接範囲）、目的、関係する管轄区域、受動的調査の境界を文書に明記します。特に、DNS の名前解決、ワードリストによるブルートフォース、対象への HTTP 接続が許可されているかを明確にしてください。 ../../ETHICS.md をお読みください。調査に気づかれることが問題になる場合は、何かを検索する前に investigate-without-getting-made を使って帰属情報の管理を設定してください。

完了条件： 対象、目的、対象外リスト、管轄区域、受動的調査の境界を文書に記録し、グレーゾーンとなる 3 つの活動のうち、どれを実施できるか把握していること。

ステップ 2 — 登録情報と DNS のベースライン

対象範囲内の各 apex ドメインで who-owns-this-domain を実行します。レジストラ、日付、ステータス、ネームサーバー、すべてのレコードセット、そして TXT、MX、DKIM、CAA から判明するメールおよび SaaS のフィンガープリントを確認します。登録情報が伏せられている場合は、同じ調査で過去の WHOIS 情報も取得します。

完了条件： すべての apex ドメインについて、取得時刻を記録した登録情報、完全なレコードセット、DNS から抽出したサードパーティベンダーの一覧がそろっていること。

ステップ 3 — 名前空間を拡張する

find-hidden-subdomains を実行します。Certificate Transparency と受動 DNS は、無料で、履歴を確認でき、外部から見えないため、最初に使います。ドメインだけでなく、ステップ 2 で得た組織名も検索対象に含めてください。証明書のサブジェクト検索を使えば、依頼内容に含まれていなかった関連ドメインや買収したドメインも見つかります。

完了条件： 重複を除いた候補ホスト名の一覧があり、各名前についてソースと初回確認日を記録していること。また、新たに見つかった apex ドメインをステップ 2 に戻して調査していること。

ステップ 4 — 名前を解決し、インベントリを開始する

各候補を次のように分類します。アドレスに解決される、サードパーティの CNAME に解決される、または解決されない。最後まで待たずに、ここでインベントリを作成します。すでに収集した一覧に後から出所情報を追加しようとすると、調査結果のタイムスタンプが失われます。スキーマと行ごとのフィールドについては、reference/asset-inventory.md を参照してください。

完了条件： すべての候補が、名前解決のタイムスタンプとともに 3 つの分類のいずれかに登録されていること。名前解決されるすべてのホストについて IP と ASN が記録され、すべてのサードパーティ CNAME が特定のベンダーに帰属していること。

Step 5 — インフラストラクチャとサービス

ステップ 4 のアドレスとネットブロックに対して find-exposed-servers を実行します。スキャンプラットフォームのみを照会してください。ポートスキャンやサービスプロービングは行わないでください。証明書とファビコンを手掛かりにして、対象と DNS を共有していなくてもインフラストラクチャを共有しているホストを見つけ、意図せず公開されているように見えるものを記録します。

完了条件： 対象範囲内の各 IP について、観測されたポートとサービスにスキャン日が記録されていること、各ネットブロックについて RIR レコードに基づく所有者が特定されていること、証明書またはファビコンを手掛かりにしてのみ見つかったインフラストラクチャがインベントリに追加され、帰属の確度が評価されていること。

Step 6 — コンテンツ、履歴、コード、技術スタック

次の 3 つの情報源を、この順に利用します。

• read-deleted-pages で、かつての状態を調べます。廃止されたホスト名、以前のスタッフページ、公開されていたパス、CDN 導入前のインフラストラクチャに関する記述などです。
• google-like-a-spy で、見つかったホスト上で現在インデックス登録されているものを調べます。ドキュメント、ディレクトリ一覧、設定ファイル、忘れられたポータルなどです。
• secrets-in-git-history で、ステップ 2 から 5 で明らかになった組織名、GitHub 組織のスラッグ、クラウドテナントのラベル、プロジェクト ID を調べます。

画像が重要な場合（サイト群で再利用されているロゴや、オフィスの写真を装ったストックフォトなど）は、find-the-original-image を実行します。DNS や登録情報では結び付かないサイト同士も、共通の画像から関連性を特定できます。

次に、ここまでに集めた情報から技術スタックをまとめます。アーカイブされたコピーやスキャン記録にあるヘッダーと Cookie、証明書の発行者、CNAME のターゲット、JavaScript とアセットのパス、CSP ディレクティブ、ファビコンのハッシュ、ステップ 2 で得た SaaS のフィンガープリントを使います。ライブページが必要な場合は、ページを直接取得せず、サードパーティによるスキャン結果を確認してください。

完了条件： 優先度の高いホスト名についてアーカイブ済みコンテンツとインデックス登録済みコンテンツの確認が済んでいること、コードの露出が記録されているか、露出なしと判断されていること、新たなホスト名がステップ 4 で再調査されていること、そして各結論の根拠となるアーティファクトを示し、バージョンを検証済みではなく申告値として明記したうえで、ホストごとに技術スタックが記録されていること。

Step 7 — マップの完成を判断する

網羅性は判断を要するため、基準に照らして判断します。

• 連続する 2 つの新しい情報源から、新たなアセットが見つからないこと。限界まで調査したことではなく、飽和状態が完了の兆候です。
• 発見したすべての名前が解決済み、または分類済みであり、名前解決できるすべてのホストに所有者と帰属の確度が付与されていること。
• 命名規則に説明のつかない欠落がないこと。たとえば、web01 と web03 がインベントリにある場合、web02 についても確認できていること。
• ステップ 2 で特定したすべてのベンダー名とテナントからアセットが見つかっているか、該当なしと判断されていること。
• ステップ 1 の目的に、インベントリをもとに回答できること。

基準を満たさない場合は、再開すべき段階が明確になります。

完了条件： 5 つすべての基準を満たしていること。満たせない場合は、残る不足事項を暗黙のままにせず、明示的な制約事項として記録すること。

Step 8 — 所有者側の調査を引き継ぐ

登録者、証明書のサブジェクト、RIR の再割り当て先、またはテナントラベルが個人ではなく法人に解決された場合、ドメイン調査は完了です。ここからは法人調査を開始します。法人名と管轄区域を x-ray-a-company に引き継ぎ、登記と実質的所有者に関する確認事項は who-really-owns-it に、復元したメールアドレスは what-an-email-reveals に渡してください。DNS のアーティファクトから法人構造を推定しようとしないでください。DNS が示すのは運用者であり、株主ではありません。

完了条件： 所有者側のセレクターがすべて適切なスキルに振り分けられているか、行き止まりとして理由とともに記録されていること。

Step 9 — 報告する

write-the-intel-brief を実行します。まずアセットのインベントリを示し、次に帰属の連鎖、意図せず公開されているように見えるもの、最後にステップ 7 の制約事項を記載します。完了条件： すべての主張が情報源とタイムスタンプを伴うインベントリの行にたどれること、そしてすべての調査結果に確度の評価が付いていること。

ここでうまくいかなくなること

• 方向転換によるスコープクリープ。 列挙を続けると、関連するドメインが際限なく見つかり、そのたびに次の調査対象に見えてきます。ステップ1の対象リストに含まれていない場合は、作業を開始するのではなく、発見事項として報告してください。
• 気付かぬうちにアクティブな調査へ移行。 名前解決、ブルートフォース、HTTP プロービングは連続した範囲にあり、ツールもその境界を曖昧にします。パッシブな収集ツールにも、フラグを1つ追加するだけでアクティブになるモードがあり、不注意なフラグ1つで、そのエンゲージメントがパッシブだという主張が成り立たなくなります。
• 帰属のないインベントリ。 共有ホスティング、CDN アドレス、バンドルされた証明書によって、対象のものではない資産まで対象に紐付けられることがあります。評価が付いていないインベントリ項目は責任問題になります。同様に、対象が利用しているだけの脆弱な SaaS テナントは、サプライチェーン上の発見事項であり、そのように表現する必要があります。
• 古いデータを現行情報として提示。 アーカイブ、CT、スキャン記録はいずれも過去の情報です。日付のない発見事項は、発見事項とは言えません。
• 最初に静かになった時点で停止。 新しい結果が得られなくなった場合、通常は1つの情報源が飽和しただけで、対象の全体像が把握できたわけではありません。これを確認するのがステップ7です。
• 過剰な収集。 アーカイブ済みページや SNMP の連絡先にある職員名は個人データです。目的に必要な情報だけを収集し、それ以上は収集しないでください。

信頼度の評価

インベントリと帰属は別々に評価してください。ホストが稼働中のサービスとして確認できていても、対象の資産であることは未確認という場合があります。この2つを混同することが、ドメイン調査で最もよくある報告上の誤りです。

• 確認済みの資産 — 登録情報を確認したドメイン配下にある、名前によって対象へ再割り当てされたネットブロック上にある、または対象が管理していることを実証できる証明書を提供しており、さらに独立した2つ目の情報源でも裏付けられているもの。
• 資産である可能性が高い — 強いインフラストラクチャのフィンガープリントが1つあり（共有 DKIM キー、同じメールテナントのラベル、プロバイダーが割り当てた同一のネームサーバーペア、特徴的なファビコンまたは本文の文字列など）、それに矛盾する情報がないもの。
• 未確認 — 共有ホスティングまたは CDN のアドレス、バンドルされた証明書に記載された名前、org:だけに基づく帰属、または基礎となる記録を確認していないアグリゲーターの結果。

各手法のスキルに、これより具体的な基準がある場合は、そちらを優先してください。

実例

エンゲージメント：クライアントが meridian-freight.test を買収する予定で、契約締結前にインターネットに公開されている対象資産を把握したいとしています。スコープ：頂点ドメインと、登録者が管理していることを実証できるすべてのドメイン。境界：名前解決は許可、ブルートフォースは禁止、HTTP への接触は禁止。

ステップ2：登録から5年が経過しており、登録者情報は秘匿されていますが、国は NL です。Microsoft 365 テナントがあり、サポートデスク、ID プロバイダー、GitHub 組織の TXT トークンが見つかりました。この GitHub 組織名は記録全体で最も価値の高い情報であり、調べるのに必要だったのは1回の検索だけでした。

ステップ3では候補が74件見つかり、証明書サブジェクトの検索で meridian-logistics-group.test が見つかりましたが、これは依頼内容には含まれていません。ステップ2に戻ると、MX レコードの M365 テナントラベルが同じであり、同じ運営者だと分かりました。対象に含め、クライアントに通知しました。

ステップ4：31件が名前解決でき、そのうち9件はサードパーティの CNAME に解決されました。これらは関係性を示すものであり、資産ではありません。uat-portal は他とは異なる小規模なオランダのホスティング用ネットブロックにあり、これがエンゲージメントの最有力候補になりました。

ステップ5：この UAT ホストでは、5週間前にポート443と3306が開いていることが観測されていました。また、ファビコンのハッシュを共有するホストが11件あり、隠れた資産群に見えましたが、確認すると、そのハッシュは標準的な CMS テーマのものでした。これが行き止まりの例です。確認を省略していたら、まさにこの種の情報が報告を水増ししていたでしょう。

ステップ6：GitHub 組織の公開リポジトリにある CI 設定ファイルから、DNS に存在しない2つの内部ホスト名が見つかりました。名前解決はできませんが、それでも重要です。買収者はこれらのシステムも引き継ぐことになるからです。

ステップ7：連続する3つ目の情報源から新しい情報は得られず、web02 の所在も確認でき、すべてのベンダーを調査済みです。完了と判断できますが、明示すべき未解決事項が1つあります。頂点ドメインのワイルドカード証明書があるため、それ以降に発行されたサブドメインは CT から見つけられません。ステップ8：オランダの登録者所在地、関連する兄弟ドメイン、証明書サブジェクトに含まれるグループ名から持株会社の構造がうかがえるため、x-ray-a-company に送ります。

次の調査先

セレクター	移動先
法人、グループ名、管轄区域	x-ray-a-company、who-really-owns-it
メールアドレスと電話番号	what-an-email-reveals、whose-number-is-this
アーカイブやメタデータに記載された従業員	find-anyone
リポジトリから判明した開発者のハンドル名	hunt-a-handle
資産から取得したドキュメント	secrets-in-file-metadata
ドメインのメールボックスに関する漏えい状況	what-leaked-about-you
構造把握のための全資産と法人の一覧	graph-the-network

法律および利用規約に関する注意事項

サードパーティのデータセットからの受動的な収集は、ほとんどの管轄区域で合法的な調査です。境界となるのは、対象へのトラフィックと非公開システムへのアクセスです。過去の WHOIS から復元された登録者データは、かつて公開されていたとしても GDPR 上の個人データであるため、適法な根拠が必要であり、収集を最小限に抑えなければなりません。スキャンプラットフォームやアーカイブの利用規約では、大量の再配布が制限されています。調査結果を引用するにとどめ、データセットを再公開しないでください。露出が見つかった場合に許可されるのは、運営者または該当する CERT への報告のみで、それ以外は認められません。また、デューデリジェンスでは、実施する調査範囲について、クライアントの書面による承認を得ていることを確認してください。「クライアントが買収する予定」というのは、対象からの承認ではありません。