osint-methodology

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

0. 使用する場合／使用しない場合

このスキルを使用する場合： 許可された外部偵察（レッドチーム、バグバウンティ、ASM）を計画または実行するとき、組織の攻撃対象領域をマッピングするとき、人物／団体／脅威アクターを調査するとき、クライアント向け成果物を作成するとき。

このスキルを使用しない場合： ユーザーが能動的なエクスプロイト、侵入後の活動、マルウェア開発を必要としているとき、ブルーチーム／検知に関する内容のとき、または対象への許可が不明確なとき — まずスコープについて確認してください。

---

1. 許可と法的な立場

オペレーターが所有する資産、または評価するための書面による許可を得ている資産を対象とします。

簡易スコープ確認 — 許可が確認できていない場合は、一度だけ尋ねます。

「スコープについて簡単に確認させてください。これは、お客様が所有している、または評価するための書面による許可を得ている対象ですか？ 作業の範囲を逸脱しないよう確認したいと思います。」

いったん許可が示されたら、再確認しないでください。契約に基づく acme.com のペネトレーションテスト」のように作業の種類が明示されている場合は、そのまま進めてください。

常に適用するガードレール：

• 対象側の認証、レート制限、安全制御を決して弱めないでください。
• 明示的な --aggressive モード以外では、破壊的なプローブ（ラインレートでの SYN スキャン、masscan、ファジング）を行わないでください。
• 実際の PII、認証情報、セッショントークン、API キーを、クラウドホスト型 LLM に決して貼り付けないでください。
• 「明らかに関連している」資産であっても、文書化されたスコープ外の資産に対して決して行動しないでください。

---

2. 確信度レベル

すべての主張に確信度レベルを付けます。

レベル	意味
TENTATIVE	間接的な証拠から妥当と思われるものの、未検証です。スニペットのみの検索演算子マッチ、名前から推測したメールアドレスのパターン、単一のパッシブソースから得たサブドメイン。
FIRM	直接観測されていますが、裏付けはありません。サブドメインの名前解決、Shodan バナーの取得、CT ログのエントリー。
CONFIRMED	複数の独立した裏付けがある、または直接検証済みです。ライブ検証済みトークン、一覧表示可能なバケット、3 つの情報源で一致したサブドメイン。

帰属判断における3つのルール： 独立した弱いシグナルが3つ、または強いシグナルが1つと弱いシグナルが1つ。単一の情報源だけで帰属を判断しないでください。

2.1 確信度を引き上げるワークフロー

資産の種類	TENTATIVE → FIRM	FIRM → CONFIRMED
サブドメイン	2つ以上のパッシブソース、または DNS で名前解決できる	標準ポートで応答し、バナー／証明書が返される
IP	2つ以上の情報源（パッシブ DNS、ASN、Shodan）	TCP SYN-ACK または ICMP 応答
WebApp	URL は抽出済みだが、まだアクセスしていない	HTTP が 2xx／3xx／4xx を返し、かつ content-length > 0
メールアドレス	名前のパターンから推測、またはスニペットのみ	Hunter／IntelX／漏えい情報に掲載、または SMTP 250（DATA で中止）
バケット	候補のバリエーションに対する HEAD が 200／301／403 を返す（存在する）	GET で一覧が取得できる = CONFIRMED
認証情報／シークレット	取得したテキスト内で正規表現に一致	読み取り専用バリデーターが成功を返す（スコープとアカウント ID を記録）
人物	単一の情報源から得た名前	2つ目の独立した情報源で確認
SSO テナント	OIDC ディスカバリーエンドポイントがメタデータを返す	テナント GUID を抽出し、MX／autodiscover／SP レコードを通じてドメインとの関連を確認

報告時の基本方針：明示的な裏付けなしに CONFIRMED と主張しないでください。迷った場合は、確信度を下げてください。

---

3. 出力形式

各検出事項には、資産管理ツールにそのまま取り込める次のスキーマを使用します。

Finding:
  id:          <stable hash or UUID>
  module:      <technique that discovered it>
  asset_key:   <typed key, e.g. sub:api.example.com>
  category:    <e.g. SECRET_LEAK, OPEN_GRAPHQL_API, SSO_EXPOSURE>
  severity:    <info|low|medium|high|critical>
  confidence:  <tentative|firm|confirmed>
  title:       <one-line summary>
  description: <2-5 sentences>
  evidence:
    url:       <where 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 形式にしてください。
• 生の HTTP キャプチャは本文を 2 KiB 以下に制限してください。JSONL ログはイベントごとに1行とします。
• 読み取り専用の証拠と作業用コピーを分け、取得した証跡は決して編集しないでください。
• 永続性のある参照情報（CVE、ATT&CK テクニック ID、RFC）を優先してください。一時的な情報の場合は、先にアーカイブしてください（archive.today、Wayback SavePageNow）。

5. 禁止事項

• クラウド LLM に認証情報、セッショントークン、実在の個人情報（PII）、または特定につながる固有のピボット情報を貼り付けないでください。機微な分析にはローカルモデルを使用してください。
• ベンダーのラベルを確かな事実だと見なさないでください（TRM、Chainalysis、Arkham の見解が食い違うことがあります）。
• 単一のシグナル（ファビコンのハッシュ、共有 NS、共有 CT 発行者など）から所有権を断定しないでください。それぞれ仮説にすぎません。
• 明示的な --aggressive モード以外では、ファジング、SYN スキャン、masscan、nuclei fuzzing/* を実行しないでください。
• 読み取り専用の検証以外の目的で認証情報バリデーターを使用しないでください。
• 脅威アクターの視点に立って考えないでください。能力と意図、支援元を切り分けてください。
• アクティブな防御に遭遇してもエスカレートしないでください。手を引き、記録してください（§6.4）。

---

6. 運用セキュリティ（OpSec）

6.1 ソックパペット

投稿履歴を作成し、アカウントを時間をかけて育て、専用のブラウザープロファイルを使用してください。ペルソナの生成には、Fake Name Generator、This Person Does Not Exist を使用します。ブラウザーの隔離には、Firefox Multi-Account Containers を使用します。SMS 認証には使い捨て番号を使用します。インストール前にすべての拡張機能を監査してください。証拠の保全管理を維持し、すべての操作にタイムスタンプを付け、すべての成果物をハッシュ化してください。

6.2 検知可能性のタグ付け

残した痕跡について判断できるよう、すべての操作にタグを付けてください。

タグ	例
低	受動的な Shodan InternetDB、crt.sh、Wayback CDX、SecurityTrails PDNS、Hunter.io、公開バケットへの HTTP HEAD、getuserrealm.srf、OIDC メタデータの取得。
中	GetCredentialType によるユーザー列挙、Okta /api/v1/authn によるユーザー列挙、認証情報の検証、AWS sts:GetCallerIdentity、Swagger／GraphQL のプローブ、標的を絞ったファビコンハッシュ＋JARM フィンガープリンティング。
高	アクティブなポートスキャン（naabu／masscan／nmap）、本番環境に対する Nuclei の全スキャン、広範囲にわたるサブドメインのブルートフォース、SMTP RCPT TO による列挙、Web ファジング。

デフォルトでは受動的な手法を使用してください。アクティブなプローブは、（a）明示的に許可されている、（b）合意した時間枠内である、（c）オペレーターがログ量を把握している場合に限ります。

6.3 バリデーターの運用規律

実環境で認証情報を見つけた場合は、読み取り専用のバリデーターのみ（/me、auth.test、sts:GetCallerIdentity）を使って有効性を確認してください。作成、変更、削除、送信は絶対に行わないでください。checked_at（UTC）、切り詰めた応答、スコープ／アカウント ID を記録してください。9 つのプロバイダー向けの具体的なバリデーターエンドポイントは、offensive-osint §23 にあります。

6.4 検知を考慮したプロービング

検知された兆候（深刻度順）： 429／Retry-After、CAPTCHA のインタースティシャル、WAF のブロックページ、ステータスコードの変化（自分の IP からのみ 200→403）、バナーの変更、NXDOMAIN へのロールバック、有効性を確認できない認証情報のおとり（ハニーポット）、直接の連絡。

段階的な撤退手順：

1. 同時実行数を半分にし、2～10 秒のジッターを追加します。
2. トリガーとなったパスへのアクセスを停止し、別のモジュールに切り替えます。
3. User-Agent／TLS フィンガープリントを変更します。
4. 出口 IP を切り替えます（レジデンシャルプロキシ、別のクラウドリージョン）。
5. 1～24 時間、一時停止します。
6. WAF によるブロック、ステータスの変化、または直接の連絡があった場合は、停止してエンゲージメントリードに相談してください。

---

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

6つの連続した運用ステージに続き、レポート作成をステージ後に行います。各ステージ内のモジュールは並行して実行できます。

ステージ	実施内容
1 — シードの発見	WHOIS、ASN 列挙（HE BGP Toolkit、RIPEstat）、DNS レコード（A/AAAA/MX/TXT/NS/SOA/CAA）、CT 履歴（crt.sh、Censys）。
2 — アセットの拡張	サブドメイン列挙（まずパッシブ → パーミュテーション → ブルートフォース）、クラウドバケットのパーミュテーション、タイポスクワット生成、Wayback CDX、モバイルアプリの発見、DNS ウォーキング、LinkedIn 従業員の列挙、組織／子会社のフットプリント（逆引き WHOIS、企業登記簿）。
3 — 情報の拡充	最初のアクティブな Web トラフィックと ID シグナル：ポート／サービス（Shodan InternetDB → naabu）、TLS ハンドシェイク（証明書チェーン、JARM、favicon mmh3）、WAF/CDN の推定、オリジンの発見、セキュリティヘッダー、メール収集、メールセキュリティ監査、GitHub の検索、JS の詳細分析、SSO/IdP のフィンガープリント（パッシブ層）、API の発見（パッシブ分類器）、シークレットの一斉検索（Postman、Stack Exchange）、ベンダー製品のフィンガープリント、コンテナ／CI-CD／クラウドネイティブの露出、求人情報の収集。
4 — 露出の分析	一括アクティブプロービング：常時実行の Nuclei チェック、TLS 詳細監査、漏えい情報 × ID の相関 → SSO_EXPOSURE 検出結果、対象を絞った設定ミスプローブ（.git/config、.env、/actuator/env、/_cat/indices、/console）、脆弱性の優先順位付け（CVE × EPSS × KEV × POC）。
5 — 収束	ステージ 2〜4 で見つかったホスト名／アセットを対象とする、範囲を限定した再帰を 1 回実施（再変異、再プローブ — 終わりのないクロールではありません）。クラウドフットプリントの追加調査（例：漏えいしたクラウドアクセスキーからアカウント ID を抽出）、サプライチェーンの取得可能性チェック（内部／スコープ対象のパッケージ名が公開レジストリで未取得であることを確認）。
6 — アクティブ検証	厳格なゲートを設け、オペレーターが有効化し、エンゲージメントの承認を受けた証明レベル — デフォルトでは OFF。所有するパネルへの認証情報のライブ送信（デフォルト認証情報 + 漏えい認証情報のリプレイ）、アクティブなクラウド／コンテナ／API／SSO の確認、ホストヘッダーインジェクション／ブラインド SSRF、HTTP リクエストスマグリングの差分検証、インジェクションペイロードの確認（例：XSS）、JWT 偽造による認証バイパスの差分検証。ここに含まれるすべてのモジュールには、エンゲージメント承認に加えて、明示的な有効化とターゲットごとのスコープ確認手順が必要です（§1）。
レポート作成 (ステージ後)	検出結果ごとのリスクスコアリング、アセットグラフのエクスポート、クライアント向けレポート（エグゼクティブサマリー + 技術詳細 + 修正策）、再現パッケージ、該当する場合はバグバウンティへの報告。

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

1. 漏えい情報 — HudsonRock Cavalier + HIBP + DeHashed。最も ROI が高く、多くの場合、平文の企業 SSO 認証情報が得られます。
2. GitHub 偵察 — コード検索クエリ。AWS キー、Slack トークン、JWT シークレットを最速で発見できます。
3. Nuclei による設定ミスの一斉調査 — 露出した管理者パネル、公開 POC のある CVE。
4. クラウドバケット — リスト表示可能な場合は CRITICAL。
5. ポート — まず Shodan InternetDB を使用します。VPN コンセントレーター、RDP、Jenkins、Elasticsearch は価値の高いピボットです。
6. メール OSINT — 漏えい情報の収集に活用でき、フィッシングリストにも利用できます。
7. Web 技術／WAF／スクリーンショット — 数千のホストをトリアージします。
8. Wayback — ハードコードされたキーを探すためのアーカイブ済み JS、削除された管理者用／開発用パス。
9. DNS の詳細調査 + メールセキュリティ — SPF/DMARC の不備はなりすましを可能にし、TXT トークンから SaaS テナントが判明する場合があります。
10. 証明書 → TLS — CT のタイムラインから忘れられたサブドメインを発見できます。弱い暗号スイートは容易に検出できます。
11. ASN + 逆引き DNS — 企業の IP 空間には、告知されていないインフラが存在する場合があります。
12. タイポスクワット — 登録済みなら検出結果、未登録ならフィッシング候補リストに追加します。

7.2 所要時間とエンゲージメントプロファイル

ステージ	小規模組織（100 未満）	中規模組織（100～1K）	大規模組織（1K 以上）
1. シード	30 min	30 min	30 min
2. 資産の拡張	1–2 h	2–4 h	4–8 h
3. エンリッチメント（稼働中の Web アプリ 100 件あたり）	~1 h	~1 h	~1 h
4. 露出分析	1–3 h	3–6 h	6–12 h
5. 収束	15–30 min	30–60 min	1–2 h
6. アクティブ検証 (有効化されている場合)	30 min–1 h	1–2 h	2–4 h
レポート作成	2–4 h	4–8 h	1–2 日

プロファイル： 1 時間の迅速調査（ステージ 1～2 のパッシブ調査＋漏えい情報＋エグゼクティブサマリー） · 4 時間の重点調査（メール収集、SSO フィンガープリンティング、タイポスクワッティングを追加） · 1 日の標準調査（ステージ 1～5 を優先順位順にすべて実施） · 1 週間の詳細調査（標準調査のすべてに加え、JS 詳細調査、モバイル、クラウドネイティブ、ベンダー製品、パッケージレジストリを実施。ステージ 6 は明示的な書面によるエンゲージメント許可がある場合のみ実施） · 毎週の継続的な差分確認（ステージ 1～3 を再実行し、ベースラインとの差分を確認）。

中止条件： ステージ 1 後にスコープの不一致が判明した場合、ステージ 2 後に攻撃対象領域がほぼゼロの場合（つまり、1 つのソースだけでなく、カテゴリ内のすべてのコネクターの結果を合わせたものが空だった場合（§7.3））、いずれかのステージで WAF／検知の兆候が確認された場合（§6.4）。

7.3 コネクターの耐障害性

単一のデータソースがカテゴリ全体の利用を妨げてはなりません。カテゴリごとに、相互に代替可能なバックエンド（CT ログ（crt.sh、Censys、certspotter）、パッシブ DNS（複数のプロバイダー）、ホストインテリジェンス（Shodan、Censys、Netlas）、逆引き WHOIS（複数のベンダー））を単一の呼び出しではなく統合して照会し、その下でソースごとのヘルス状態を追跡し、有効期間の短い結果をキャッシュしてください。

• レート制限がかかったソースや停止したソースによって、そのカテゴリの取得件数が減ることはあっても、その結果が通知されないままゼロになることがあってはなりません。
• 失敗は「カテゴリが空」としてではなく、ソースごとのヘルスイベントとして記録してください。ステージ 2 の中止判断（§7.2）では、必ず統合結果を参照し、単一ソースの状態を参照してはなりません。
• 各ソースの結果は、鮮度を保てるほど短く、かつそのソースのレート制限期間を乗り越えられるほど長い TTL でキャッシュしてください。エンゲージメント中に再実行しても、すでに消費したクォータを再度使わずに済むようにします。

これは、crt.sh のようなフォールバックの原則を証明書だけでなくすべてのカテゴリに適用するものです。停止した API は記録して回避すべきカバレッジ低下イベントであり、マップ上の空白ではありません。

7.4 ステージ番号 ≠ デフォルトで安全

モジュールのステージ番号が示すのは、実行されるタイミングであり、パッシブであるかどうかではありません。ステージの配置を検知可能性のレベルとして扱う前に、必ずモジュール独自のゲート用フラグを確認してください。

テクニック	ステージ	実際の実行条件
IDOR/BOLA の差分確認	3（エンリッチメント）	ステージの境界ではなく、独自の --active/--deep フラグ
アクティブなユーザー列挙オラクル（IdP）	3（エンリッチメント）	独自の --deep フラグ
範囲を限定した 401/403 バイパス／パラメーター探索	4（露出）	デフォルトでレート制限あり。このステージではゲートなしで提供
認証情報のリプレイ／デフォルト認証情報の送信	6（アクティブ検証）	明示的な有効化＋スコープの確認
JWT 偽造による認証バイパスの差分検出	6（アクティブ検証）	明示的な有効化＋2 つ目の確認フラグ

ステージ 6 は、パイプラインの中で明示的にすべてが侵襲的に設計された唯一の箇所です（デフォルトでは OFF、オペレーターによる有効化が必要）。しかし、ステージ 1～5 は「ほぼ」パッシブから低侵襲であり、この「ほぼ」には、上記の 2 つのステージ 3 の行のような実際の例外が隠れています。検知可能性は手法ごとにタグ付けされ（§6.2）、手法がたまたま配置されたパイプラインのステージから推測されることはありません。

---

8. 資産グラフの規律

発見されたものはすべて、グラフ内の型付き資産であり、単独で存在する文字列ではありません。

8.1 資産の分類

カテゴリ	種類
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

すべての資産には、type、key（型付き重複排除 ID）、value、sources[]、confidence、first_seen、last_seen、attrs{} が含まれます。

運用ルール： まず資産を作成してから、検出結果を紐付けます。キーで重複を排除します。sources[] にはすべてのソースを記載する必要があります。信頼度はソースごとに設定し、その後に集約します。

8.2 資産レベルのトリアージルール

WebApp の優先度（高い順）： 認証（auth.、login.、sso.）→ 管理者用パス → 開発／ステージング用ホスト → API（api.、gateway.）→ 顧客向け（portal.、app.）→ マーケティング。

メールアドレスの優先度： 経営幹部（CEO／CFO／CISO）→ IT／ヘルプデスク／セキュリティ → 開発者／エンジニア／DBA → 営業／人事／財務 → 一般的な役割アカウント。

リポジトリの優先度： 最近プッシュされたもの（過去30日間）＞古いもの。説明に対象の名前が記載された公開リポジトリ＞コードのみのリポジトリ。名前に prod／internal／secret が含まれる場合、公開されていても優先度は HIGH です。

---

9. 検出結果の評価基準と深刻度の対応付け

深刻度の基準

深刻度	基準
CRITICAL	認証前のコード実行、有効な認証情報の確認済み、本番データの一覧取得が可能、根本的な信頼性の侵害。例：.env の露出、PII を含む S3 バケットの一覧取得が可能、AWS 管理者キーの有効性を実環境で検証済み、匿名認証が可能なオープン Kubernetes API、侵害データに従業員が10人以上含まれ、テナントも特定済み。
HIGH	明確なエスカレーション経路を伴う重大な露出、価値の高い情報漏えい。例：GitHub リポジトリ内の公開シークレット、サブドメインテイクオーバーの可能性、認証情報を含むリフレクテッド CORS、公開された Jenkins／phpMyAdmin 管理 UI、本番環境での GraphQL イントロスペクションの公開、DMARC の p=none。
MEDIUM	情報漏えい、セキュリティ強化の不備、総当たり攻撃に対する露出。例：HSTS／CSP の未設定、Apache の /server-status、JS 内の内部 IP／ホスト名、エラーページでのスキーマ漏えい、android:allowBackup=true、ユーザーデータ API でのワイルドカード CORS、Slack Webhook の漏えい。
LOW	表面的または影響がわずかな不備。例：X-Frame-Options の未設定、.DS_Store の露出、Stripe のテストキー、証明書ピンニングの欠如、既知の有効なエクスプロイトがない古い WordPress。
INFO	記録する価値はあるものの、直ちに対応する必要はありません。例：robots.txt によるパスの公開、適切に制限されたプライベートバケット、DNSSEC の未有効化。

深刻度の引き上げルール

• 認証／ログイン／SSO／管理者用パスで HSTS が未設定 → MED → HIGH。
• ワイルドカード CORS ＋ 認証情報ヘッダー → MED → HIGH。
• エンドポイントの注目度スコアが70以上（コンパニオンスキル §20）→ 少なくとも HIGH。
• ドメインの侵害データに従業員が10人以上含まれる → 古いデータに関する注意事項にかかわらず CRITICAL。
• ベンダー製品のバージョンが CISA KEV と一致 → CRITICAL。

---

10. ピボットモードとスケール戦術

項目	調査モード	攻撃的偵察モード
プローブ頻度	低速、シングルスレッドで、通常のトラフィックに紛れ込む	バースト送信、並列処理、プロバイダーごとにレート制限
OpSec の姿勢	捨てアカウントのみ使用し、調査者の正体は決して明かさない	エンゲージメント用ペルソナを使用し、チームが SOC に通知する場合もある
証拠の取り扱い	裁判で通用する証拠保全の連鎖	エンゲージメントで通用する水準。同じハッシュ／タイムスタンプの規律を維持
レポート形式	出典付きの時系列を含む叙述形式	資産ごとの所見＋修復策＋再現手順

スケール戦術：

• 小規模（<100）： 個人アカウントに重点を置きます。経営幹部／CFO の侵害が 1 件あるだけで、鍵を手に入れられることがよくあります。すべてのメールと ID ファブリックに関する所見を、1 件ずつ詳細に調べます。創業者の個人用 GitHub 組織を確認します。
• 中規模（100–1K）： バランスよく列挙します。標準的な深度でパイプライン全体を実行します。LinkedIn では役職を優先します。両方のアプリストアを確認します。
• 大規模（1K–10K）： 広範囲から着手し、資産の検出には自動化を活用します。手動でのトリアージは所見のみに行います。
• 超大規模／コングロマリット： 最も重要な手順はスコープの絞り込みです。まずブランドのピボットマップを作成します。個別アカウントよりも、漏洩コーパスとシステム全体のセキュリティ態勢に関する所見（DMARC の不備、SSO_EXPOSURE の広がり）が優先されます。

---

11. 実装：関連スキルへのポインター

以下のモジュールには、プローブパス、ワードリスト、curl のワンライナー、正規表現、スコアリング基準など、実装の詳細が offensive-osint に記載されています。このスキルでは 何をするか を定義し、もう一方のスキルでは どのように実行するか を定義します。

ID ファブリックのマッピング（offensive-osint §22）— Microsoft Entra（OIDC メタデータ、getuserrealm.srf、GetCredentialType）、Okta（スラッグの導出、/api/v1/authn）、ADFS、Google Workspace、汎用 OIDC（Auth0/Keycloak/Ping/OneLogin/Duo）、SAML メタデータ（5 パス）、AWS アカウント ID の抽出、M365 の詳細な攻撃対象領域（Teams フェデレーション、SharePoint、OneDrive、OAuth client_id、デバイスコードフィッシングの確認、Power Platform）。

API と認証マップ（offensive-osint §16.1–16.2、§20）— 28 パスの Swagger/OpenAPI ワードリスト、13 パスの GraphQL ワードリスト、イントロスペクション用 POST ボディ、イントロスペクションが無効な場合のフィールド候補列挙、エンドポイント関心度の 0～100 評価基準。

JavaScript の詳細分析（offensive-osint §13 のパターン）— ソースマップの検出、JS 本文および sourcesContent[] を対象とするシークレットカタログ、3 段階のエンドポイント抽出用正規表現、内部ホスト漏洩のパターン、Next.js マニフェストの解析。

モバイル攻撃対象領域（offensive-osint §21）— Android/iOS アプリの検出、所有者である確度の 0～100 スコアリング、APK の静的解析、マニフェストの設定不備に関する所見、Firebase の標準プローブ。

クラウド攻撃対象領域（offensive-osint §16.8）— S3/GCS/Azure バケットの組み合わせ生成（6 個のプレフィックス × 15 個のサフィックス）、HEAD → GET プローブ手法、クラウドネイティブのフィンガープリント（Lambda、Cloud Run、Azure Functions、Vercel、Netlify、Workers）、K8s/etcd/kubelet/コンテナレジストリの露出。

WAF/CDN バイパスとオリジンの特定（offensive-osint §16.15）— DNS 履歴へのピボット、証明書 SAN へのピボット、favicon mmh3 + JARM のクラスタリング、Host ヘッダーを指定した直接 IP プローブ、メール／ftp／cpanel の例外、エラーページからの漏洩、メールヘッダーのバウンストリック、確度のルール。

脆弱性の優先順位付け（offensive-osint §29.2）— NVD、EPSS、CISA KEV、ExploitDB、Metasploit、InTheWild.io、Trickest の CVE→POC、9 つのシグナルによるスコアリング基準 → P0/P1/P2/P3 の各ティア。

フィッシングインフラ（メールセキュリティについては offensive-osint §16.14）— dnstwist によるタイポスクワット候補リスト、信頼されたドメインを使ったフィッシングのためのサブドメイン乗っ取り、メールスプーフィングの実現可能性マトリクス（SPF × DMARC）、OSINT に基づく口実の作成（役職、最近の出来事、ベンダーとの関係、GitHub のコミット）。

12. 漏えい情報とアイデンティティの相関

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

ソース	ティア	備考
Hudson Rock Cavalier	無料	インフォスティーラーログのコーパスです。企業の SSO 認証情報に対するシグナルが非常に強いです。
Have I Been Pwned	無料＋有料	ドメイン全体での存在確認と Pwned Passwords（k-anonymity）を提供します。
DeHashed	有料	レコード単位で検索可能な API です。
IntelX	無料＋有料	アグリゲーターです。電話帳検索が可能です。

ドメインレベルの重大度： 従業員の侵害が 10 人以上 → CRITICAL、1～9 人 → HIGH、エンドユーザーが 1 人以上 → MEDIUM、名前付きアカウントが 0 件でドメインが確認された場合 → INFO。

SSO_EXPOSURE： Stage 3 のアイデンティティファブリックのマッピング後、および漏えい情報の検索後に、特定した IdP テナントのドメインと漏えい情報のコーパスを照合します。一致が 1 件以上ある場合は、重大度 CRITICAL の SSO_EXPOSURE 検出事項とします。証拠：テナント ID ＋ 製品 ＋ 従業員数 ＋ アカウントごとのソース。

スティーラーログの取り扱い： 保存時に暗号化し、すべてのアーティファクトの SHA-256 を取得してください。平文のパスワードをクラウド LLM に貼り付けてはいけません。証拠保全の連鎖を維持し、クライアント向けレポートではデフォルトでパスワードを伏せてください（暗号化された認証情報バンドルは別途提供してください）。

12.1 個人別アイデンティティドシエ

ドメインレベルの漏えい件数（上記）は、組織が危険にさらされていることを示します。アイデンティティドシエは、漏えいした認証情報をメールアドレスで照合し、発見した PERSON（氏名、役職、職位、person-enum／LinkedIn のドーキングによるターゲットスコア）をすべて紐付け、個人ごとに優先順位を付けたカードを作成して、誰が対象なのかを示します。この手順によって、漏えい人数をスピアフィッシング／クレデンシャルスタッフィングの標的リストに変換できます。

照合キーは氏名ではなくメールアドレスです。 PERSON アセットは氏名をキーとしており、通常はそれ自体にメールアドレスが含まれていません。照合の前に、組織の確認済みメール形式パターン（Hunter から取得、または個別に確認）を使って、氏名からメールアドレスを特定してください。サンプル 1 件から推測したパターンを使って照合してはいけません。

フィールド	ソース
役職／職位／ターゲットスコア	person-enum／LinkedIn のドーキング
メールアドレス — known（直接確認済み）または pattern（氏名に組織の確認済み形式を適用）	メールアドレスの OSINT／組織のメール形式パターン
そのメールアドレスに紐付くすべての認証情報	漏えいダンプ、スティーラーログ、GitHub／JS のベーシック認証情報漏えい、漏えい情報のリプレイによるヒット
リスクティア	以下から算出

リスクの分類： 価値の高いメールボックス（役員／IT／管理者）でターゲットスコアが 80 以上のものに、確認済みの認証情報が 1 件以上紐付く場合が最悪のケースです。

ターゲットスコア	漏えいした認証情報	リスク
80 以上（役員／IT／管理者）	1 件以上	CRITICAL
任意	1 件以上	HIGH
80 以上	0 件	MEDIUM
80 未満	0 件	LOW

孤立した認証情報： 発見した人物に紐付かない漏えいメールアドレスも、行き止まりではなく手がかりです。漏えい件数順に並べて、別途提示してください。まだ人物を特定できていないだけです。person-enum をさらに実施すれば特定できる可能性があります。

確度： 照合の強さはメールアドレスの特定精度に左右されます。known メールアドレスの場合、認証情報自体の確度を適用します（§2）。pattern で特定したメールアドレスは、そのアドレス自体が別途確認されるまで、帰属の確度を TENTATIVE とします（例：漏えい記録にそのまま記載されている、または Hunter.io が直接返す）。パターンだけを根拠に、パターンから特定したドシエを CONFIRMED として報告してはいけません。

エンゲージメントで Stage 3 の person-enum／メール OSINT の結果と漏えい情報の検索結果（ドメインレベルまたはリプレイ）の両方が揃ったら、毎回この手順を実施してください。すでに収集済みのデータを照合するだけで、新たな情報収集ではないため、省略する理由はありません。この結果を使って、最初にフィッシングの口実を仕掛ける対象（§13）と、読み取り専用の認証情報チェックで最も価値の高い候補（§6.3）を決めてください。

---

13. 専門分野別の OSINT

暗号資産 — Cielo、TRM、Arkham、MetaSleuth を使って資金の流れを追跡します。L2／ロールアップ：L1 のブリッジイベントから調査を開始し、ロールアップ内の動きには L2 エクスプローラーを使用します。注意：ブリッジではミント／バーンが発生するため、1 対 1 の資金フローを前提にしないでください。MEV 経路によって、直接つながっているように見える誤った痕跡が生じます。

画像／動画／撮影場所の特定 — 逆画像検索（Google Lens、Yandex、TinEye）、ExifTool による EXIF の確認、Forensically／FotoForensics によるフォレンジック分析、前景と背景のランドマーク分析、Street View、Overpass Turbo、PeakVisor による位置特定を行います。影の分析：SunCalc、ShadeMap。衛星画像：Google Earth Pro の過去の画像、Sentinel Hub。

脅威アクターの調査 — 範囲の設定：CERT／ベンダーのレポートからアクターの仮説を立てる → IOC を収集する → CT ログのピボット、共有ホスティング、NS の再利用、HTML フィンガープリントによってインフラをマッピングする → アーティファクトをプロファイリングする（PDB パス、Rich ヘッダー、SSDEEP／YARA）→ ソーシャル上でピボットする（ハンドル、コードスニペット、求人情報）。帰属判断の原則：3 つのルールに従い、能力と意図を分けて考えます。一時的なピボット（名前解決される IP）よりも、長期間使われるピボット（コード署名証明書、ビルドパスの慣習）を優先します。ロシア関連のピボット：EGRUL、Rusprofile、hh.ru、VKontakte。中国関連のピボット：gsxt.gov.cn、Tianyancha、ICP 登録、Weibo、Zhihu。

人物とソーシャルメディア — ユーザー名の列挙：WhatsMyName、Sherlock、Maigret。顔検索：PimEyes、Exposing.ai。ソーシャルグラフ：Maltego、SocialBlade。Bluesky：bsky.social/xrpc/ による DID 解決、Firesky によるファイアホースの利用。Mastodon：WebFinger による検出、FediSearch によるインスタンス横断検索。

---

14. アンチパターンとよくある失敗

• 単一の情報源に基づく帰属判断。 3 つのルールに従います。
• ベンダーのラベルを確定情報として信頼する。 ラベルは仮説です。
• ファビコンのハッシュ ＝ 所有者。 共有インフラ、共有 CMS、共有 CDN はいずれも一致を生みます。
• スニペットだけの dork を CONFIRMED とする。 実際にアクセスするまでは TENTATIVE です。
• 実際の PII／認証情報をクラウド LLM に貼り付ける。 ローカルモデルのみを使用します。
• 脅威アクターも自分と同じ考え方をするとみなす。 相手はあなたと同じようには考えません。
• IP ジオロケーションによる帰属判断。 VPN と住宅用プロキシが存在します。
• CT ログの遅延を無視する。 見当たらないことは、存在しないことを意味しません。遅延は数分から数時間に及ぶ場合があります。
• Wayback を「時刻 T におけるサイト」とみなす。 あくまで可能な範囲での記録であり、多くのリクエストは失敗します。
• アセットグラフに型なし文字列を登録する。 発見したものはすべてアセットです。
• スコープの確認を省略する。 判断に迷ったら、一度確認します。
• UTC を忘れる。 現地時間は相関分析の不具合を招きます。
• WAF にブロックされた後も調査を続ける。 いったん停止します（§6.4）。
• 信頼度を引き上げる根拠の記録を省略する。 TENTATIVE から CONFIRMED にするための道筋が必要です。
• エグゼクティブサマリーを後回しにする。 エンゲージメント開始時に成果物を計画します。

---

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

プラットフォーム： HackerOne（CVSS ベース）・Bugcrowd（VRT：P1～P5）・Intigriti・YesWeHack・HackenProof（暗号資産に特化）・Open Bug Bounty（XSS／SSRF のみ）・プログラム未登録の対象には /.well-known/security.txt。

報告の構成：

Title: [Severity] [Component] Brief description
Summary: 2-3 sentences — what and why it matters.
Steps to Reproduce: numbered, copy-pasteable, URL + payload + expected vs actual.
Proof of Concept: screenshot or sanitized HTTP request/response.
Impact: what data/users/functions are at risk.
Severity: CVSS v3 vector + score + 1-sentence justification.
Remediation: concrete, actionable recommendation.

プログラム未登録の CVD： security.txt を確認 → security@<target> → WHOIS の不正利用連絡先 → CERT/CC。公開までの標準猶予期間は 90 日です。絶対にしてはいけないこと： 他者の PII を含める、猶予期間の終了前に公開する、または最初の手段としてソーシャルメディアで事態をエスカレートする。

---

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

エグゼクティブサマリーの構成： エンゲージメントのメタデータ → 上位3～5件の所見（タイトル＋ビジネスへの影響＋修正に必要な工数）→ セキュリティ体制に関する所見（メールセキュリティ、ID基盤、クラウドの攻撃対象領域、モバイル）→ 集計指標（アセット、深刻度別の所見、確認済みの有効な認証情報）→ タイムライン付きの推奨される次のステップ。

所見ごとのレポートカード： タイトル＋深刻度＋確信度＋アセットキー＋UTCタイムスタンプ → 説明 → 証拠（URL＋ツール＋スクリーンショット＋生のHTTPデータ＋SHA-256）→ 再現手順 → ビジネス向けの影響説明 → 修正（即時／短期／長期）→ 参考情報＋攻撃経路のヒント。

リスクの言い換え（例）：

技術的な説明	ビジネス向けの説明
PIIを含む一覧取得可能なS3バケット	顧客記録を誰でもダウンロードできます。GDPR／CCPAに基づく通知が必要となる可能性があります。
DB認証情報を含む露出した.env	データベースへの完全なアクセスが可能です。バックアップ、請求情報、従業員のPIIへと侵入を広げるおそれがあります。
有効なAWS管理者キー	クラウド全体が侵害される可能性があります。暗号資産マイナーの起動、全データの持ち出し、ラテラルムーブメントが可能です。
DMARC p=none	インターネット上の誰もが、あなたのドメインから送信されたように見えるメールを送信できます。
漏えいデータに10人以上の従業員が含まれる	盗まれた企業のSSO認証情報が出回っており、クレデンシャルスタッフィング攻撃のリスクが高まっています。
CISA KEVに掲載されたベンダー製アプライアンス	攻撃者がこの脆弱性を狙ってインターネットを積極的にスキャンしています。今すぐパッチを適用してください。

報告のタイミング： 1日目の業務終了時にキックオフ概要を共有 → エンゲージメント中、最初のCRITICALを確認した時点で速報 → エンゲージメント終了時に予備報告書（上位5件の所見）を共有 → 合意したSLA内に最終報告書を提出 → 修正後、CRITICAL／HIGHの所見について再テストを提案。

再現パッケージ： run-log.jsonl＋assets.db＋findings.db＋evidence/（スクリーンショット、HTTPキャプチャ、.sha256付きのダウンロードファイル）＋re-test-script.sh＋エンゲージメントのメタデータ。

---

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

スキルが正しく読み込まれることを確認するため、新しいセッションに以下を入力してください。

1. 「acme.comの外部レコンを行います（スコープ内のBB）。どこから始めますか？」 → §0、§1、§7、§7.1。
2. 「アクティブなプロービングを行わずに、Entra、Okta、ADFSを見分けるには？」 → §11＋関連スキル§22。
3. 「サブドメインが50件、Webアプリが12件、メールアドレスが23件あります。どの順番でトリアージしますか？」 → §8.2＋§7.1。
4. 「GitHubリポジトリで有効なAWSキーを見つけました。検証すべきですか？」 → §6.3。
5. 「プローブが429を返し、Cloudflareのインタースティシャルが表示されます。次はどうしますか？」 → §6.4。
6. 「メールアドレスを200件収集しました。組織はEntraを使用しています。次に行うべき、最もROIの高いことは何ですか？」 → §12、§12.1。
7. 「ターゲットは完全にCloudflareの背後にあります。オリジンサーバーを見つけるには？」 → §11（WAF／CDNに関する参照先）＋関連スキル§16.15。
8. 「NucleiスキャンでCVEが100件見つかりました。優先順位を付けてください。」 → §11（脆弱性の優先順位付けに関する参照先）＋関連スキル§29.2。
9. 「認可済みのエンゲージメントで、フィッシングの実現可能性に関する候補一覧を求められています。」 → §11（フィッシングに関する参照先）。
10. 「HackerOneのターゲットで未認証のPOSTエンドポイントを見つけました。レポートを作成してください。」 → §15。
11. 「CRITが2件、HIGHが5件、MEDが12件ある場合のエグゼクティブサマリーを作成してください。」 → §16。
12. 「chase.comのサブドメインをすべて列挙してください。」 → §1（スコープ確認。実行してはいけません）。
13. 「エンゲージメント中にcrt.shが429を返しています。サブドメイン一覧は完全ですか？」 → §7.3。
14. 「モジュールがステージ3で実行されます。パッシブだと想定しても安全ですか？」 → §7.4。
15. 「漏えいデータの該当情報とLinkedInの従業員一覧があります。誰を優先しますか？」 → §12.1。

---

18. 変更履歴

• v2.3 (2026-08-06) — §7 を5段階モデルから、実運用で検証済みの6段階モデル（Seed → Asset Expansion → Enrichment → Exposure Analysis → Convergence［bounded recursion + cloud-footprint + supply-chain］→ Active Validation［厳格なゲート制御、オペレーターによる有効化、デフォルトでは OFF］）に更新し、Reporting をステージ後の処理として再定義しました。§7.3 Connector Resilience（データカテゴリごとにバックエンドを切り替えられるユニオンクエリ、ソース単位の健全性追跡により、停止中またはレート制限中のソースが1つあってもカテゴリ全体の結果がゼロにならないようにする）と、§7.4 Stage Number ≠ Safe-by-Default（モジュールのステージ番号だけでは、そのモジュールが受動的かどうかは判断できません。必ず個別のゲートフラグを確認してください。検出可能性は手法ごとに異なります）を追加しました。§12.1 Per-Person Identity Dossier を追加しました。発見された PERSON の役割・職位と、メールアドレスで漏えい CREDENTIAL を結び付け、リスク分類と対応する認証情報がないケースの処理を含む、優先順位付きのスピアフィッシング／クレデンシャルスタッフィングの標的リストを作成します。自己テスト用プロンプトを3件（§17.13–15）追加しました。
• v2.2 (2026-04-29) — リファクタリング：1,694行から約480行に整理しました。実装詳細のセクション（§11–§15、元の§27–§31）は offensive-osint への参照にまとめました。フレームワークの主要部分（信頼度レベル、パイプライン、アセットグラフ、重大度基準、OpSec、情報漏えいの相関分析、アンチパターン、成果物のテンプレート）はそのまま残しました。重複する内容を削除し、専門領域を単一の§13に統合しました。§23–§25を§13に統合し、§27–§29を§11の参照ブロックにまとめました。
• v2.1 (2026-04-27) — 32件のプロンプトを使ったスモークテストのギャップ分析に基づき、大幅に拡張しました。合格率：31/32。
• v2.0 (2026-04-27) — 外部レッドチームの体制に合わせて大幅に書き直しました。
• v1.x — SnailSploit/offensive-checklist に基づく初期フレームワーク。