reconnaissance

偵察

ドメインとウェブアプリケーションの偵察です。サブドメイン、開いているポート、エンドポイント、API、JavaScript のルートを発見し、攻撃対象領域の一覧を作成します。

フェーズ

ドメイン評価

1. サブドメインの発見 - パッシブ DNS、証明書の透明性、DNS ブルートフォース、ゾーン転送
2. ポートスキャン - nmap/masscan（上位 1000/10000/すべて）、サービス検出、OS フィンガープリンティング
3. サービス列挙 - バージョン検出、バナー取得、プロトコル固有の列挙

ウェブアプリケーションのマッピング

0. ソフトウェアインベントリ - 依存関係、フレームワーク、SBOM の生成
1. アクティブスキャン - ディレクトリ／ファイルを対象とする ffuf、gobuster、nikto、ZAP スパイダー
2. API の発見 - REST、GraphQL、SOAP、WebSocket、Swagger/OpenAPI ドキュメント
3. JavaScript と SPA - クライアント側のルート、動的スクリプト、ブラウザーのストレージ
4. 攻撃対象領域の分析 - 攻撃対象領域を分類し、リスクに基づいて優先順位を付ける

出力

inventory/  - JSON: subdomains, ports, endpoints, APIs, SBOM
analysis/   - MD: attack-surface, testing-checklist
raw/        - Tool outputs (nmap, ffuf, ZAP, subfinder)

ツール

subfinder、amass、certspotter、crt.sh、nmap、masscan、nuclei、sslscan、ffuf、gobuster、nikto、ZAP、Playwright MCP

関連スキル

• /osint - リポジトリの列挙、シークレットのスキャン、Git 履歴の分析のため、偵察と併せて実行します

ルール

1. アクティブスキャンの前に、パッシブな情報収集を行う
2. フェーズ 2 では、常に /osint を並行して実行する
3. レート制限を遵守する
4. ポートスキャンの前に、サブドメインが稼働していることを確認する
5. ツールの生出力をすべて保存する
6. HTTP レスポンスヘッダーからの vhost 漏えい：必ず生 IP のレスポンスヘッダーを確認してください（curl -sI http://IP/）。X-Backend-Server、X-Forwarded-Host、X-Served-By、X-Upstream などのヘッダーからは、DNS やブルートフォースでは検出できない内部ホスト名や vhost が漏れることがよくあります。検出したホスト名は、すぐに /etc/hosts に追加してください。
7. ワイルドカード SSL 証明書（SAN に *.domain.tld がある場合）は、隠れた vhost の有力な兆候です。ワイルドカード SAN を検出したら、必ず ffuf -u https://IP -k -H "Host: FUZZ.domain.tld" -w subdomains.txt -mc all -fs <default_size> で vhost のブルートフォースを実行してください。レスポンスサイズとステータスをデフォルトの vhost と比較し、有効なサブドメインを特定します。
8. ffuf を使わない VHost 列挙：ffuf や gobuster が使えない場合は、シェルループを使用します：for sub in admin dev api portal dashboard staging git; do code=$(curl -s -o /dev/null -w "%{http_code}:%{size_download}" -H "Host: ${sub}.DOMAIN" http://IP); echo "$sub: $code"; done — デフォルトページとのレスポンスサイズの違いで絞り込みます。
9. Web 管理パネル：admin.、panel.、manage.* などの管理用 vhost を検出したら、既知の管理 UI を確認してください：Nginx UI（manifest.json →「Nginx UI」）、Cockpit、Webmin、phpMyAdmin。これらには、認証不要の API エンドポイントや既知の CVE が存在することがよくあります。Nginx UI については、特に /api/backup、/api/settings、/api/install を確認してください。
10. マーケティング層でのモバイル／ネイティブクライアントのダウンロード：公開 Web 層に .apk／.dmg／.exe／.ipa へのダウンロードリンクがある場合、「本物の」API エンドポイントと必須ヘッダーには通常、そのクライアントからしかアクセスできません。Web HTML からは有用な情報が得られず、API はバイナリにハードコードされた静的 User-Agent／Host によって制限されています。ボックスが静的ページだけだと決めつける前に、必ずクライアントを取得して逆コンパイル／抽出してください。Android React Native の場合：unzip <app>.apk -d ext/ && file ext/assets/index.android.bundle。バンドルは通常、obfuscator.io 形式です（function _0xNNNN(idx) デコーダーと、parseInt の式がターゲット値と一致するまでループする array.shift() の IIFE）。手作業で解読するのではなく、デコーダー、配列リテラル、IIFE を単独の Node.js ファイルに抽出し、数秒ですべてのインデックスを出力してください：for(let i=baseHex; i<baseHex+arr.length; i++) console.log(i.toString(16), _0xDecode(i));。次に、API 呼び出しの難読化されたオブジェクトリテラルを再構築します（URL は短い断片 4～7 個の連結で、ヘッダーも同様です）。復元した値をそのまま使ってリクエストを再送してください。
11. Windows ターゲット向けの AD 特化ポートスキャン：初期フィンガープリントで Windows DC 型（53／135／139／445／389 のいずれかがオープン）が示された場合は、-p- を省略し、まず AD 関連の 13 ポートに絞ってスキャンしてください。数秒で完了し、重要な項目をすべてカバーできます。

    nmap -Pn -sC -sV -p 53,88,135,139,389,445,464,593,636,3268,3269,5985,5986,9389 -oA recon/ad-focused TARGET
    

    ポートの内訳：53 DNS、88 Kerberos、135 RPC、139／445 SMB、389／636 LDAP／LDAPS、464 kpasswd、593 RPC-over-HTTPS、3268／3269 GC／GC-LDAPS、5985 WinRM（HTTP）、5986 WinRM（HTTPS — 証明書認証）、9389 AD Web Services。5985 と 5986 の両方を必ず調べてください。5985 がフィルタリングされている場合、クライアント証明書認証を使う 5986 が一般的な足がかりとなることがあります（WinRM 証明書認証の足がかりについては skills/system/reference/foothold-patterns.md を参照）。-p- に切り替えるのは、（a）絞り込みスキャンでフラグにつながるサービスが見つからない場合、または（b）標準外の高位ポートでのアプリ（カスタム Web サービス、3389 以外の RDP など）が疑われる場合に限ってください。AD 型が明白な場合に、全 TCP ポートのスキャンで 30 分も費やさないでください。
12. CT ログの列挙は必須です：エンゲージメントでアペックスドメインが指定されている場合はすべて、CT ログの列挙（crt.sh／certspotter／subfinder）が必須です。ホスト名が提供されているグレーボックスエンゲージメントも含みます。提供されたホスト名はシードであり、調査対象全体ではありません。CDN／WAF の背後にあるターゲットには、さらにオリジンの特定（クラウドエンドポイントへの直接アクセス、archive.org CDX、過去の DNS）も行ってください。crt.sh／subfinder のコマンドは reference/scenarios/subdomain-enumeration.md にすでに用意されているため、使用してください。