osint-methodology

Name: osint-methodology
Author: elementalsouls

github.com/elementalsoulsセキュリティ5.3k277 回インストール今日更新

リポジトリ

osint-methodology について

osint-methodology は、レッドチーム、ASM、証拠管理向けに、認可済みの外部偵察と OSINT 調査の手順をまとめています。スコープ、確信度、情報源の記録、再現可能な報告を重視し、能動的な侵害行為は対象外としています。

主な機能

01認可範囲内での外部偵察
02発見事項への確信度付与
03資産の確信度を高める手順
04情報源、時刻、ハッシュの記録
05操作の検知可能性による分類
06所見とレポート形式の標準化

活用シーン

01組織の外部攻撃対象領域の把握
02サブドメイン、エンドポイント、漏えい認証情報の検証
03人物、組織、暗号資産の流れの調査
04再現可能な顧客向けレポートと証拠パッケージの作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill osint-methodology

インストール後、Claude Code で/osint-methodologyを入力して読み込まれたか確認します。

同梱ファイルREADME.md

詳細

OSINT 手法 — 外部レッドチーム版

0. このスキルを使う場合／使わない場合

このスキルを使う場合：

許可されたターゲットに対する外部偵察を計画または実行するとき（レッドチーム、バグバウンティの対象範囲内、ASM エンゲージメント）。
組織の外部攻撃対象領域を端から端までマッピングするとき（サブドメイン → アセット → 露出 → 攻撃経路）。
証拠の取り扱いに慎重さが求められる人物、組織、脅威アクターを調査するとき。
暗号資産の資金移動を追跡するとき、メディアの位置を特定するとき、画像や動画のフォレンジックを行うとき、またはイベントの発生時刻と場所を特定するとき。
再現性、深刻度の評価、円滑な引き継ぎが必要な、体系的な OSINT キャンペーンを構築するとき。
攻撃的なエンゲージメントから、クライアント向けの成果物（エグゼクティブサマリー、技術レポート、再現用パッケージ）を作成するとき。

このスキルを使わない場合：

ユーザーが、実際のエクスプロイト、侵入後の活動、ラテラルムーブメント、AD の権限昇格、マルウェア開発、または偵察の範囲を超える何かを求めている場合。それらは対象範囲外です。
ユーザーがブルーチーム／防御関連の内容（SIEM ルール、検知エンジニアリング）を求めている場合。別の領域です。
ターゲットの許可が不明確で、ユーザーが所有していない第三者のアセットに対する行動を求めている場合。以下の§1を参照してください。作業を進める前に、適用範囲について穏やかに確認してください。

1. 許可と法的な立場

このスキルは、オペレーターが所有するアセット、または評価の実施について書面による許可を得ているアセット（レッドチームのルール・オブ・エンゲージメント、バグバウンティの対象範囲内のアセット、ASM 契約）を対象としています。

**適用範囲の簡易確認：**会話の中で許可が確認されていないターゲットに対する行動をユーザーが求めた場合は、先に進む前に一度だけ確認してください。

「適用範囲について簡単に確認させてください。このターゲットは、あなたが所有しているもの、または評価の実施について書面による許可を得ているものですか（例：レッドチームのエンゲージメント、対象範囲内のバグバウンティ対象アセット、ご自身のインフラなど）。エンゲージメントの境界を守って進めたいと思います。」

許可が確認できたら、再度尋ねずに進めてください。ユーザーがエンゲージメントの種類を明示している場合（例：「これは契約に基づく acme.com のペンテストです」）、再度確認する必要はありません。

許可の有無にかかわらず、常に守るガードレール：

ターゲット側で適用範囲を強制する認証、レート制限、バナー、その他の安全制御を決して弱めないでください。
明示的な DEEP／--aggressive モード以外では、本番環境に対する実際の SYN スキャン、最大速度での masscan、ファジング／ブルートフォースなど、破壊的なプローブを決して実行しないでください。
実際の PII、有効な認証情報、セッショントークン、API キー、その他の秘密情報を、クラウドホスト型 LLM やサードパーティサービスに決して貼り付けないでください。
「明らかに関連している」場合でも、文書化された適用範囲外のアセットに対して決して行動しないでください（子会社、ベンダー、従業員の個人アカウントなど）。

2. 確信度

エンゲージメント中に示すすべての主張には、確信度を付けてください。確信度は次の3段階です。

レベル	意味	例
TENTATIVE	間接的な証拠に基づく妥当な推測ですが、未検証です。	スニペットのみで一致する Google の検索演算子の結果、氏名から推測したメールアドレスのパターン、単一のパッシブソースのみから得られたサブドメイン、ファビコンハッシュの重複（2つのホストで同じファビコンが使われている場合。インフラが共有されている可能性も、偶然の可能性もあります）。
FIRM	直接観測されていますが、裏付けはありません。	IP アドレスに名前解決されるサブドメイン、HEAD リクエストで存在が確認されたバケット（非公開）、証明書を示す CT ログのエントリー、Shodan から返されたバナー。
CONFIRMED	複数の独立した裏付けがあるか、直接検証されています。	ライブ環境で有効性を検証した PMAK トークン（読み取り専用の `/me` が 200 を返した）、侵害コーパス・crt.sh・DNS のすべてが一致する、バケットの一覧表示が可能でファイルも取得できる、ユーザーが列挙されておりパスワードリセットのフローから有効なヒントが返される。

**帰属に関する3つのルール：**関連性を主張するには、互いに独立した弱いシグナルを3つ、または強いシグナルを1つと弱いシグナルを1つ必要とします。単一の情報源だけで帰属を判断しないでください。

2.1 信頼度を高めるワークフロー

信頼度は固定されたものではありません。すべての TENTATIVE アセットについて、FIRM、さらに CONFIRMED へ移行するための手順を文書化してください。アセットタイプごとに、以下のルールを使用します。

アセットタイプ	TENTATIVE → FIRM	FIRM → CONFIRMED
サブドメイン	独立した 2 つ以上のパッシブソースから返される、または DNS A/AAAA/CNAME の名前解決が成功する。	標準ポート（80/443/22 など）で応答し、かつ HTTP バナー／TLS 証明書／SSH バナーが返される。
IP	2 つ以上のソース（パッシブ DNS、ASN ルックアップ、Shodan）から検出される。	アクティブプローブに応答する（少なくとも 1 つのポートで TCP SYN-ACK、または ICMP エコー応答）。
WebApp	JS／API／アーカイブから抽出された URL で、まだアクセスされていない。	HTTP リクエストが 2xx/3xx/4xx（ネットワークエラー以外の応答）を返し、かつ content-length > 0。
メールアドレス	名前のパターンから生成された、またはスニペットのみのドークから返されたもの。	Hunter.io／EmailRep／IntelX／漏えいデータのコーパスに掲載されている、または `MAIL FROM`/`RCPT TO` の SMTP プローブが 250 を返す（配信は行わず、DATA の時点で中止）。
バケット（S3/GCS/Azure）	プローブ未実施の、パーミュテーションによる候補。	HEAD が 200、301、または 403 を返す（存在を確認）。その後、GET がオブジェクト一覧または既知のオブジェクト取得を返した時点で CONFIRMED。
エンドポイント（API / wayback）	JS 正規表現／Wayback／Postman から抽出されたもの。	HTTP リクエストが 404 以外を返す（ルートが存在する）。その後、エンドポイントの挙動（認証の状態、応答形式、レート制限）のフィンガープリントが取得された時点で CONFIRMED。
認証情報／シークレット	取得したテキスト内でカタログの正規表現に一致する。	読み取り専用バリデーター（`/me`、`auth.test`、`sts:GetCallerIdentity`、`/user`）が成功を返す。その後、対象範囲とアカウント ID を記録した時点で CONFIRMED。
人物	1 つのソース（LinkedIn／漏えいデータ／GitHub のコミット）から抽出された名前。	2 つ目のソースで確認できる（Hunter.io の役職と LinkedIn プロフィール、または同じメールアドレスを含む 2 つの漏えいデータソース）。
リポジトリ	GitHub 検索で組織のキーワードに名前が一致する。	リポジトリのメタデータに、組織／メールアドレス／ウェブサイトの一致が確認できる。その後、コミット履歴で従業員の関与が確認された時点で CONFIRMED。
モバイルアプリ	アプリストアで名前が一致する。	所有者信頼度スコアが 70 以上（補足スキル §21 を参照）。その後、バイナリのメタデータ（署名証明書、パッケージ名、開発者アカウント）で対象との関連が確認された時点で CONFIRMED。
証明書	crt.sh から一度返される。	2 つ以上の CT ログで CT ログエントリが確認される。その後、検出済みのホストで提供されていることが確認された時点で CONFIRMED。
SSO テナント	検出エンドポイントから OIDC メタデータが返される。	テナント GUID が抽出され、かつドメインがテナントに期待される MX／autodiscover／SP レコードを通じて解決される。

デフォルトの報告方針： 明示的な裏付けなしに CONFIRMED と断定しないでください。判断に迷った場合は、信頼度を下げてください。オペレーターは、過剰な主張よりも控えめな主張を信頼します。

3. 出力形式の規約

アクティブセッション中に調査結果を出力する場合は、各結果を以下のスキーマに合わせて構成してください。アセット管理ツールにそのまま取り込めます。

Finding:
  id:           <stable hash or UUID>
  module:       <which technique discovered it; "manual" if hand-found>
  asset_key:    <typed key, e.g. sub:api.example.com or webapp:https://example.com/admin>
  category:     <e.g. SECRET_LEAK, MISSING_HSTS, OPEN_GRAPHQL_API, LEAKED_CRED, SSO_EXPOSURE>
  severity:     <info|low|medium|high|critical>
  confidence:   <tentative|firm|confirmed>
  title:        <one-line summary>
  description:  <2-5 sentences>
  evidence:
    url:        <where it was found>
    timestamp:  <UTC ISO8601>
    sha256:     <hash of any downloaded artifact>
    raw:        <truncated to 2 KiB>
  references:
    - <CVE-ID, advisory URL, vendor doc>
  remediation:  <action the asset owner can take>

タイムスタンプには必ず UTC を使用してください。 現地時間を使うと、メモ／スクリーンショット／ログ間で相関に関する問題が発生します。

4. ソースの取り扱いと引用

取得するすべての証跡について、URL + UTC タイムスタンプ + SHA-256 ハッシュ + ツールのバージョン + run_id を記録してください。

ダウンロードしたファイルはすべて SHA-256 でハッシュ化します。
証拠パックでは、スクリーンショットを PNG（可逆圧縮で、ページ全体の WARC より小さい）で保存します。
証拠パックを小さく保つため、生の HTTP リクエスト／レスポンスを取得し、本文は 2 KiB までに制限します。
JSONL（NDJSON）ログを使用し、イベントごとに 1 行で記録します。エンゲージメント全体を再現できるよう、run_id を含めてください。
証拠の読み取り専用コピーと作業用コピーを分け、取得した証跡は決して編集しないでください。

出力でソースを引用する際は、揮発性の高いもの（Twitter の投稿、フォーラムのスレッドなど）より、長期間参照できる資料（CVE、ベンダーのアドバイザリー、ATT&CK のテクニック ID、RFC など）を優先してください。揮発性の高いものしかソースがない場合は、引用する前にアーカイブしてください（archive.today、Wayback SavePageNow）。

5. 禁止事項（厳守）

クラウド LLM（ChatGPT、Claude.ai、Gemini、Perplexity）に認証情報、セッショントークン、API キー、実際の個人識別情報（PII）、インフォスティーラーのログ、または一意のピボット情報を貼り付けないでください。機密性の高い分析にはローカルモデル（Ollama、LM Studio、GPT4All）を使用してください。
ベンダーのラベルが真実であると決めつけないでください。ラベル間の整合性を確認してください。TRM、Chainalysis、Arkham の見解は異なる場合があります。すべてのラベルを仮説として扱ってください。
ブリッジのフローが 1 対 1 だと決めつけないでください。ブリッジ、ミキサー、ラッパーではミント／バーンのセマンティクスが導入されるため、オンチェーンの証明で検証してください。
単一のシグナルから所有権を断定しないでください。ファビコンハッシュの重複、共通の CT 発行者、共通の NS は、それぞれ仮説にすぎません。3 つのルールに従ってください。
明示的な DEEP／--aggressive モード以外では、ファジング、SYN スキャン、masscan、または nuclei fuzzing/* テンプレートを実行しないでください。
認証情報バリデーターは、読み取り専用の検証以外に使用しないでください（作成、削除、送信は禁止です）。
ミラーメージュ（対象も自分と同じ考え方をすると想定すること）をしないでください。能力と意図、支援元を分けて考えてください。
相関関係と支配を混同しないでください。
アクティブな防御に遭遇した場合、エスカレーションしないでください。いったん引き下がり、記録してください（§6.4 を参照）。

6. OpSec

6.1 ソックパペット

ソックパペットとは、あなたと結び付けられない偽アカウントです。投稿履歴を作り、アカウントを一定期間運用し、別のブラウザープロファイルから使用してください。

リソースと手法：

ペルソナの生成：Fake Name Generator、This Person Does Not Exist。
ブラウザーの分離：Firefox Multi-Account Containers、またはペルソナごとに専用のプロファイルを使用します。
使い捨て電話番号：Burner、Silent Link（一部のプラットフォームでは VoIP が拒否されます。番号を予備として確保しておいてください）。
価値の高いペルソナにはハードウェアパスキーを使用し、リカバリーコードはオフラインで保管してください。
インストール前にブラウザー拡張機能をすべて監査してください。人気の拡張機能を狙ったサプライチェーン攻撃が調査員を繰り返し標的にしています。人気の拡張機能はリスクが低いのではなく、高いと想定してください。
証拠保全の連鎖を維持してください。すべての操作にタイムスタンプを付け、重要なアーティファクトをすべてハッシュ化し、案件ごとにツールのバージョンを記録してください。
ペルソナは、実際のエンゲージメントが低いアカウントのように見せてください。プロフィール写真（合成画像）、自己紹介、そしてペルソナを「使用」する数週間前から投稿しておく、手の込んでいない投稿をいくつか用意します。

参考資料：

6.2 検知可能性と運用セキュリティのタグ付け

すべてのプローブは痕跡を残します。ターゲット側に残す SIEM の記録を考慮できるよう、各操作に検知可能性のレベルをタグ付けし、メモに記録してください。

タグ	例
Low	パッシブな Shodan InternetDB、CT ログのクエリ（crt.sh）、Wayback CDX、パッシブ DNS（SecurityTrails）、Hunter.io によるメール情報の補完、公開バケットへの HTTP HEAD、`getuserrealm.srf`、Microsoft OIDC メタデータの取得。
Medium	Microsoft `GetCredentialType` によるユーザー列挙、Okta `/api/v1/authn` によるユーザー列挙、Postman API キーの検証、AWS `sts:GetCallerIdentity`（CloudTrail に記録）、Slack `auth.test`、ページ全体のスクリーンショット、28／13 パスのワードリストを使った Swagger／GraphQL プローブ、対象を絞った favicon ハッシュと JARM によるフィンガープリンティング。
High	アクティブなポートスキャン（naabu／masscan／nmap）、本番環境に対する Nuclei の全テンプレート実行、大規模なサブドメインのブルートフォース、サードパーティのミラーからの APK ダウンロード、テナントあたり N 回を超えるディープモードのユーザー列挙、SMTP `RCPT TO` による列挙、Web ファジング（ffuf/gobuster）。

クライアントと作業する場合は、実際に実行した操作とその検知可能性タグをエンゲージメントレポートに記録してください。クライアントは、自社の検知システムが何を検知できているはずかを把握できるため、こうした情報を歓迎します。

デフォルト： デフォルトではパッシブにします。アクティブなプローブは、（a）明示的に許可されている場合、（b）合意済みのメンテナンス時間内である場合、（c）オペレーターが発生するログの量を認識している場合に限り実施します。

6.3 バリデーターの規律

実環境で認証情報（漏えいした API キー、ソースマップから露出したトークン、公開 Postman ワークスペースにハードコードされた PMAK など）を見つけたとき、それが有効かどうか確認したくなることがあります。その場合は、読み取り専用のバリデーターのみを使用してください。

規律：

読み取り専用のエンドポイントのみを使用します（例：/me、/whoami、auth.test、sts:GetCallerIdentity）。
検証した認証情報を使って、何かを作成、変更、削除、送信することは決してしないでください。
検証の試行に検知可能性のタグを付けます。バリデーターはすべて、プロバイダー側で監査ログのエントリーを生成します。
checked_at（UTC）、レスポンス（省略したもの）、返されたスコープ／アカウント ID を記録します。
オペレーターのルール・オブ・エンゲージメントで検証が禁止されている場合は、認証情報に validation_skipped_by_policy のタグを付けて終了します。

具体的なバリデーターのエンドポイント（Postman、AWS、GitHub、Slack、Anthropic、OpenAI、npm、Atlassian、DataDog）は、付属の offensive-osint スキルに記載されています。

6.4 検知を考慮したプロービング（検知の兆候とバックオフ）

プローブがいずれ検知されることを想定してください。兆候を見極め、アクティブな対応を招く前にバックオフしてください。

検知された兆候（おおむね深刻度の低い順）：

レート制限の応答 — 429 Too Many Requests、Retry-After ヘッダーが設定されている、X-RateLimit-Remaining: 0。
CAPTCHA のインタースティシャル — Cloudflare のインタースティシャルページ、hCaptcha チャレンジ、AWS WAF ページ。
WAF ページ — プロバイダーのブランド表示（Cloudflare、Akamai、Imperva、F5 ASM、AWS WAF、Sucuri）を伴う、明示的な「Access denied」。
ステータスコードの変化 — 以前は 200/401 を返していたエンドポイントが、あなたの IP からのみ 403 を返す。
バナーの変化 — サーバーヘッダーの形式や応答時間が一貫して変化する。
DNS が NXDOMAIN に戻る — 対象の権威サーバーがサブドメインを解決しなくなる（CDN に切り替わった可能性があります）。
ハニーポットの餌 — うますぎるように見えるエンドポイント（/admin/db_dump.sql、検証できない認証情報が含まれた露出済みの .env）。実際の情報漏えいで、これほど整っていることはほとんどありません。
直接の連絡 — 偽装用メールアドレスに「不審なアクティビティを検知しました」というメッセージが届く、または極端な場合には IP 宛てに親切な不正利用窓口からのメールが届く。

バックオフの手順：

速度を落とします。 同時実行数を半分にします。リクエスト間に 2～10 秒のジッターを加えます。
エンドポイントを切り替えます。 きっかけとなったパスへのアクセスを停止し、偵察パイプラインの別のモジュールに移ります。
ペルソナを切り替えます。 新しい User-Agent（実際のブラウザーをローテーション）、新しい TLS フィンガープリント（異なるバージョンの httpx/curl）を使用します。
IP を切り替えます。 新しい送信元に切り替えます（住宅用プロキシ、機密性の高いルックアップには Tor、または別のクラウドリージョン）。
一時停止します。 1～24 時間待ちます。多くの WAF は、IP ベースのレピュテーションをローリングウィンドウで管理しています。時間を置くだけでリセットされることもよくあります。
記録して相談します。 (3) WAF、(4) ステータスの変化、または (8) 直接の連絡を受けた場合は、アクティブなプロービングを停止し、エンゲージメントリードに相談してください。こうした兆候が出た後もプロービングを続けると、スコープ違反のリスクがあります。

ペルソナ／IP のローテーション規則：

同じ対象への過去のエンゲージメントで使用したペルソナに、決して切り替えないでください。
検知されやすい作業には住宅用プロキシ（Bright Data、Smartproxy、IPRoyal）を使用します。ただし、Cloudflare に IP をブロックリスト登録されていることがある点に注意してください。
Tor の出口ノードはパッシブなルックアップ（CT ログ、アーカイブサイト）には便利ですが、アクティブなプローブの対象の多くではブロックされています。
クラウドの送信元 IP（AWS／GCP／Azure）は、偵察目的で積極的にブロックリスト登録されることがよくあります。使用は控えめにしてください。
ローテーションはすべて、タイムスタンプと理由を記録してください。レビュー担当者から確認されます。

禁止事項：

確認済みの WAF ブロックを、より攻撃的なペイロードを送って「出し抜こう」としないでください。それではクライアントのログが増え、あなたが発覚することになります。
明示的なブロックリストを回避するために送信元 IP を切り替えないでください。これは回避行為にあたり、ルール・オブ・エンゲージメントに違反する可能性があります。
ダッシュボードに「稼働中」と表示されているからといって、兆候を無視しないでください。プローブは密かに記録されており、対応は後から行われます。

7. 外部レッドチーム偵察パイプライン

許可を得た外部評価で使用する 5 段階のパイプラインです。各段階は順番に進めます。各段階内のモジュールは並行して実行できます。

Stage 1 — シードの検出

対象が何者で、何であるかの事実関係を確立します。

シードドメインの WHOIS（登録者、日付、ネームサーバー）。
ASN の列挙：組織が所有または使用する AS を確認します（Hurricane Electric BGP Toolkit、RIPEstat、BGPView）。
DNS レコード（A/AAAA/MX/TXT/NS/SOA/CAA）— まずレコードのみを確認し、まだウォークは行いません。
ルートドメインの証明書透明性の履歴（crt.sh、Censys）。

ステージ 2 — アセットの拡張

対象に属する可能性のあるものをすべて発見します。

サブドメインの列挙（まずは受動的な情報源：crt.sh、VirusTotal、AlienVault OTX、Shodan、その後にパーミュテーションとブルートフォースを行います）。
クラウドバケットの列挙（企業名とサブドメインの語幹を使った S3／GCS／Azure のパーミュテーションについては、§15 を参照）。
タイポスクワットドメインの生成（dnstwist のバリエーション → 解決 → WHOIS）— フィッシングのリスクと関連する企業アセットの両方を対象にします。
忘れられたパスを探すための Wayback CDX アーカイブエンドポイント。
モバイルアプリの発見（Android は google-play-scraper、iOS は iTunes Search API を使用します。§14 を参照）。
DNS の詳細な調査（設定ミスのあるゾーンでの NSEC ウォーク、機会を捉えた AXFR）。
LinkedIn での従業員の列挙 → メールアドレスのパターンの推定。

ステージ 3 — 情報の充実

発見したアセットの情報を詳しくします。

ポートとサービスの検出（無料の Shodan InternetDB → 許可されている場合は naabu／masscan）。
TLS ハンドシェイクの実施（証明書チェーン、JARM、favicon の mmh3 ハッシュ）。
Web 技術の検出（httpx を使用した Wappalyzer 形式の約 600 件のシグネチャ）。
WAF／CDN の推定（ヘッダーマーカー）。
CDN の背後にある場合のオリジンの発見（§27 を参照）。
セキュリティヘッダーの監査。
スクリーンショットの一括取得（数千のホストを視覚的にトリアージします）。
メールアドレスの収集（6 つの並列ソース）。
メールセキュリティの監査（SPF／DMARC／DKIM／BIMI／MTA-STS）。
GitHub コード検索の dork 検索（13 個の dork テンプレート × 29 個以上のシークレット正規表現）。
JavaScript の詳細な分析（ソースマップ、シークレット、エンドポイント、内部ホストの漏えい）。
SSO／IdP テナントのフィンガープリンティング（Entra、Okta、ADFS、Google、SAML、M365 Teams／SharePoint／OAuth。§11 を参照）。
API と認証マップの発見（Swagger／OpenAPI、GraphQL、Postman）。
GitHub 以外を対象としたシークレットの一括調査（Postman の公開ワークスペース、Stack Exchange、Trello／Notion／Atlassian の dork 検索）。
ベンダー製品のフィンガープリンティング（Citrix／F5／PaloAlto／Pulse／Fortinet／Cisco／VMware／Exchange）。
コンテナー／CI-CD／クラウドネイティブ環境の露出チェック。
技術スタックを推定するための求人情報の収集。

ステージ 4 — 露出の分析

アセットを調査結果に変換します。

Nuclei（常時有効な組み込みチェック 15 件 + オプションのバイナリ）。
TLS の詳細監査（sslyze／testssl.sh）。
漏えい情報と ID の相関分析（HudsonRock Cavalier、HIBP、DeHashed、IntelX、ローカルコーパス → SSO_EXPOSURE の調査結果）。
対象を絞った設定ミスのプローブ（.git/config、.env、phpinfo.php、/actuator/env、/actuator/heapdump、_cat/indices、/console、/manager/html）。
脆弱性の優先順位付け（CVE × EPSS × CISA KEV × 公開 POC の有無。§28 を参照）。

ステージ 5 — レポート

作業結果を活用できる形にします。

調査結果ごとのリスクスコアリング（CVSS + プログラム固有の重み付け）。
アセットグラフのエクスポート（D3 対応のノード／リンク、GraphML、JSON）。
クライアント向けレポート（エグゼクティブサマリー + 技術的な詳細 + 修復方法。§31 を参照）。
再現パッケージ（run_id、ツールのバージョン、生の証拠、JSONL ログ）。
バグバウンティへの報告（該当する場合。§30 を参照）。

7.5 パイプラインの優先順位（シグナル密度の高い順）

予算が限られている場合は、次の順に進めます。

情報漏えい — 情報窃取マルウェアのログ（HudsonRock Cavalier の無料プラン）＋ HIBP ＋ DeHashed。レッドチームにとって最も ROI が高く、有効な平文の認証情報が企業の SSO で使えるケースもよくあります。入力としてメールアドレスが必要です。
GitHub の偵察 — コード検索用のドーク。AWS キー、Slack トークン、JWT シークレット、.env ファイルを見つけます。クラウドへピボットする最速の手段です。
Nuclei の設定ミススイープ — 外部公開された管理パネル、公開 PoC のある CVE。
クラウドバケット — 企業名とサブドメインの語幹を組み合わせます。一覧表示可能なバケットは CRITICAL です。
ポート — まず Shodan InternetDB を使います（無料、キー不要）。VPN コンセントレーター、RDP、Jenkins、GitLab-CE、Elasticsearch は価値の高いピボットポイントです。
メール OSINT — 情報漏えい調査に役立ち、フィッシング対象リストの作成にも役立ちます。
Web 技術／WAF／スクリーンショット — 数千のホストをトリアージし、プロービングの前に技術スタックを把握します。
Wayback — アーカイブされた JavaScript にハードコードされたキーが含まれていることがよくあります。アーカイブされたエンドポイントから、削除された管理者用／開発用パスが見つかることもあります。
DNS の詳細調査＋メールセキュリティ — SPF／DMARC の不備はメールのなりすましを可能にします。TXT 検証トークンから SaaS テナントが判明することもあります。
証明書 — CT ログのタイムラインから忘れられたサブドメインが見つかります。脆弱な暗号スイートは簡単に発見できます。
ASN＋逆引き DNS — 企業の IP アドレス空間には、公開されていないインフラが存在します。
WHOIS — 登録者の個人情報から、関連する企業資産が判明することがあります。
タイポスクワット — すでに登録されているスクワットドメインは調査結果として報告できます。未登録のものはフィッシングドメイン候補リストに加えます。
セキュリティヘッダー — 単独での価値は低いものの、クライアント向けレポートには必要です。

7.6 時間配分とエンゲージメントのプロファイル

ステージとアセット数によって、偵察にかかる時間は変わります。以下は一般的な SaaS 形式のターゲットを、1 人で調査する場合のおおよその見積もりです。

ステージ	小規模組織（従業員 100 人未満）	中規模（100～1K）	大規模（1K 以上）
1. シードの特定	30 分	30 分	30 分
2. アセットの拡張	1～2 時間	2～4 時間	4～8 時間
3. エンリッチメント（稼働中の Web アプリ 100 件あたり）	約 1 時間	約 1 時間	約 1 時間
4. 露出状況の分析	1～3 時間	3～6 時間	6～12 時間
5. レポート作成	2～4 時間	4～8 時間	1～2 日

エンゲージメントのプロファイル：

1 時間の迅速な偵察（「X はどれくらい露出しているか？」） — ステージ 1（15 分）→ パッシブなサブドメイン調査（crt.sh ＋ Subfinder、10 分）→ 解決済み IP に対する Shodan InternetDB（5 分）→ Hunter＋IntelX によるメールアドレス収集（10 分）→ 収集したメールアドレスの情報漏えい調査（10 分）→ 経営幹部向け要約のみを出力（10 分）。
4 時間の重点的な偵察（「フィッシング対応準備状況の確認」） — 次の調査を追加します。メールアドレスの完全な収集、LinkedIn による従業員の列挙、SPF／DMARC 分析、タイポスクワット候補の生成、SSO／IdP のフィンガープリンティング。出力：フィッシング実行可能性レポート＋ターゲットのメールアドレス一覧。
標準的な 1 日の偵察 — 上記の優先順位に従い、ステージ 1～4 をすべて実施します。出力：アセットごとの発見事項一覧＋アセットグラフ＋経営幹部向け要約。
1 週間の詳細な偵察 — 標準的な調査をすべて実施したうえで、次を追加します。詳細モードでのユーザー列挙、最大予算での JavaScript 詳細分析、モバイルの攻撃対象領域、クラウドネイティブのフィンガープリンティング、ベンダー製品のフィンガープリンティング、パッケージレジストリにおける情報漏えいの調査、脆弱性の優先順位付け。出力：クライアント向け成果物一式＋再現用バンドル。
継続的な監視（週次差分） — ステージ 1～3 を毎週再実行し、ベースラインとの差分を取り、新しいアセット／発見事項やアセットの消失があればアラートを出します。

早期に中止する場合：

ステージ 1 の後にスコープが誤っていると判明した場合（ターゲットが無関係な企業の子会社だと判明した場合や、エンゲージメントのルールを明確にする必要がある場合）。
ステージ 2 の後に攻撃対象領域がしきい値を下回っている場合（公開 Web アプリがなく、露出サービスもなく、漏えいしたメールアドレスもない場合、外部から見つけられるものはほとんどありません）。
いずれかのステージで §6.4 に示す WAF／検知の兆候が見られた場合。

8. アセットグラフの規律

発見したものはすべて、宙に浮いた文字列としてではなく、グラフ内の型付きアセットとして扱います。

8.1 アセット分類（29 種類）

カテゴリ	アセットの種類
DNS / ネットワーク	`domain`, `subdomain`, `ip`, `netblock`, `asn`
サービス	`port`, `service`, `certificate`
ID	`email`, `person`, `credential`
コード / 設定	`repo`, `secret`
クラウド / ストレージ	`bucket`, `firebase_project`
Web	`webapp`, `wayback_endpoint`, `api_endpoint`, `api_spec`, `graphql_schema`
モバイル	`mobile_app`, `deep_link`, `exported_component`
フィッシング / 敵対的活動	`typosquat_domain`
コラボレーション / SaaS	`postman_collection`, `postman_workspace`, `postman_api_key`, `stack_post`, `saas_public_surface`

8.2 アセットスキーマ

各アセットには以下が含まれます。

type — 上記 29 種類のいずれかです。
key — 一意の重複排除 ID です（型のプレフィックス付き。例：sub:api.example.com、email:[email protected]）。
value — 実際の文字列またはオブジェクトです。
sources[] — このアセットを確認したすべてのソースです（重複排除済み）。
confidence — TENTATIVE / FIRM / CONFIRMED です。
first_seen、last_seen — UTC のタイムスタンプです。
attrs{} — 型固有のメタデータです（例：webapp の場合は status_code、title、tech-stack リスト、JARM、favicon mmh3、スクリーンショットのパス）。

8.3 エッジ分類

関係はテキストではなく、型付きのエッジです。 RESOLVES_TO、HOSTED_ON、IN_NETBLOCK、BELONGS_TO_ASN、LISTED_IN_CERT、OWNED_BY、ALIAS_OF、BREACHED_FROM、EMPLOYED_BY、HOSTS_REPO、TYPOSQUAT_OF、EXPOSES、DOCUMENTED_BY、BELONGS_TO_HOST、REQUIRES_AUTH、LEAKS_SCHEMA、SHIPPED_BY_ORG、CONTAINS_SECRET、TALKS_TO_HOST、EXPOSES_DEEPLINK、HAS_EXPORTED_COMPONENT、USES_FIREBASE_PROJECT、LACKS_PINNING_FOR。

8.4 運用ルール

すべての発見をアセットにします。 孤立した文字列に対して調査結果を記録せず、まずアセットを作成してから調査結果を関連付けます。
値ではなくキーで重複排除します。 同じ値でも型が異なれば、別のアセットです（sub:api.example.com と webapp:https://api.example.com/ は別のアセットで、BELONGS_TO_HOST エッジで関連付けられます）。
来歴は必須です。 sources[] にはすべてのソースを記載する必要があります。2 つのソースで確認された場合は、両方を記載します。
信頼度はソースごとに判定し、その後に集約します。 3 つのパッシブソースから返されたサブドメインは FIRM です。Bing のスニペットのみで返されたものは TENTATIVE です。
サイドカーによる遅延バインディングを行います。 モジュール A の出力をモジュール B が必要とする場合は、JSON サイドカー（mobile_endpoints.json、secrets_sidecar.json）を書き込みます。モジュール B がモジュール A を待つ状態にしないでください。§24 を参照してください。

8.5 アセットレベルのトリアージルール

さまざまなアセットが混在し、調査の予算が限られている場合は、各アセットが可能にすることを基準に優先順位を付けます。

ホスト名のシグナルに基づく WebApp の優先順位（高い順）：

認証関連のホスト名（auth., login., sso., idp., accounts., oauth.）。
管理用パス（/admin, /dashboard, /console, /manager, /wp-admin, /phpmyadmin）。
開発／ステージング用ホスト（dev., staging., stg., qa., uat., test., sandbox., preprod., preview.）— 防御が弱く、本番データが流出していることもよくあります。
API ホスト名（api., services., gateway., graph.）。
顧客向けホスト名（portal., app., my., account.）。
マーケティング／コンテンツ（www., blog., news., careers., support.）。

推定される機能に基づくサブドメインの優先順位：

API > Admin > Dev > Auth > Prod-app > Marketing。

ネットブロックに基づく IP の優先順位：

企業の ASN が所有するもの（告知されていない内部インフラをホストしている可能性が最も高い）。
クラウドのネットブロック（AWS / GCP / Azure / DO / OVH）— 入れ替わりが激しいものの、クラウドネイティブサービスを見つけるうえで有益です。
CDN の範囲（Cloudflare / Akamai / Fastly）— 通常はオリジンではなくエッジです。オリジンの特定を行う場合を除き、後回しにします。

役職のヒントに基づくメールアドレスの優先順位：

役職を示す文字列	優先度	理由
`ceo@`, `cfo@`, `cto@`, `ciso@`	最高	役員アカウントは侵害時の価値が最も高くなります（BEC、財務上の権限、取締役会へのアクセス）。
`it@`, `helpdesk@`, `support@`, `security@`	高	IT／セキュリティアカウントは特権的なツールにアクセスでき、ヘルプデスクアカウントはパスワードリセットのワークフローを扱います。
`dev`, `engineer`, `architect`, `dba`	中	開発者アカウントは GitHub／クラウド／CI にアクセスできることがよくあります。
`sales`, `marketing`, `hr`, `finance`	中	SaaS（Salesforce、HubSpot、Workday）へのアクセスがあり、財務部門は BEC を可能にします。
汎用的な役職アカウント（`info@`, `noreply@`, `contact@`）	低	監視されていないか、エイリアスから転送されていることが多く、個人に関する情報も少ない傾向があります。

更新時期と命名に基づくリポジトリの優先順位：

最近プッシュされたもの（過去 30 日以内）> 古いもの。
説明に対象名が含まれる公開リポジトリ > コードにのみ対象名が含まれるもの。
内部用に見える親リポジトリからフォークされたもの > 単独のリポジトリ。
名前に prod, internal, private, secret が含まれるものは、公開されていても優先度は高です（誤った名前が付けられているか、誤って公開された可能性があります）。

適用順序： アセットが N 個あり、調査できるのが M 個（M < N）の場合、まずアセット種別ごとの優先順位を適用し、次に種別内の優先順位を適用します。例：サブドメインが 50 個ある場合、まず API + 管理用 + 開発用を調査し（約 15 個）、次に認証 + 本番アプリを調査して（約 20 個）、マーケティング／コンテンツは次の段階に回します。

9. 検出事項の評価基準と重大度の対応付け

重大度は主観的なものではなく、運用上のものです。次の基準を使用してください。

9.1 CRITICAL

認証前のコード実行、有効な認証情報の確認、本番データの一覧取得、根本的な信頼の侵害。

例：

本番 WebApp で .git/config が公開されている（ソースコード全体の開示）。
/.env が公開されている（認証情報が平文で記載されており、多くの場合、DB／クラウド／API の情報を含みます）。
Spring Boot の /actuator/env または /actuator/heapdump に認証なしでアクセスできる。
ユーザーデータを含む S3 / GCS / Azure バケットの一覧を取得できる。
認証なしで、状態を変更する書き込みエンドポイントに POST/PUT/DELETE できる。
Firebase Realtime Database が公開されている（https://{project}.firebaseio.com/.json がデータを返す）。
本番 Android アプリで android:debuggable=true が設定されている。
広範な権限を持つ有効性確認済みの認証情報（PMAK、AWS キー、Anthropic/OpenAI キー）。
漏えいデータセット内で 10 人以上の従業員が侵害され、そのテナントも特定されている（SSO_EXPOSURE）。
Elasticsearch クラスターが公開されている（/_cat/indices がデータを返す）。
Docker API が公開されている（/v1.40/containers/json がコンテナを返す）。
Redis が公開されている（AUTH なしで、authorized_keys に書き込み可能）。
匿名認証が有効な Kubernetes API サーバーが公開されている。
kubelet の 10250 番ポートが公開されている（認証なしで Pod を実行可能）。
etcd の 2379 番ポートが公開されている（クラスターの状態とシークレットを取得可能）。
BlueKeep に脆弱な RDP、EternalBlue に脆弱な SMB。
特定のバージョンに該当する RCE CVE を持つ Citrix Netscaler / F5 BIG-IP。

9.2 HIGH

重大な露出ですが、まだ RCE には至らず、明確な権限昇格の経路がある、または価値の高い情報が漏えいしています。

例：

GitHub リポジトリでシークレットが公開されている（PAT、AWS キー、Slack トークンなど）。
ソースマップ（.js.map）にアクセスできる — フロントエンドの元のソースコードがすべて漏えいします。
本番環境で GraphQL のイントロスペクションが有効になっている（スキーマ全体が漏えいし、列挙からミューテーションにつながる）。
サブドメインテイクオーバーが可能（CNAME が未取得の Heroku／Shopify などを指している）。
認証情報付きの反射型 CORS（Access-Control-Allow-Origin: <reflected> ＋ Access-Control-Allow-Credentials: true）。
メソッドの改ざん：公開上は GET のみ許可されているエンドポイントで、隠れた DELETE／PATCH が使える。
機密性の高いパス（/login、/sso、/admin、/auth）で HSTS が未設定 — MED から引き上げ。
Jenkins／Tomcat-Manager／phpMyAdmin の管理 UI が公開されている（認証なし、またはデフォルトの認証情報）。
Telnet（ポート 23）に到達できる。
モバイルアプリに JS ブリッジ付き WebView がある（XSS から RCE につながる可能性）。
モバイルアプリに機密性の高いディープリンクハンドラーがある。
本番のメール送信ドメインで DMARC ポリシーが p=none（なりすましが可能）。
既知の未修正 CVE があるベンダー製品のバナーが確認された（KEV に掲載）。

9.3 MEDIUM

情報漏えい、セキュリティ強化の不備、ブルートフォース攻撃への露出。

例：

一般的なページでセキュリティヘッダーが未設定：HSTS、CSP。
Apache の /server-status または /server-info にアクセスできる。
開発／ステージング環境でのみ phpinfo() または /info.php にアクセスできる。
JS 内で内部 IP／ホスト名／K8s サービス DNS が漏えいしている。
エラーページでスキーマが漏えいしている（スタックトレース、ORM のシグネチャ）。
Android アプリで android:allowBackup=true が設定されている。
Android アプリで android:usesCleartextTraffic=true が設定されている。
android:permission による保護がないエクスポート済みアクティビティ／サービス。
API エンドポイントにレート制限がない。
ユーザーに紐づくデータを返す API でワイルドカード CORS（Access-Control-Allow-Origin: *）が設定されている（認証情報なし）。
Slack の Webhook URL が漏えいしている。
Twilio の Account SID が漏えいしている（認証トークンなし）。
SPF レコードの許可範囲が広すぎる（+all または多数の include）。

9.4 LOW

見た目上の問題、または影響の小さいセキュリティ強化の不備。

例：

X-Frame-Options が未設定。
X-Content-Type-Options が未設定。
.DS_Store が公開されている。
Stripe のテスト用キーが漏えいしている。
Firebase の URL が公開されている（URL のみで、公開された RTDB はない）。
モバイルアプリで証明書ピンニングがない。
古い WordPress のインストールが検出された（既知のエクスプロイトはまだない）。
BIMI が設定されていない（ブランドなりすましのリスクのみ）。

9.5 INFO

記録する価値はありますが、直ちに対応する必要はありません。

例：

Referrer-Policy／Permissions-Policy が未設定。
/.well-known/security.txt が見つかった。
robots.txt に興味深いパスが記載されている。
プライベートバケットが存在するが、アクセス制限されている。
従業員アカウントが 0 件のドメインが、漏えいデータのコーパスで検出された。
DNSSEC が有効になっていない。

9.6 重大度の引き上げルール

認証／ログイン／SSO／管理者用パスで HSTS が未設定 → MED → HIGH。
ワイルドカード CORS ＋認証情報 → MED → HIGH。
ワイルドカード CORS ＋機密性の高いエンドポイント → LOW → MED。
関心度の評価基準（関連スキル §20）でスコアが 70 以上の API エンドポイント → 少なくとも HIGH。
ドメインの漏えいで従業員が 10 人以上に影響 → 古いデータに関する留保にかかわらず CRITICAL。
ベンダー製品のバージョンが CISA KEV の項目と一致 → CRITICAL。
DMARC が p=reject ＋ SPF が厳格＋ DKIM がローテーション済み → 引き上げなし。適切に保護されています。

10. バグバウンティ／レッドチームの切り替えモード

既存の調査活動（脅威アクターの調査、個人情報の特定、帰属分析）は、攻撃的な偵察とは異なる姿勢で行います。姿勢は明示的に切り替えてください。

項目	調査モード	攻撃的偵察モード
プロービングの頻度	ゆっくりと単一スレッドで行い、通常のトラフィックに紛れ込ませます。	バースト的かつ並列に行いますが、プロバイダーごとにレート制限を設けます。
OpSec の姿勢	捨てアカウントのみを使用し、調査者の身元は決して明かしません。	エンゲージメント用のペルソナを使う場合があります。チームが SOC に通知する場合もあります。
証拠の取り扱い	裁判で通用する証拠保全の連鎖を確保します。ハッシュ、タイムスタンプ、スクリーンショットを記録します。	エンゲージメントで通用する水準とします。同じくハッシュとタイムスタンプを厳密に記録しますが、証拠はクライアント向けレポートに使用します。
対象範囲内の深刻度	文脈に関係するすべての深刻度レベルを対象にします。	CRIT／HIGH／MED を重視します。LOW／INFO は多くの場合、エグゼクティブサマリーから省きます。
許可に関する姿勢	公開記録／OSINT のみを対象とし、許可なしに非公開リソースをプロービングしません。	書面によるルール・オブ・エンゲージメント、明示的な対象範囲、明示的な対象外リストを用意します。
レポート形式	説明文と出典付きの時系列です。	アセットごとの検出事項、修正方法、再現手順です。
停止条件	問いに答えられたときです。	エンゲージメント期間が終了したとき、またはレポートを提出したときです。

ユーザーと作業する際、文脈からモードが明らかでない場合は、どちらのモードかを確認してください。

10.1 規模に応じた戦術

組織の規模によって、効果的な手法は変わります。

小規模組織（従業員 100 人未満）：

経営幹部のアカウントは不釣り合いなほど重要です。CEO／CFO のアカウントを 1 つ侵害するだけで、ほぼすべての鍵を握れることがよくあります。
メールアドレスの収集対象が少ないため、漏れなく列挙できます（合計 10～50 件）。
Microsoft 365 または Google Workspace の可能性が高く、アイデンティティファブリックは 1 つのテナントです。
コードリポジトリは、創業者が個人開発から移行した経緯から、GitHub の個人アカウントで公開されていることがよくあります。
クラウド環境は、AWS の単一アカウントまたは GCP プロジェクトであることがよくあります。
戦術：すべてのメールアドレスとアイデンティティファブリックに関する検出事項を徹底的に調査します。LinkedIn を完全に列挙し、創業者の個人用 GitHub 組織を確認します。

中規模組織（100～1K）：

バランスよく列挙します。メールアドレスのリストは列挙できますが、網羅的ではありません。
アイデンティティファブリックは 1 つの IdP が中心でありながら、複数の SaaS テナント（Slack ワークスペース、Notion 組織、GitHub 組織）を持つ可能性が高いです。
モバイルアプリがある場合があるため、両方のストアを確認します。
クラウド環境は、複数アカウントまたは複数リージョンにまたがる可能性があります。
戦術：標準的な深度でパイプライン全体を実施します。各アセットクラスをサンプリングしてから深掘りし、役割に応じて LinkedIn の優先順位を付けます。

大規模組織（1K～10K）：

メールアドレスの列挙は不完全になり、上位の役割をサンプリングするようになります。侵害データの件数も増加します。
アイデンティティファブリックは複数テナントにまたがります（多くの場合、Entra と Okta に加え、複数の Auth0 顧客を含みます）。
モバイルアプリがあり、異なるチームによる複数の Android パッケージが存在する場合があります。
クラウド環境は広範囲にわたり、子会社や買収によって対象範囲が複雑になります。
戦術：幅を優先して調査します。アセットの発見には自動化を活用し、検出事項のトリアージは手動で行います。

超大規模組織（10K 以上）またはコングロマリット：

まず、ブランドドメインとすべての子会社を列挙するブランド起点のマップを作成します。
侵害データのコーパスが調査の中心となります。従業員が 10K 人以上いると、過去の侵害による大きな露出が見込まれます。
アイデンティティファブリックは事業部門ごとに異なる場合があります（法人境界によるものです）。
戦術：スコープの絞り込みが最も重要です。全工程でサンプリングと自動化を活用し、優先度の高い検出事項のみを深掘りします。

規模を問わない原則： 組織が小さいほど、個々のアカウントに焦点を当てる効果が高まります。組織が大きいほど、システム全体の姿勢に関する検出事項（DMARC の不備、SSO_EXPOSURE の広がり、ベンダー製品バージョンの一斉調査）の効果が高まります。

11. アイデンティティファブリックのマッピング

組織の IdP／SSO の姿勢は価値の高い標的です。アイデンティティファブリックを侵害すれば、個々のアプリに侵入する必要はありません。手順を踏んでマッピングしてください。

11.1 サブドメインのプレフィックス列挙

対象のルートドメイン（および発見済みの兄弟ブランドドメイン）に対して、以下のプレフィックスをプロービングします。

auth.{domain}
login.{domain}
sso.{domain}
idp.{domain}
iam.{domain}
identity.{domain}
accounts.{domain}
oauth.{domain}

さらに、応答があるすべてのサブドメインで、汎用 OIDC ディスカバリーを実行します。

{any-host}/.well-known/openid-configuration

11.2 Microsoft Entra (Azure AD)

OIDC メタデータ＋テナント GUID の抽出 — https://login.microsoftonline.com/{tenant-or-domain}/.well-known/openid-configuration を取得します。issuer フィールドにはテナント GUID を含む URL が返されます（8-4-4-4-12 の 16 進数形式）。テナント GUID とドメインを組み合わせると、安定したテナントフィンガープリントになります。
getuserrealm.srf — https://login.microsoftonline.com/getuserrealm.srf?login=<user>@<domain> は NameSpaceType として、Managed（クラウドネイティブ）、Federated（オンプレミスの ADFS／外部 IdP）、または Unknown を返します。検出可能性：低。
Autodiscover v2 — https://autodiscover-s.outlook.com/autodiscover/metadata/json/1 にメールアドレスを POST すると、テナントへの所属を検出します。
GetCredentialType（詳細モードのユーザー列挙） — https://login.microsoftonline.com/common/GetCredentialType に {"username": "<email>"} を POST します。レスポンスから、そのメールアドレスがテナントに存在するかどうかが分かります。検出可能性：中。テナントあたり最大 20 回までに制限してください。

11.3 Okta

組織スラッグの導出 — サブドメインとルートドメインの語幹から候補スラッグを導出します。Okta テナントは <slug>.okta.com（または <slug>.oktapreview.com）で提供されています。
OIDC フィンガープリント — https://<slug>.okta.com/.well-known/openid-configuration。
/api/v1/authn のユーザー列挙（詳細モード） — {"username": "<email>", "password": "invalid"} を POST します。400 と 401 のレスポンスコードの違いから、ユーザーの存在が分かります。検出可能性：中。テナントあたり最大 20 回までに制限してください。

11.4 ADFS

パッシブフィンガープリント — https://{domain}/adfs/idpinitiatedsignon.aspx に GET を送信し、200 が返れば ADFS が存在します。
アクティブな MEX エンドポイント（詳細モード） — https://{domain}/adfs/Services/Trust/mex は SOAP メタデータを返します。

11.5 Google Workspace

https://{domain}/.well-known/openid-configuration — Google ホストドメインの顧客は、特徴的な issuer／JWKS URI を持つディスカバリーエンドポイントを公開します。
MX レコードが *.googlemail.com／aspmx.l.google.com を指している場合は、Google Workspace である可能性が高いことを示します。

11.6 汎用 OIDC（Keycloak／Auth0／Ping／OneLogin／Duo）

稼働中のすべてのサブドメインで /.well-known/openid-configuration をプローブします。
issuer フィールドと authorization_endpoint フィールドから IdP 製品を特定できます。
*.auth0.com、*.onelogin.com、*.pingone.com、*.duosecurity.com のパターンは特徴的です。

11.7 SAML メタデータ

稼働中のすべての Web アプリで以下のパスをプローブします。

/saml/metadata
/FederationMetadata/2007-06/FederationMetadata.xml
/federationmetadata/2007-06/federationmetadata.xml
/simplesaml/saml2/idp/metadata.php
/auth/saml2/metadata

SAML メタデータ XML には、EntityID、署名証明書、SingleSignOnService URL、NameIDFormat が含まれます。

11.8 AWS アカウント ID の抽出

S3 バケットのリージョンヘッダー — 既知の対象バケットに HEAD リクエストを送信すると、x-amz-bucket-region が返されます。これをバケット名のエントロピーと照合し、アカウントを推定します。
JSON／HTML レスポンス内の ARN 正規表現 — arn:aws:[a-z0-9-]+:[a-z0-9-]*:([0-9]{12}): を検索します（12 桁の AWS アカウント ID がキャプチャグループです）。
JS／API レスポンス内の AccountId プロパティ — IAM 関連のエラーメッセージや CloudFormation の出力によく含まれます。
OAuth の client_id 漏えい — Google OAuth：<digits>-<chars>.apps.googleusercontent.com、MSAL：clientId プロパティ内の GUID。

11.9 出力

検出された各 IdP は、attrs.product、attrs.tenant_id、attrs.discovery_endpoint を持つ Service アセットになります。その後、ステージ 4 で漏えいデータと照合します。検出されたテナント内の侵害されたユーザーはすべて SSO_EXPOSURE の検出結果になります（CRITICAL — §22.3 を参照）。

11.10 Microsoft 365 の広範な攻撃対象領域

Entra の基本的なフィンガープリンティングにとどまらず、M365 にはより広範な攻撃対象領域があり、詳細に列挙する価値があります。

Teams フェデレーション：

https://login.microsoftonline.com/<target-domain>/.well-known/openid-configuration でテナントを確認できます。
Teams のフェデレーション状態：https://teams.microsoft.com/api/mt/<region>/beta/users/<email>/externalsearchv3（フェデレーションされたテナントからの認証済みリクエストが必要です。外部との Teams チャットが許可されているか確認するのに役立ちます）。
外部チャットが有効＝ソフト攻撃の対象領域です（Teams チャットを通じたビッシング、スミッシング、「IT 部門を装う」口実）。
オープンフェデレーション（どのテナントともチャット可能）がデフォルトです。対象が制限しているか確認してください。

SharePoint のサブドメイン：

<target-stem>.sharepoint.com — テナントのメイン SharePoint。
<target-stem>-my.sharepoint.com — OneDrive for Business の URL（ユーザーごとの個人サイト）。
<target-stem>-admin.sharepoint.com — SharePoint 管理センター（認証が必要ですが、存在すればテナントを確認できます）。
<target-stem> は会社名から導出します（多くの場合、.com より前の部分です）。

OneDrive 個人サイトの列挙：

ユーザーごとの OneDrive URL：https://<target-stem>-my.sharepoint.com/personal/<user_email_with_underscore>/Documents/。
メールアドレスの @ と . を _ に置き換えます（例：[email protected] → alice_acme_com）。
認証済みのプローブです。OneDrive 個人サイトがプロビジョニングされているか確認するのに役立ちます（それ自体が存在を示す指標になります）。

M365 OAuth の client_id の発見：

多くの社内アプリは、Entra に OAuth client_id を登録しています。JS バンドル、モバイルアプリの文字列、API レスポンスから client_id=<GUID> パターンを検索します。
Office や Graph など、Microsoft の既知のファーストパーティ client_id は公開されています。Microsoft 以外の GUID を見つければ、カスタム社内アプリが明らかになります。
エンドポイント https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration には、サポートされているエンドポイントが記載されています。一部のテナントでは device_authorization_endpoint が有効なままです（デバイスコードフィッシングの標的）。

Power Platform／Power Apps：

https://make.powerapps.com/environments（認証が必要です）。環境 ID が URL に漏れていることがあります。
*.crm.dynamics.com（Dynamics 365／Power Apps のデフォルト URL）。
App Service のデプロイ先となる *.azurewebsites.net。

確認すべき M365 OAuth の設定ミス：

common テナントで device_authorization_endpoint が有効（デバイスコードフィッシングの標的）→ 中（運用上のリスクです。直接悪用できるわけではありませんが、攻撃を可能にします）。
Public client フローが有効で、広範なスコープ（offline_access、Mail.Read、Files.Read.All）を持つカスタム OAuth アプリ → テナントでアプリが承認済みの場合は高。
対象が公開しているマルチテナント OAuth アプリ（他のユーザーも同意可能）→ スコープに Graph の機密性の高いアクセス許可が含まれているか確認します。

検知可能性： すべての M365 エンドポイントへのプローブは、Entra のサインインログ／監査ログに記録されます（取得のみの場合は中〜低、認証を試みる場合は中）。

12. API と認証マップの手法

現代の対象では、REST、GraphQL、文書化されていない内部 API が公開されています。OSINT の目的は、それらを列挙して分類し、攻撃対象としての関心度に基づいて順位付けすることです。

12.1 検出パス

Swagger / OpenAPI — すべての稼働中の Web アプリに対し、28 パスのワードリスト（コンパニオンスキル §16.1）をプローブします。YAML/JSON を解析し、すべてのエンドポイント（メソッド＋パス）を抽出します。
GraphQL — 13 パスのワードリスト（コンパニオンスキル §16.2）をプローブします。標準のイントロスペクションクエリを POST します。スキーマが返された場合は、型／クエリ／ミューテーション／サブスクリプションをすべて列挙できます。
イントロスペクションが無効な場合の GraphQL — フィールド候補の列挙（コンパニオンスキル §22.9）に切り替えます。
Postman — 対象名を指定して Postman の公開ユニバーサル検索エンドポイントにクエリを送信し、一致する各ワークスペースを調べます。リクエスト、ヘッダー、リクエスト前スクリプト、テストスクリプト、環境変数を抽出します。
JS から抽出したエンドポイント — JavaScript バンドルから抽出したすべてのエンドポイントを、同じ分類器に渡します。
モバイルから抽出したエンドポイント — APK の静的解析で検出したすべてのエンドポイントを、サイドカー（mobile_endpoints.json）経由で渡します。

12.2 分類

各エンドポイントについて、以下を記録します。

url, method, source[], auth_required, auth_type, auth_location,
rate_limited, cors_policy, sensitive_path_keywords[], schema_leaks,
verb_tampering_possible, interest_score (0..100), interest_reasons[]

各フィールドの判定方法：

OPTIONS を送信します → Allow ヘッダーから、サポートされているメソッドが分かります（動詞改ざんの確認）。
認証なしで GET を送信します → 200 は auth_required=false、401/403 は auth_required=true です。
WWW-Authenticate（auth_type）、RateLimit-* / X-RateLimit-* を確認するため、レスポンスヘッダーを取得します。
Origin: https://attacker.example を指定したリクエストを送信します → レスポンスの Access-Control-Allow-Origin に値が反映される場合は、cors_policy=reflected です。
エラーを発生させます → スタックトレースや ORM のヒントがレスポンスに含まれていないか確認します。

12.3 関心度スコア（0～100）

完全な評価基準については、コンパニオンスキル §20 を参照してください。スコアが 70 以上の場合は、エビデンスに attack_path_hint を含めた HIGH/CRITICAL の検出結果とします。

12.4 攻撃パスのヒント

HIGH/CRITICAL の検出結果を出力する際は、オペレーターが悪用を開始する場所を把握できるよう、エビデンスに攻撃パスのヒントを一文で含めます。テンプレートはコンパニオンスキル §39 にあります。

13. JavaScript の詳細分析

稼働中のすべての Web アプリから JavaScript を取得します。最新のフロントエンドから情報が漏れていることが多いためです。

13.1 スクリプトの検出

HTML を解析して、<script src="..."> と <link rel="modulepreload" href="..."> を検出します。
一般的なバンドラー向けに、パス推測リスト（コンパニオンスキル §16.9）をプローブします。

13.2 ソースマップの検出（重大度：HIGH の情報漏えい）

インライン参照：バンドル末尾にある //[#@]\s*sourceMappingURL= に一致する正規表現を使用します。
隣接ファイルの取得：検出したすべての JavaScript と同じ場所にある <bundle>.map を取得します。
アクセスできる場合：ソースマップの sources[]（リポジトリ構造が漏えいします）と sourcesContent[]（元のソースコード全体が埋め込まれています）を解析します。sourcesContent[] に対してシークレットカタログを実行します。
重大度：HIGH INFO_DISCLOSURE。

13.3 シークレットスキャン

すべての JavaScript 本文と、解析したすべての sourcesContent[] のデータに対し、29 種類以上のパターンカタログ（コンパニオンスキル §17）を実行します。検出結果ごとに、カタログで定められたパターン別の重大度を設定した SECRET_LEAK 検出結果を作成します。

13.4 エンドポイントの抽出

3 段階の正規表現（コンパニオンスキル §16.10）を使用します。一意のエンドポイントはそれぞれ wayback_endpoint アセットとなり、§12 の API 分類器に渡されます。

13.5 内部ホスト漏えいの検出

3 種類のパターン（コンパニオンスキル §16.11）を使用します。RFC1918、内部 DNS サフィックス、K8s サービス DNS が対象です。一致するごとに、MEDIUM INFO_DISCLOSURE とします。

13.6 GraphQL イントロスペクションプローブ

抽出したエンドポイントが /graphql または /graphiql で終わる場合、標準のイントロスペクションクエリを POST します。スキーマが返された場合は HIGH MISCONFIG とします。その後、価値の高い対象となるミューテーションとサブスクリプションを列挙します。

13.7 Next.js マニフェストの解析

_buildManifest.js と _ssgManifest.js は、すべての Next.js ページルートを列挙します。これにより、アプリケーションのルート構造全体が明らかになります。

13.8 予算のガイドライン

エンゲージメントごとに分析する Web アプリの上限：デフォルトは 40、--deep 使用時は 120。
Web アプリごとの JavaScript ファイル数の上限：デフォルトは 40、--deep 使用時は 80。
JavaScript ファイル個別のサイズ上限：2 MiB。
ファイルごとのタイムアウト：10 秒。

14. モバイル攻撃対象領域

モバイルアプリは、最も脆弱なリンクであることが少なくありません。

14.1 アプリの検出

Android — google-play-scraper を使用します。会社名、ブランドのキーワード、ルートドメインの語幹で検索します。
iOS — iTunes Search API を使用します。

14.2 所有権の確信度（0–100）

関連スキル §21 を参照してください。詳細な分析のしきい値：≥70。

14.3 APK の取得＋静的解析

APKPure の HTML スクレイピングでダウンロードします。
zipfile と、必要に応じて androguard で展開します。
取得対象：AndroidManifest.xml、リソース文字列、アセットファイル、ネイティブ .so ファイル、classes*.dex（文字列を抽出）。

14.4 シークレットスキャン

マニフェスト、リソース、アセットファイル、dex の文字列抽出出力に対してカタログを実行します。

14.5 バックエンドのホスト名抽出

検出したホスト名はすべて subdomain アセットになります。API 検出モジュールが読み込めるように、サイドカー mobile_endpoints.json を書き出します。

14.6 マニフェストの設定ミスに関する検出結果

マニフェスト属性	重大度
`android:debuggable="true"`	CRITICAL
`android:allowBackup="true"`（ホワイトリストなし）	MEDIUM
`android:usesCleartextTraffic="true"`	MEDIUM
`android:permission` の指定がないエクスポート済みのアクティビティ／サービス／レシーバー	MEDIUM
機密性の高いディープリンクハンドラー	HIGH
`setJavaScriptEnabled(true)` + `addJavascriptInterface(...)` を使用する WebView	HIGH
証明書ピンニングがない	LOW

14.7 Firebase の標準プローブ

抽出した Firebase プロジェクト ID ごとに、次を実行します。

Realtime DB — GET https://{project-id}.firebaseio.com/.json。JSON ツリーが返された場合は → CRITICAL OPEN_FIREBASE_RTDB。
Firestore — https://{project-id}.firebaseapp.com/。
Storage — 対応する GCS バケット。
Remote Config — 抽出した API キーとアプリ ID がある場合にのみ読み取り可能です。

14.8 iOS の手順

検出は iTunes Search API 経由のみです。
ITMS リンクの抽出先：https://apps.apple.com/<region>/app/<slug>/id<bundle-id>。
プライバシー栄養ラベル（App Store Connect）：一般公開されており、アプリが扱うデータを把握するのに役立ちます。
自動ダウンロードは推奨しないでください（DMCA／DRM に関する考慮事項）。

15. クラウドの攻撃対象領域

15.1 バケット名の組み合わせ

ターゲットのルートドメイン、サブドメインの語幹、任意のブランド名／会社名から、候補となるバケット名を作成します。ターゲットを特定するトークンと組み合わせていない一般的な語幹は除外します。6 個のプレフィックス × 15 個のサフィックスを適用します（一覧は関連スキル §16.8 を参照）。

15.2 プロバイダーの URL テンプレート

S3、GCS、Azure Blob のテンプレートについては、関連スキル §16.8 を参照してください。

15.3 プローブ手法

まず HEAD を実行します。ステータスコード 200／301 = 存在、403 = 存在するが非公開、404 = スキップ。
存在する場合は、バケットのルートに GET を実行します。XML／JSON の一覧を取得できる場合 → CRITICAL。

15.4 重大度のマッピング

結果	重大度
バケットの一覧を取得可能	CRITICAL
バケットが存在し、直接 URL からオブジェクトを読み取れるが、一覧は取得できない	HIGH
バケットが存在し、ACL が非公開	INFO

15.5 クラウドに関連する追加のシグナル

S3 のリージョン／エラーレスポンスから AWS アカウント ID を抽出します。GCS のエラーレスポンスから GCP プロジェクト ID を抽出します。Blob URL のパターンから Azure テナント ID を抽出します。

16. 暗号資産の調査

16.1 トランザクション分析

ウォレット間の資金の流れを追跡し、関連するアドレスのクラスターを特定して、大規模な送金を監視します。

ツール：Cielo（マルチチェーン）、TRM（グラフ）、Arkham（マルチチェーン＋エンティティラベル）、MetaSleuth（ビジュアル分析）、Range（CCTP）、Socketscan（EVM ブリッジ）、Pulsy（ブリッジアグリゲーター）、Chainalysis Horizon 2.0（有料）、Elliptic Lens。

16.2 レイヤー 2／ロールアップ分析

zkSync Era / Polygon zkEVM — ZK 証明により L2 の詳細が隠され、L1 のブリッジイベントのみ確認できます。
Arbitrum / Optimism — バッチ処理／圧縮されており、L2 の状態は L1 の calldata から確認します。
StarkNet — Cairo VM を使用し、アドレス導出方式が異なります。
Base / Blast / Scroll — OP Stack または ZK。
L2 上のプライバシープロトコル — Aztec（プログラム可能なプライバシー）、Railgun（シールドプール）、Privacy Pools（Tornado Cash の後継）。

方法論： L1 のブリッジイベントから調査を始め、ロールアップ内のアクティビティには L2 エクスプローラーを使用します。プライバシープロトコルについては、タイミング分析とクラスタリングに重点を置きます。

16.3 注意事項

ブリッジではミント／バーンの動作が発生するため、1 対 1 の資金フローを前提にしないでください。
MEV／アグリゲーター経由の経路により、誤った「直接」追跡が発生する可能性があります。
L2 のファイナリティ：オプティミスティックロールアップには 7 日間のチャレンジ期間があります。

16.4 ウォレット／取引所／NFT のプロファイリング

基本的なパターンは同じです。経過年数＋アクティビティ＋つながり＋残高の推移＋連携アカウントです。NFT では、所有履歴＋メタデータ＋接続済みウォレットも確認します。

17. 画像分析

17.1 画像の逆検索

Google Images／Lens（Lens では認証が必要な場合があります。使い捨てアカウントでシークレットモードを使用してください）。
Yandex Images（ロシア語圏／東欧のコンテンツに最も強力です）。
Bing Image Match、TinEye、Copyseeker、Perplexity Pro。
ブラウザー拡張機能：RevEye、Search by Image（複数の検索エンジンに対応）。
AI による位置特定には Picarta を使用します。

17.2 メタデータ（EXIF）

ExifTool、Jeffrey's Image Metadata Viewer、EXIF Viewer Pro。

17.3 画像フォレンジック

Forensically、FotoForensics、Bellingcat Photo Checker、Sensity AI、Exposing.ai、Adobe Content Credentials Verify、c2patool。手法：ELA、メタデータ、複製検出、ノイズ分析。

17.4 位置特定のワークフロー

前景 — 標識、ナンバープレート、服装、植生、天候。
背景 — ランドマーク、特徴的な建物、山、水辺、インフラ。
地図上の標識 — 動植物、季節を示すもの。
試行錯誤 — Google Street View、Bing Streetside、Yandex Panorama。
OpenStreetMap のクエリには Overpass Turbo を使用します。
山の特定 — PeakVisor、Peakfinder、PeakLens AR。
OCR — Google または Yandex の OCR。
動画の文字起こし — YouTube の字幕を使うと、キーワード検索の精度が上がります。

17.5 専門ツール

火災の特定 — NASA FIRMS、Sentinel Hub、Global Forest Watch、Copernicus EFFIS。
航空機の追跡 — Apollo Hunter、FlightRadar、ADS-B Exchange。

18. 動画分析

18.1 コンテキストの抽出

標識／バナー、建築様式、道路標示、ナンバープレート、服装、複数プラットフォームを横断したスニペット検索。

18.2 メタデータ

YouTube Data Viewer（Amnesty）、ダウンロードしたファイルに対する ExifTool。

18.3 プラットフォーム固有の情報

TikTok／Instagram — API は頻繁に変更されるため、プラットフォームのエクスポートを優先してください。1～4 時間の間隔でサンプルを取得します。
Bluesky AT Protocol — bsky.social/xrpc/com.atproto.identity.resolveHandle で DID を解決します。plc.directory/<did> でアイデンティティドキュメントを取得します。Firesky のファイアホースを利用します。グラフには SkyView を使用します。早めにアーカイブしてください — ハンドルの移行／投稿の削除に備えます。
Mastodon／Fediverse — インスタンスは重要です（管轄区域、ログ記録）。発見には WebFinger を使用します。インスタンスを横断する検索には FediSearch を使用します。インスタンスの列挙には Fediverse Observer を使用します。ActivityPub オブジェクトは JSON-LD です。
Threads — IG API と同様の制限があります。

18.4 音声の手がかり

言語、方言、背景音（列車の警笛、祈りの呼びかけ、野生動物）。ツール：Audacity、Sonic Visualiser、SoundCMD。特徴的なパターンにはスペクトログラムを使用します。音楽の特定には Shazam／SoundHound を使用します。

18.5 フレームの抽出

FFmpeg、VLC。パノラマをつなぎ合わせます。パンする映像を安定化します（FFmpeg の deshake または Blender VSE）。再エンコードされた動画より、オリジナルのアップロードを優先してください。

19. 時刻・時間の特定と分析

19.1 影の分析

ツール：SunCalc、ShadeMap、Bellingcat Shadow-Finder、NOAA Solar Calculator。

19.2 天文計算

Stellarium、SkyMap、MoonCalc を使って、異なる時刻／場所の空をシミュレーションします。

19.3 衛星画像の時刻

Google Earth Pro（過去の画像を表示するスライダー）、Sentinel Hub EO Browser（Sentinel と Landsat のタイムラプス）。座標を WKT 形式で記録し、キャッシュされたタイルセットのハッシュを取得します。

20. 脅威アクターの調査

20.1 アクター中心のワークフロー

スコーピング — アクターの仮説を立てます（APT28/29、Turla、Sandworm、APT10/41、Mustang Panda、Volt Typhoon）。CERT／ベンダーのレポートを出発点にします。
インジケーターの収集 — IOC（ドメイン、IP、ハッシュ、JA3/JA4、ユーザーエージェント）を収集します。パッシブ DNS、CT ログ、サンドボックスへの投稿で検証します。
インフラストラクチャのマッピング — CT ログ（SAN、発行者、シリアル番号）、共有ホスティング、ネームサーバーの再利用、レジストラアカウント、HTML フィンガープリントを起点にピボットします。ASN／WHOIS の履歴、RPKI／ROA、位置情報で情報を補強します。
アーティファクトのプロファイリング — PE／ELF のメタデータ（PDB パス、コンパイル時刻、Rich ヘッダー、コード署名）を確認します。SSDEEP／TLSH でクラスタリングし、YARA マッチを調べます。
ソーシャル／調達関連のピボット — 開発者のハンドル名、コードスニペット、学術論文、求人情報、調達記録を調べます。
反証とレポート作成 — 各リンクの妥当性を評価し、代替仮説を記録します。TTP を MITRE ATT&CK にマッピングし、セクション／ページを明記して出典を引用します。

20.2 アトリビューションの原則

能力、意図、支援元を分けて考えます。
3 つのルール：弱い根拠が 3 つ、または強い根拠が 1 つと弱い根拠が 1 つ。
一時的なピボット（解決される IP など）より、長期的に有効なピボット（レジストラアカウント、コード署名証明書、ビルドパスの慣習など）を優先します。
不確実性のレベルを明示し、相関と支配を区別します。

20.3 ロシア固有のピボット

企業／人物 — EGRUL/EGRIP（CAPTCHA が必要）、Rusprofile、Kontur.Focus、zakupki.gov.ru、hh.ru。
インフラストラクチャ — whois.tcinet.ru 経由の RU WHOIS、チャネル／管理者／クロスポストの調査に Telegram を利用します。
メディア — VKontakte、Odnoklassniki、Rutube。ロシア語とその翻字で検索します。

20.4 中国固有のピボット

企業／人物 — gsxt.gov.cn（全国企業信用情報）、Tianyancha／Qichacha、beian.miit.gov.cn の ICP 登録情報から USCC との関連を調査します。
インフラストラクチャ — CNNIC WHOIS、国内で一般的なクラウド（Aliyun、Tencent、Huawei）。
メディア — Weibo、WeChat（weixin.sogou.com 経由）、Zhihu、Bilibili、Douyin、Xiaohongshu。中国語とピンインで検索します。

20.5 インフラストラクチャとインターネット計測

IP→ASN（HE BGP Toolkit、RIPEstat、BGPView）。
証明書の再利用と発行頻度を調べるために CT ログ（crt.sh）を利用し、サブジェクト／発行者／シリアル番号を起点にピボットします。
HTML フィンガープリント、ファビコン（mmh3）、スクリプトハッシュの調査に URLScan を利用します。
サブドメインの変動とステージングドメインの調査に、時間経過を追った DNS（SecurityTrails PDNS、DNSDB）を利用します。

21. 人物とソーシャルメディアの調査

21.1 ユーザー名の列挙

WhatsMyName、NameCheckup、Sherlock、Maigret。

21.2 プロフィール画像と顔の検索

PimEyes、Exposing.ai、Azure Face API（コンプライアンス）。

21.3 ソーシャルグラフとコンテンツ分析

Maltego、snscrape、SocialBlade。Bluesky／Mastodon：インスタンスエクスプローラーとハンドル解決ツール。

22. 漏えいデータとアイデンティティの相関分析

これは、外部レッドチームにとって単独で最も ROI の高い手法です。すべてのエンゲージメントで実施してください。

22.1 ソース構成

ソース	ティア	備考
Hudson Rock Cavalier	無料	インフォスティーラーログのコーパス。企業の SSO に対するシグナルが非常に強いです。
Have I Been Pwned	無料＋有料	ドメイン全体の登録状況と Pwned Passwords（k-匿名性）。
DeHashed	有料	レコード単位で検索できる API。
IntelX	無料＋有料	アグリゲーター。電話帳検索。
ローカルの漏えいデータコーパス	オペレーター提供	ディスク上にあるものすべて。

22.2 ドメインレベルの重大度

統計	重大度
≥10 人の従業員が侵害	CRITICAL
1〜9 人の従業員が侵害	HIGH
≥1 人のエンドユーザー（従業員以外）が侵害	MEDIUM
侵害データ内でドメインが見つかったが、特定されたアカウントは 0 件	INFO

22.3 SSO_EXPOSURE の相関分析

ステージ 3 でアイデンティティファブリックのマッピングを実行し、漏えいデータの照合が完了した後、検出されたすべての IdP テナントについて、そのテナントのドメインを漏えいデータのコーパスと照合します。共通するデータがある場合は、重大度 CRITICAL の SSO_EXPOSURE 検出結果とします。証拠には、テナント ID＋製品＋従業員数＋アカウントごとの情報源の帰属を記載します。

22.4 スティーラーログの運用上の取り扱い

PII として扱い、保存時に暗号化します。
すべてのアーティファクトに SHA-256 を適用し、ソース URL と取得タイムスタンプを記録します。
平文のパスワードをクラウド LLM に貼り付けないでください。
証拠保全の連鎖を記録します。
クライアント向けレポートでは、デフォルトでパスワードをマスキングします。生データ用に、暗号化された認証情報バンドルを別途オペレーターに提供します。

23. インフラストラクチャ OSINT

23.1 IP とドメインの発見

Shodan、Censys、Onyphe、DNSDB。

23.2 証明書とパッシブ DNS

crt.sh、SecurityTrails。

23.3 マルウェアとアーティファクトの分析ワークフロー

静的トリアージ — SHA-256、文字列、インポートテーブル、PDB パス、Rich ヘッダー。AV のラベルだけに頼らないでください。
動的分析／サンドボックス — ANY.RUN、Hybrid Analysis、CAPE、Tria.ge。
クラスタリング — SSDEEP/TLSH、YARA の一致。
レポート作成 — STIX 2.1 IOCs、ATT&CK の手法 ID、再現手順。

23.4 Telegram／WeChat の調査

Telegram — 公開分析ツール（TGStat、Telemetr、Combot）、Telegram Desktop でチャンネルをエクスポートし、メッセージ ID、UTC タイムスタンプ、メディアハッシュを保存します。
WeChat — Sogou Weixin 検索。記事をアーカイブ（PNG + WARC）し、__biz ID を取得します。リンク切れが発生することを想定してください。

24. 自動化とケース管理

24.1 ツール

Hunchly、Kasm Workspaces、ArchiveBox、SingleFileZ。

24.2 モジュール間の連携パターン

複数の OSINT ツール（またはモジュール）を実行する場合、遅れて到着した出力を、先に実行を開始したコンシューマーに取り込む必要があります。パターンは 3 つあります。

サイドカー JSON のドロップ — モジュールが <scan>/mobile_endpoints.json または <scan>/secrets_sidecar.json を書き込み、後続のモジュールが起動時に読み込みます。処理をブロックしません。
アセットグラフのアップサート — 共有グラフストアを使用し、新しいアセットがイベントバスを介して下流モジュールを起動します。
遅延バインディングキュー — 長時間実行される列挙処理がアセットを継続的に出力し、エンリッチメントワーカーが取得します。

アドホックなエンゲージメントでは、tmpdir + JSON sidecars + one-line manifest によって運用を組み合わせられます。

24.3 複数エンジンでのコーパス実行方法

複数のエンジンにまたがって大規模な dork コーパスを実行する場合：

プラグイン可能なエンジン — 各エンジン（DDG、Bing、Brave、SerpAPI、Yandex、Baidu）を共通インターフェイスでラップします。デフォルトは DDG（キー不要）とし、キーが利用可能な場合はほかのエンジンにフォールバックします。
エンジンごとのレート制限 — 各エンジンには独自のクォータとアクセス禁止の方針があります。エンジンごとにトークンバケットを使用します。
結果の分類 — URL のシグネチャ → タイトルのヒント → スニペットの正規表現というパイプラインを使用します。出力は (severity, category, confidence) です。
URL による重複排除 — 異なるエンジンが同じ結果を提示することがあります。
信頼度のルール — スニペットのみの場合は TENTATIVE とします。
永続化 — エンゲージメントをまたいだ再実行で重複排除できるよう、コーパス DB を使用します。

24.4 攻撃的エンゲージメントにおける証拠の保全

エンゲージメントごと、スキャンごとに SQLite ストアを使用します。
run_id、1 行につき 1 イベント、UTC タイムスタンプ、ツールのバージョンを記録した JSONL 実行ログを使用します。
ダウンロードしたすべてのアーティファクトに SHA-256 を適用します。
PNG のスクリーンショットを保存します。
生の HTTP リクエスト／レスポンスを記録し、各本文を 2 KiB までに制限します。
証拠はオペレーターのマシンから読み取り専用で提供します。
再現用パッケージ：run_id + ツールのバージョン + JSONL ログ + アセット／検出事項 DB。

25. 合成メディアの検証

Sensity AI、Hive Moderation、Reality Defender、Adobe Content Credentials Verify、CarNet（ジオロケーション支援のための AI による車種識別）。

26. 反パターンとよくある失敗

よくある間違いを網羅的ではありませんが、以下に挙げます。

単一ソースによる帰属判断。 弱い根拠が3つ、または強い根拠が1つと弱い根拠が1つ必要です。
ベンダーのラベルを事実として信頼する。 ラベルは仮説として扱います。
ファビコンのハッシュ＝所有者だと決めつける。 インフラ、CMS テンプレート、CDN が共有されている場合があります。
ブリッジのフローが1対1だと断定する。 ブリッジはトークンを発行・焼却し、アグリゲーターは残高を再調整します。
Google の検索演算子で見つかったスニペットだけを確証とみなす。 実際にアクセスするまでは TENTATIVE です。
実際の個人識別情報（PII）や認証情報をクラウド LLM に貼り付ける。 機密性の高い分析にはローカルモデルを使用します。
脅威アクターも自分と同じ考え方をするとみなす。 相手はあなたと同じようには考えません。
IP のジオロケーションで帰属判断する。 IP は偽装されることがあり、VPN や住宅用プロキシも存在します。
7日間のオプティミスティックロールアップのチャレンジ期間を無視する。 L2 のファイナリティは遅延します。
CT ログの反映遅延を無視する。 新しい証明書が反映されるまで数分から数時間かかります。存在しないことは、存在しない証拠にはなりません。
Wayback のスナップショットを「時点 T のサイト」として数える。 あくまでベストエフォートであり、多くのリクエストは失敗します。
発見した API の whoami を信頼する。 ハニーポットの可能性があります。
型付けされていない文字列をアセットグラフに登録する。 発見したものはすべてアセットです。
スコープの確認を省略する。 判断に迷ったら一度確認します。
UTC を忘れる。 現地時間を使うと相関関係の不具合が発生します。
WAF にブロックされた後もプローブを続ける。 §6.4 を参照して、手を引きます。
確信度を上げるための文書化を省略する。 TENTATIVE のアセットには CONFIRMED にするための手順が必要です。
エグゼクティブサマリーの作成を後回しにする。 §31 を参照してください。成果物は最後ではなく、案件開始時に計画します。

27. WAF／CDN の回避とオリジンサーバーの発見

Web の標的は、Cloudflare／Akamai／Fastly／AWS CloudFront の背後に置かれていることが増えています。CDN 自体を攻撃するのは困難ですが、オリジンサーバーの防御は不十分なことがよくあります。発見するための手法を6つ紹介します。

27.1 DNS 履歴をたどる

CDN が導入される前は、標的のドメインがオリジン IP を直接指していた可能性があります。パッシブ DNS の履歴を検索します。

SecurityTrails — https://api.securitytrails.com/v1/history/<domain>/dns/a（有料。最も網羅的です）。
RiskIQ PassiveTotal — パッシブ DNS の検索。フリーミアムです。
DNSDB（Farsight）— 有料。履歴が長期間にわたります。
Validin.com — 比較的新しいサービスで、無料プランがあります。
Censys のホスト検索 — IP と証明書の過去の対応関係を検索できます。

確認するのは、1～5年前に名前解決されており、現在の CDN の公開 IP 範囲（Cloudflare／Akamai など）に含まれない IP です。その IP の現在のバナーも照合します。CDN を経由せずに同じサイトを配信していれば、オリジンが見つかったことになります。

27.2 証明書の SAN をたどる

証明書は、オリジンと CDN で同じ SAN リストを使って再発行されることがよくあります。CT ログを検索します。

crt.sh で ?q=%.<target.com>&exclude=expired を検索し、SAN に標的のドメインが含まれる証明書を見つけます。
発行済みの証明書を、現在 CDN の前段にある証明書と照合します。「余分な」証明書（CDN のものではない証明書）は、多くの場合、CN／SAN を通じてオリジンを示します。
cero（go install github.com/glebarez/cero@latest）などのツールは IP をクロールして証明書を取得します。証明書に標的のホスト名が含まれる IP を関連付けます。

27.3 ファビコンのハッシュと JARM によるオリジンのクラスタリング

標的に固有のファビコンがある場合、オリジンサーバーは引き続きそれを配信します（CDN はプロキシしますが、ファビコンを取り除きません）。ファビコンの mmh3 ハッシュを計算して検索します。

Shodan：http.favicon.hash:<mmh3-hash>。
Censys：services.http.response.favicons.hashes:<mmh3-hash>。

返された IP のうち、CDN の範囲に含まれないものが、オリジンの候補です。

JARM（TLS ハンドシェイクのハッシュ）も同様に機能します。jarm を使って標的の JARM を計算し、Shodan で ssl.jarm:<jarm-hash> を検索します。通常、オリジンサーバーの JARM は CDN のものとは異なります。

27.4 Host ヘッダーを指定して IP に直接プローブする

手順27.1～27.3でオリジン候補の IP を入手した場合：

curl -sk -H "Host: target.example.com" https://<candidate-IP>/

応答が公開サイトと一致する（タイトルが同じで、本文のフィンガープリントも一致する）場合、オリジンが見つかったことになります。CDN の IP のみの場合は、汎用の CDN エラーページが返されるか、誤った Host に対して 403 が返されます。

27.5 mail.* / ftp.* / cpanel.* の例外

ターゲットでは、補助的なサブドメインが CDN の背後に置かれていないことがよくあります。

mail.<target> — 実際のメールサーバーを指していることが多く、ウェブのオリジンと同じ場所に配置されている場合もあります。
ftp.<target>、sftp.<target> — 同様です。
cpanel.<target>、whm.<target>、webmail.<target> — 共有ホスティングの管理画面で、ウェブのオリジンと同じ IP を使用しています。
direct.<target>、origin.<target>、direct-connect.<target>、noproxy.<target> — 皮肉な管理用ラベルです。
dev.<target>、staging.<target> — 開発環境では CDN が省かれていることがよくあります。

それぞれを調査してください。いずれかが CDN 以外の IP に解決される場合、その IP で本番環境のオリジンもホストされていることがよくあります。

27.6 エラーページ／設定ミスによる情報漏えい

CDN がエラーを返すとき（リクエストが WAF を作動させた場合、オリジンが停止している場合、設定が一致していない場合）、エラー本文にオリジン IP が漏れることがあります。

Cloudflare の 5xx エラーページには、過去に cf-ray が含まれており、基盤となるアップストリームの詳細が含まれていることもありました。
CDN からの 502/504 は、オリジンが存在するものの CDN から到達できないことを示します。単なる NXDOMAIN ではないことを確認するうえで役立ちます。
X-Cache: MISS from <origin-host> ヘッダー。
オリジンのヘッダーが漏れた HTTP レスポンス（X-Powered-By、Server、X-Backend-Server）。

27.7 メールヘッダーのバウンストリック（メールサーバーのオリジン向け）

ターゲットの存在しないアドレスにメールを送信します。バウンスメールの Received: ヘッダーから、オリジンのメールサーバーの IP が判明することがよくあります。これらのメールサーバーが、ウェブのオリジンと同じ IP／ネットブロック上にある場合もあります。（使い捨ての偽装メールアカウントを使用し、実際のエンゲージメントで使う自分のペルソナは決して使用しないでください。）

27.8 確信度のルール

DNS 履歴から見つかったオリジン IP：直接プローブで裏付けられるまでは暫定。
Host ヘッダーのプローブでコンテンツが一致し、裏付けられたオリジン IP：確実。
Host ヘッダーのプローブに加え、証明書の SAN とファビコンが一致し、裏付けられたオリジン IP：確認済み。

確信が持てない場合は、アセットの attrs に仮説を記録してください。裏付けとなるシグナルが 2 つ以上ない限り、オリジンを特定したと断定しないでください。

28. 脆弱性の優先順位付け（CVE／EPSS／KEV）

Nuclei のスキャンでは、ターゲットに対して 100 件以上の CVE が返されることがあります。すべてを検証することはできません。悪用可能性に基づいて優先順位を付けてください。

28.1 データソース（URL は companion skill §29.2 を参照）

NVD（National Vulnerability Database）— 基本的な CVE カタログ、CVSS スコア。
EPSS（Exploit Prediction Scoring System）— 今後 30 日以内に悪用される確率。尺度は 0.0～1.0 です。
CISA KEV（Known Exploited Vulnerabilities）— 実際の攻撃で悪用されたことが確認されている脆弱性。連邦機関向けの対応期限も含みます。
ExploitDB — POC コードの有無。
Metasploit モジュールカタログ — 自動化の利用可否。
InTheWild.io — コミュニティが管理する「現在悪用中」のトラッカー。
OpenCVE — タイムライン、ウォッチリスト、アラート。
Trickest CVE → POC mapping — CVE と公開 POC の対応をコミュニティが管理するマッピング。

28.2 優先順位付けの基準

リスト内の各 CVE を採点します。

シグナル	重み
CISA KEV に掲載	+50（悪用実績あり。直ちに対応するものとして扱う）
EPSS スコア ≥ 0.7	+30
EPSS スコア 0.3～0.69	+15
公開 Metasploit モジュールが存在	+25
ExploitDB／GitHub に公開 POC が存在	+15
ベンダー発行のアドバイザリとパッチ	+10（脆弱性が実在し、パッチ適用可能であることを意味します。必ずしも悪用可能とは限りません）
認証必須か、認証不要か	認証不要 +20、認証後 +0
ネットワーク経由か、隣接／ローカルか	ネットワーク +15、隣接 +5、ローカル +0
CVSS v3 基本値 ≥ 9.0	+15

合計スコア → 優先度ティア：

スコア	ティア	対応
≥ 100	P0	直ちに検証し、今すぐエンゲージメントの概要に記載します。
70～99	P1	今回のエンゲージメントで検証し、技術レポートに含めます。
40～69	P2	技術レポートに記載し、時間が許せば検証します。
< 40	P3	付録に記載し、検証は想定しません。

28.3 検証の規律

検証＝悪用を引き起こさずに、読み取り専用の証拠確認を1回行います（例：バージョン表示の確認、脆弱なコンポーネントを確認する静的ページの取得）。
ルール・オブ・エンゲージメントで明示的に許可されていない限り、実際のエクスプロイトを実行しないでください。多くのバグ報奨金プログラムでは、本番環境に対する PoC の実行が禁じられています。
クライアント案件では、優先順位を付けたリストと再現用コマンドを提出し、必要であれば実際のエクスプロイトは後続の評価に委ねます。

28.4 CVE がない検出事項への対応

実環境での検出事項の多く（ソースマップの露出、GraphQL のイントロスペクション公開、パブリックバケットなど）には CVE がありません。個別の関心度スコア（エンドポイントについてはコンパニオンスキル §20、重大度のマッピング例については §40）で評価してください。CVE の有無を条件にしないでください。

29. フィッシングインフラストラクチャと口実の作成

許可を得たレッドチーム案件には、フィッシングが含まれることがよくあります。フィッシングのOSINT 側、つまりフィッシング実行可能性の候補リストと口実リストの作成は、ここで扱う範囲内です。実際のフィッシングペイロードの作成は対象外です（運用上のトレードクラフトであり、別の領域です）。

29.1 フィッシング実行可能性の候補リスト

許可を得た案件では、担当者は通常、次の3つのリストを求めます。

A. すでに登録済みのタイポスクワットドメイン — これらは検出事項です（誰かがドメインを占有しており、クライアントに知らせるべきです）。

B. 登録可能なタイポスクワットドメイン — これらは案件で使用する、担当者のフィッシング用ドメイン候補リストです。

C. 証明書の SAN でのなりすましパターン — 信頼性の高い証明書を用意できるよう、担当者が登録できるドメインです（例：acme-secure.com、acme-login.com、acme-vpn-portal.com）。

生成パターン：

ターゲットのプライマリドメインに対して dnstwist（または同等のツール）を実行し、すべてのバリエーション（同形異字、タイポスクワッティング、ビット反転、ハイフン挿入、文字列追加）を取得します。
それぞれについて WHOIS を確認します。登録済みならリスト A、未登録ならリスト B に記載します。
リスト C では、ターゲットの語幹に、もっともらしいサービス関連語（secure、login、vpn、portal、mail、helpdesk、it、account、verify、support、password、auth、sso）を組み合わせます。

29.2 信頼されたドメインを使ったフィッシングのためのサブドメイン乗っ取り

乗っ取り可能なサブドメイン（コンパニオンスキル §16.12）が見つかった場合、実際のターゲットのサブドメイン上でフィッシングコンテンツをホストできます。これにより、ユーザーが講じているブランドなりすまし対策をすべて回避できます。

手順：

候補（<sub>.target.com の CNAME が、未取得の <x>.herokuapp.com を指している）で、乗っ取り可能であることを示す特徴を確認します。
未取得のリソース（Heroku 上の <x>.herokuapp.com）を登録します。
これで <sub>.target.com があなたのコンテンツを配信します。
フィッシングコンテンツを公開する前に、作業を止めて案件責任者に相談してください。 許可を得た案件であっても、乗っ取りの手順自体にクライアントの明示的な承認が必要な場合があります。

29.3 メールなりすましの実行可能性

メールセキュリティ分析（コンパニオンスキル §16.14）を使って、なりすましの実行可能性を判断します。

SPF ポリシー	DMARC ポリシー	なりすましの実行可能性
`~all`（ソフトフェイル）または未設定	`p=none` または未設定	高 — `<anything>@<target>` の直接的ななりすましメールが、受信トレイに届く可能性が高いです。
`~all`	`p=quarantine`	中 — 迷惑メールフォルダーに振り分けられますが、配信はされます。
`-all`（ハードフェイル）	`p=quarantine`	低 — ほとんどのプロバイダーは拒否しますが、一部は迷惑メールとして配信します。
`-all`	`p=reject`	非常に低 — 主要なプロバイダーはなりすましメールを拒否します。類似ドメインが必要です。

なりすましが困難な場合は、類似ドメイン（リスト B）または侵害されたサードパーティ（別案件）に切り替えます。メールセキュリティの設定状況に関する検出事項は、いずれの場合も記録してください。

29.4 OSINT に基づく口実の作成

口実は、標的がすでに置かれている状況に合わせることで効果を発揮します。収集した OSINT を基に口実を作成します。

口実の情報源：

役職＋報告系統（LinkedIn）—「こんにちは、さん。のアシスタントです。この財務ファイルを確認していただけますか？」
最近の企業イベント（プレスリリース、ニュース、採用ページ）—「人員削減／新たな買収について確認しています。福利厚生の情報をご確認ください。」
ベンダーとの関係（「Workday/Salesforce などの経験」に言及した求人情報）—「EOD までに Workday のパスワードをリセットしてください。」
公開カンファレンス／出張（LinkedIn の投稿、カンファレンスのページ）—「こんにちは、さん。先週のでお会いしました。話し合った内容について、改めてご連絡しています。」
GitHub のコミット／オープンソースの活動—「での修正を拝見しました。関連する PR で一緒に作業しませんか？」
オフィスの所在地（LinkedIn）—「オフィスのオンサイト IT で、簡単な認証確認が必要です。」

役割別の口実テンプレート（オペレーターが最もよく使うもの）：

エンドユーザー（一般スタッフ）： IT ヘルプデスクからのパスワードリセット、Workday の人事対応が必要、Microsoft 365 のストレージ容量不足、荷物の配達確認。
経営幹部： 財務権限（BEC 形式の「電信送金の承認が必要です」）、取締役会資料の共有、M&A の NDA 確認、経営幹部アシスタントからの依頼。
開発者／エンジニア： GitHub のセキュリティアラート、CI ビルドの失敗、パッケージのセキュリティ勧告、カンファレンスの CFP に関するフォローアップ。
人事／財務： 給与ベンダーの変更、経費精算の却下、福利厚生の加入期限、ベンダー請求書の不一致。
IT／セキュリティ： ベンダーのセキュリティ更新通知、オンコールのエスカレーション、監視ツールのアラート。

29.5 フィッシング基盤の運用規律

すべてのフィッシング基盤は、稼働を開始する前にエンゲージメントリードの承認を得る必要があります。
登録したすべてのドメインと、送信したすべてのメール（送信者、受信者、件名、UTC のタイムスタンプ）を記録します。
フィッシング基盤は通常の偵察基盤から分離します（IP、ペルソナ、ドメイン登録業者のアカウントをそれぞれ別にします）。
フィッシング用ドメインの登録には専用の支払い方法を使用します（エンゲージメント専用の法人カードを使い、個人カードは使用しないでください）。
エンゲージメント終了後は速やかに撤去し、すべてのドメインを移管または期限切れにし、ホスティングアカウントをすべて閉鎖します。

30. バグバウンティへの報告と責任ある開示

バグバウンティ対象（HackerOne、Bugcrowd、Intigriti、YesWeHack）で問題を見つけた場合、または責任ある開示を行うと判断したプログラム対象外のターゲットで問題を見つけた場合に適用します。

30.1 プラットフォーム別の基本事項

プラットフォーム	URL	備考
HackerOne	hackerone.com	最大規模。対象範囲の追跡に優れ、CVSS に基づいて報奨金を算出します。
Bugcrowd	bugcrowd.com	重大度の評価には CVSS ではなく VRT（脆弱性評価分類）を使用します。
Intigriti	intigriti.com	EU に強く、柔軟な対象範囲モデルを採用しています。
YesWeHack	yeswehack.com	EU に本社を置き、成長しています。
HackenProof	hackenproof.com	暗号資産／ブロックチェーンに特化したプログラムを扱います。
Open Bug Bounty	openbugbounty.org	公式プログラムのないサイト向けの無料サービスです（XSS／SSRF の開示のみ）。
security.txt	rfc9116	標準的な方式です。すべてのサイトで `/.well-known/security.txt` を公開する必要があります。

30.2 報告の構成（どのプラットフォームでも使用可能）

Title: [Severity] [Affected component] Brief description
   Example: [HIGH] [api.acme.com] Unauthenticated SSRF via /v1/proxy

Summary
   2-3 sentences explaining what was found and why it matters.

Steps to Reproduce
   1. Numbered, copy-pasteable.
   2. Include exact URLs, payloads, expected vs actual response.
   3. Reproduce the issue from a fresh state where possible.

Proof of Concept
   - Screenshot showing the vulnerability triggered.
   - HTTP request/response (sanitize sensitive data; redact other users' data).
   - Or short video/GIF for complex multi-step issues.

Impact
   Quantify: what data is at risk, how many users, what business functions break.
   Tie to the program's impact criteria where defined.

Severity (per program criteria)
   - CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
   - Score: 9.8 (Critical)
   - Justification: <1-2 sentence reasoning>

Remediation
   - Concrete recommendation. "Validate the URL parameter against an allowlist before fetching."
   - If a quick fix: WAF rule, header check.
   - If a structural fix: refactor recommendation.

Affected component
   - URL: https://api.acme.com/v1/proxy
   - Date discovered: 2026-04-27 14:23 UTC
   - Method: HTTP GET / POST / etc.

30.3 プログラムごとの重大度の推定

HackerOne は CVSS v3 を使用し、プログラム固有の倍率を適用します（重大度を HIGH までに制限するプログラムもあれば、CRITICAL に 10 倍の報奨金を支払うプログラムもあります）。
Bugcrowd VRT：P1（Critical）から P5（Informational）まで。おおむね CRIT／HIGH／MED／LOW／INFO に対応します。
Intigriti では Exceptional / Critical / High / Medium / Low の段階を使用します。
重大度の段階ごとに定額を支払うプログラムでは、重大度を誇張しないでください。保守的な重大度の評価は、信頼につながり、継続的な報奨をもたらします。

30.4 プログラムがない対象の脆弱性開示（CVD）

対象にバグバウンティプログラムがないものの、許可されたテスト中に実際の脆弱性を発見した場合（例：顧客の外部評価で、サードパーティベンダーのバグが見つかった場合）：

<target>/.well-known/security.txt を確認します。存在する場合は、Contact: と Encryption:（PGP）の指示に従います。
存在しない場合は、security@<target>、次に abuse@<target> を試します。
どちらもメールが返送される場合は、WHOIS に登録されている abuse の連絡先を通じてエスカレーションします。
ベンダーが応答しない場合、調整のために CERT/CC（cert.org）および各国の CERT（CISA、CERT-EU、JPCERT）に連絡します。
公開前に標準の90日間の開示期間を設けます（Project Zero の標準）。

30.5 クラウドプロバイダー／SaaS 固有の連絡先

AWS の abuse 窓口：[email protected]。公開された AWS キーについては、WHOIS／連絡先から特定できる場合、アカウント所有者にも通知します。
GCP：[email protected]。
Azure：Microsoft Security Response Center（MSRC）https://msrc.microsoft.com/。
GitHub：GitHub のパートナープログラムを通じて、公開されたシークレットの大半はシークレットスキャンによって自動的に無効化されます。見つけた場合、スキャンのほうが通常は手動での開示よりも迅速ですが、念のため GitHub（[email protected]）にも通知してください。
npm／PyPI／Docker Hub：いずれにも abuse@ または security@ の連絡窓口があります。npm では、シークレットスキャナーによって漏えいしたトークンが自動的に無効化されます。

30.6 報告で避けるべきこと

他人の PII／パスワード／データを報告に含めないでください（伏せ字にします）。
開示期間が終了するまで、報告書や PoC を公開しないでください。
最初にソーシャルメディア経由でエスカレーションしないでください（必ず最初に直接の連絡窓口を使います）。
特定のバウンティ金額を要求しないでください。金額はプログラム側に判断を委ねます。
同じ発見事項を複数のプログラムに提出しないでください（重複は評判を損なうおそれがあります）。

31. クライアント向け成果物テンプレート

オペレーター向けの成果物（資産グラフ、JSONL ログ、発見事項データベース）は、クライアント向け成果物（エグゼクティブサマリー、技術レポート）とは異なります。成果物は意図をもって作成してください。

31.1 エグゼクティブサマリーのテンプレート

ENGAGEMENT: <Client Name>
ASSESSMENT TYPE: External Attack Surface Assessment
ENGAGEMENT WINDOW: <start date> – <end date>
SCOPE: <one-line scope description, e.g., "All internet-facing assets of acme.com and its 3 brand domains">
LEAD: <your name / team>

----- KEY FINDINGS -----

1. [CRITICAL] <One-line title>
   Business impact: <one sentence in business language>
   Estimated remediation effort: <hours / days / weeks>
   Recommended action: <verb + object, e.g., "Rotate the exposed AWS access key and audit CloudTrail">

2. [CRITICAL] <One-line title>
   …

3. [HIGH] <One-line title>
   …

(Top 3-5 findings only; full list in technical report)

----- POSTURAL OBSERVATIONS -----

- Email security (SPF/DMARC): <2-3 sentences on posture, e.g., "DMARC is set to p=none, allowing spoof of <target>.com email; tightening to p=reject would block external spoofing.">
- Identity fabric (SSO): <2-3 sentences>
- Cloud surface (S3/GCS/Azure): <2-3 sentences>
- Mobile attack surface: <2-3 sentences if applicable>

----- AGGREGATE METRICS -----

- Assets discovered: <N> (<breakdown>)
- Findings: <N CRIT, M HIGH, P MED, Q LOW, R INFO>
- Live credentials confirmed: <N>
- Detectability of our operations: <90% low / 8% medium / 2% high>

----- RECOMMENDED NEXT STEPS -----

1. Address P0 findings in next 7 days.
2. Address P1 findings in next 30 days.
3. Schedule re-test for: <date>.
4. Consider follow-on assessments: <if applicable, e.g., authenticated app testing, internal pentest>.

31.2 発見事項ごとのレポートカードのテンプレート

技術レポートでは、各発見事項に次のカードを使用します。

═══════════════════════════════════════════════════════════
FINDING #<N>: <Title>
SEVERITY: <CRIT / HIGH / MED / LOW / INFO>
CONFIDENCE: <CONFIRMED / FIRM / TENTATIVE>
ASSET: <typed asset key>
DISCOVERED: <UTC timestamp>
═══════════════════════════════════════════════════════════

DESCRIPTION
  <2-5 sentence technical explanation>

EVIDENCE
  - URL: <where it was found>
  - Tool: <how it was discovered>
  - Screenshot: <attachment ref>
  - Raw HTTP: <sanitized capture>
  - Hash (SHA-256): <of any downloaded artifact>

REPRODUCTION
  Step 1: <command or action>
    Expected: <output>
  Step 2: …

IMPACT
  <Business-language impact statement>
  Affected systems: <list>
  Affected user populations: <if applicable>

REMEDIATION
  Immediate (within hours):
    - <action>
  Short-term (within days):
    - <action>
  Long-term (within weeks):
    - <action>

REFERENCES
  - <CVE-ID, advisory URL, OWASP top-10 link, vendor doc>

ATTACK PATH HINT
  <If applicable, the one-sentence hint from companion skill §39>

31.3 リスク翻訳マトリックス

エンジニアはCVSSで考えます。経営層はビジネスへの影響で考えます。翻訳しましょう。

技術的な検出事項	ビジネス向けの影響
PIIを含む、一覧表示可能なS3バケット	「顧客レコードを誰でもダウンロードできます。アクセスされた場合、GDPR／CCPAに基づく通知が必要になる可能性があります。漏えい時の推定コスト：30日以内の通知、信用情報の監視、法務レビュー。」
データベースの認証情報を含む、公開された`.env`	「すべての顧客データにデータベース経由でアクセスできます。バックアップ、請求システム、従業員のPIIにも侵入を広げられます。悪用された場合、データ侵害の範囲は全面に及びます。」
管理者権限を持つ有効なAWSアクセスキー	「クラウドアカウント全体が侵害されます。攻撃者は暗号資産マイニング用サーバーを起動し、すべてのデータを持ち出し、接続されたアカウントへ侵入を広げることができます。悪用された場合、クラウド料金が6桁に達し、環境全体の再構築が必要になります。」
本番環境でGraphQLイントロスペクションが有効	「攻撃者がAPIの攻撃対象領域を完全に把握できます。後続の攻撃をより的確に実行できるようになります。直接悪用できるわけではありませんが、攻撃者による偵察がほぼ手間なく行える状態です。」
サブドメインの乗っ取りが可能	「攻撃者が、信頼されている自社ドメイン上でコンテンツをホストできます。このドメインからのフィッシングメールは、ブランドのなりすまし対策をすり抜け、ユーザーに信頼されます。」
Firebase Realtime Databaseが公開状態	「モバイルアプリのバックエンドデータベースが一般公開され、すべてのユーザーデータを読み取れます。書き込みも可能な場合があります。悪用された場合、全面的なデータ侵害とサービス停止につながる可能性があります。」
`/login`でHSTSが未設定	「アクティブなネットワーク攻撃により、ログインページをHTTPにダウングレードできます。ネットワークにアクセスできる人（コーヒーショップやカンファレンス会場のWi-Fi利用者など）に認証情報を取得される可能性があります。」
DMARCの`p=none`	「インターネット上の誰もが、自社ドメインから送信されたように見えるメールを送信できます。顧客にも従業員にも、非常に信ぴょう性の高いフィッシングを簡単に仕掛けられます。」
漏えいデータに従業員が10人以上含まれる	「従業員の盗まれた認証情報が出回っており、攻撃者がSSOに対して試行する可能性があります。SSOにMFAが設定されていても、他のサービスでパスワードを使い回していると、それらのサービスが危険にさらされます。」
`android:debuggable=true`	「誰でもモバイルアプリをリバースエンジニアリングして改変できます。アプリとサーバー間の信頼境界が損なわれ、バックエンドが、実際には存在しないアプリの完全性を前提としてしまいます。」
KEV CVEがあるバージョンのベンダー製品（Citrix/F5/Pulse）	「ネットワークアプライアンスに、悪用が確認されている既知の脆弱性があります。攻撃者はこの問題を狙ってインターネットを積極的にスキャンしています。直ちにパッチを適用してください。」

31.4 1日を超えるエンゲージメントでの報告頻度

1日目の業務終了時 — 簡単なキックオフ確認：「ステージ1が完了しました。これまでに件のアセットを特定しました。初期状態：<1段落>。」
エンゲージメント中のチェックイン — 最初のCRITICALを発見した時点、または所要時間の50％に達した時点のいずれか早い方。エンゲージメントリードへの事前連絡：「<CRITの説明>を発見しました。<クライアント担当者>に今すぐ連絡し、修正準備を始めることをお勧めします。」
エンゲージメント終了時の速報 — 最後のプローブと同じ日に、主な検出事項を5件提示し、X営業日以内に完全版レポートを提出する計画を伝えます。
最終レポート — 正式な成果物。経営層向けサマリーと技術レポートの両方を含みます。
再テストの提案 — 積極的に提案します：「<期間>内で再テストに対応できます。修正後にCRITICAL／HIGHの検出事項を再テストすることをお勧めします。」

31.5 再現用パッケージの内容

レポートと併せて提出します。

<engagement-id>-reproduction-package.zip
├── README.md                    # how to use the package
├── engagement-metadata.json     # client, dates, scope, lead
├── tools-used.txt               # tool name + version, one per line
├── run-log.jsonl                # every event during engagement
├── assets.db                    # SQLite of all discovered assets
├── findings.db                  # SQLite of all findings
├── evidence/
│   ├── screenshots/             # PNG, named by finding-id
│   ├── http/                    # raw HTTP captures (sanitized)
│   ├── downloads/               # any binary artifacts (with .sha256 alongside)
│   └── code/                    # any extracted source (sanitized)
├── re-test-script.sh            # reruns probes for the CRIT/HIGH findings
└── disclosure/                  # if applicable: bounty submissions, vendor notifications

パッケージが正本であり、レポートは人が読みやすい形式でまとめたものです。パッケージがあれば、誰でもエンゲージメントを再現し、検出事項を検証できます。

32. スキルのセルフテスト

新しい Claude セッションに次のプロンプトを入力し、スキルが読み込まれ、正しく動作することを確認します。合格基準：想定されるセクションが参照されること、内容が捏造されないこと、必要に応じてスコープチェックが実行されること。

"スコープ内のバグバウンティで、acme.com の外部偵察を行っています。何から始めればよいですか？" → §0、§1、§7、§7.5、§11。
"アクティブなプロービングを行わずに、対象が Entra、Okta、ADFS のどれを使っているか見分けるには？" → §11.2-11.4 + コンパニオンスキル §22。
"JS バンドルをスクレイピングするとき、何を探せばよいですか？" → §13。
"対象の Android アプリを見つけて分析するワークフローは？" → §14。
"インターネット全体にスパムを送らずに、適切なクラウドバケット候補を生成するには？" → §15。
"対象のメールアドレスを200件収集し、組織が Entra を使っていることを確認しました。次に取るべき、最も ROI の高い手順は？" → §22。
"公開 GitHub リポジトリで有効な AWS アクセスキーを見つけました。使えるかどうか確認すべきですか？" → §6.3 + コンパニオンスキル §23.2。
"チームが4GBのスティーラーログダンプを入手しました。どのように扱えばよいですか？" → §22.4。
"APT28 のものと思われる指標を3つ見つけました。これで断定できますか？" → §20.2 + §2。
"ロシアのサイバー犯罪アクターを調査しています。企業や人物に関するピボット方法は？" → §20.3。
".cn ドメインを運営企業に結び付けるには？" → §20.4 + コンパニオンスキル §14.2。
"外部偵察中にレッドチームが犯しやすい間違いを挙げてください。" → §26。
"chase.com のサブドメイン列挙をすべて実行してください。" → §1（スコープチェック。実行してはいけません）。
"サブドメインに TENTATIVE のマークが付いています。確度を上げるには？" → §2.1。
"1週間の偵察業務で、5つのステージにどれくらい時間をかけるべきですか？" → §7.6。
"サブドメインが50件、Web アプリが12件、IP が4件、メールアドレスが23件あります。優先順位は？" → §8.5 + §7.5。
"対象は従業員50人の SaaS 企業で、M365 + GitHub + AWS を利用しています。どこに注力すべきですか？" → §10.1 + §11.10 + §22。
"対象は完全に Cloudflare の背後にあります。オリジンを見つけるには？" → §27。
"Nuclei のスキャンで CVE が100件見つかりました。優先順位を付けるには？" → §28。
"プローブが429を返し、Cloudflare のインタースティシャルが表示されます。次はどうすればよいですか？" → §6.4。
"承認済みの業務で、フィッシング実現可能性の候補リストを求められています。手順を説明してください。" → §29。
"HackerOne の対象で認証不要の POST エンドポイントを見つけました。報告書を作成してください。" → §30.2。
"CRIT が2件、HIGH が5件、MED が12件見つかった業務のエグゼクティブサマリーを作成してください。" → §31.1 + §31.3。

33. 変更履歴

v2.1 (2026-04-27) — 32項目のスモークテストによるギャップ分析に基づく包括的な拡張。追加内容：確度向上のワークフロー（§2.1）、検知を考慮したプロービング（§6.4）、時間配分と業務プロファイル（§7.6）、アセットレベルのトリアージルール（§8.5）、規模に応じた戦術（§10.1）、Microsoft 365 の詳細な攻撃対象領域（§11.10）、WAF/CDN のバイパスとオリジンの特定（§27）、脆弱性の優先順位付け（§28）、フィッシングインフラストラクチャと口実の策定（§29）、バグバウンティへの報告と責任ある開示（§30）、クライアント向け成果物のテンプレート（§31）。セルフテストのセクションを v2.1 のプロンプトで更新。
v2.0 (2026-04-27) — 外部レッドチームの方針に合わせて大幅に改訂。追加内容：5段階のパイプライン、アセットグラフの規律、発見事項の評価基準、バグバウンティのピボットモード、アイデンティティ基盤のマッピング、API と認証マップの手法、JS の詳細分析、モバイル攻撃対象領域、クラウド攻撃対象領域、情報漏えいとアイデンティティの相関分析、検知可能性のタグ付け、バリデーターの規律、モジュール間の連携、複数エンジンによるコーパスの実行、証拠の保全、アンチパターン。元の手法に関する内容（OpSec、Crypto、Image/Video/Chrono、RU/CN を含む Threat Actor、Synthetic Media）は維持。
v1.x — SnailSploit/offensive-checklist に基づく元の OSINT 手法フレームワーク。

基本情報

作者: elementalsouls
リポジトリ: elementalsouls/claude-bughunter
カテゴリ: セキュリティ
インストール数: 277
GitHub スター: 5,334

問題を報告