recon-scope-triage について
セキュリティテストや ASM の確認で、テスト前に資産の所有権を検証する偵察スコープのトリアージスキルです。名称の衝突やソフト 404 を扱い、第三者資産への誤った調査を防ぎます。
主な機能
- 01検証済みドメインを基準に設定
- 02資産種別ごとに所有権を確認
- 03ランダムパスとの比較でソフト 404 を検出
- 04対象所有資産だけで件数を再集計
- 05名称衝突資産を隔離して記録
活用シーン
- 01ASM レポートの重大資産を再確認
- 02同名の無関係なリポジトリやアプリを除外
- 03バケットや漏えい記録の所有権を検証
- 04ソフト 404 の露出報告を防止
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/recon-scope-triageを入力して読み込まれたか確認します。
詳細
このスキルを使うタイミング
次の場合に起動します：
- 対象ブランドが一般語・辞書語、または複数の組織で使われる用語である（例：
apex、summit、vertex、nova、core、orbit、pulse、unity…） - ASM レポート、偵察のエクスポート、漏えい情報のコンボリスト、リポジトリ一覧、バケット一覧、またはモバイルアプリ一覧を受け取り、それに基づいて対応する
- 組織の規模に比べて「Critical」の件数が不自然に多い（数百件など）
- ツールがアセットの所有権を主張しているが、証明されていない
このスキルで防ぐ、次の2つの失敗：
- 対象ではないアセットのテストやトリアージに、エンゲージメントを浪費すること。
- 名前が同じというだけの無関係な第三者を攻撃すること。対象範囲外であり、実害につながります。
ルール：所有権は、証明されるまでは未確認として扱います。具体的な所有権のシグナルが対象との結び付きを示す場合に限り、そのアセットを対象のものとします。スキャナーのキーワード一致を根拠にしてはいけません。
キーワード一致が誤判定を生む場所（衝突の原因）
| 偵察ソース | 衝突の仕組み | 所有権の確認方法 |
|---|---|---|
| GitHub リポジトリ | 検索が、リポジトリ名／トピック／文字列に含まれるブランド語に一致 | リポジトリの所有者が組織の GH 組織であること、組織のメールアドレスからコミットされていること、コードが組織の実ドメイン／インフラを参照していること。無関係なユーザーが所有する <word>-backend という名前のリポジトリはノイズです。 |
| クラウドバケット（S3/GCS） | バケット名はグローバルな名前空間です。<word>-static、<word>-data、<word>-public は、誰かがすでに使っています | バケットの内容が対象に言及していること。バケット名が確認済みの対象サブドメインと対応し（x.target.com ↔ x-public）、かつ内容も一致すること。ACL／所有者のメタデータ。別言語・別業界の一般的な内容なら、対象のものではありません。 |
| モバイルアプリ | ストア検索で、アプリ名／パッケージに含まれるブランド語が一致 | 公開元アカウントが組織のものであること。パッケージの逆引き DNS が所有ドメインを示すこと（com.<owneddomain>.app）。開発者証明書。アプリが所有する API ホストを呼び出していること。成熟した ASM ツールでは「apps_accepted=0」／所有権信頼度フィールドが出力されます。確認してください。 |
| 漏えい情報コーパス／コンボリスト | メールアドレスのローカル部またはドメインにブランド語が含まれる | 所有ドメインとの完全一致のみ（@target.com）。@<word>group.com や @something<word>.com は対象外です。ブランド語を含む別のドメインは、別の組織のものです。 |
| タイポスクワッティング | 名前の組み合わせを生成 | これらは攻撃対象範囲ではなく、防御／ブランド保護上の検出事項です。記録して次に進みます。 |
| Stack／フォーラム／ペーストのヒット | 本文にブランド語が含まれる | 本文が対象の実ドメイン／サブドメイン／従業員／シークレットを参照していること。所有権信頼度がしきい値未満なら、対象から外します。 |
Web の「Critical」トリアージ — ソフト 404 対策
自動検出される .env／.git／actuator／管理パネルの「Critical」の大半は、ソフト 404です。SPA／フレームワークのフォールバックが、すべてのパスに対して HTTP 200（または 403）を返しています。信用する前に、各項目を確認してください：
# the "finding"
curl -s -o /tmp/a -w "%{http_code} %{size_download}\n" https://host.target.com/.env
# a junk control on the same host
curl -s -o /tmp/b -w "%{http_code} %{size_download}\n" https://host.target.com/zzz-nonsense-$RANDOM
# identical byte length / body → FALSE POSITIVE (catch-all), discard
cmp -s /tmp/a /tmp/b && echo "SOFT-404 false positive" || echo "differs — investigate"
実際に公開されている場合は、フォールバックとは異なる Content-Type と特徴的な内容があります（.git/config は [core] で始まり、.env には KEY=value があり、phpinfo には XHTML Transitional の DOCTYPE と PHP Version が含まれます）。実在の .php／phpinfo.php が、ジャンクの対照結果よりも大きい／異なる本文を返すことが、実際の露出とソフト 404 を見分ける目安です。
トリアージのワークフロー
- まず、正規の所有ドメイン一覧を確認します（SOW／プログラムのドメインと、その確認済みサブドメイン、および確認済みの Entra／Okta／Google テナントのブランド名）。これを所有権の基準とします。
- 各アセットクラスについて、上記の確認方法の列を適用します。 シグナルがなければ隔離し、テストしないでください。
- 重大度の件数を、所有が確認されたアセットだけを対象に再集計します。 差分を報告します。「Critical が N 件 → 所有権確認＋ソフト 404 トリアージ後に M 件」とすること自体が、ASM プログラムについての検出事項です。
- 衝突した項目を明示的に隔離します（
loot/quarantined_<source>.txt）。確認したうえで対象にしないと判断したことを、監査可能な形で残します。 - メタ的な検出事項を提示します： 提供された ASM／偵察データフィードの大半が誤検知なら、所有者の修復予算が誤配分され、本当のリスクが埋もれてしまいます。その点を報告書にまとめます（Medium／Strategic）。
アンチパターン
- ツールの「所有済み」というラベルを信頼すること。 ツールはキーワード照合を行うだけで、所有権を証明するものではありません。検証してください。
- 「レポートに載っていた」という理由で、同じ名前の第三者を対象にすること。 スコープ外であり、実害も生じます。
user@<word>company.comという組み合わせのメールアドレスは、別の会社の従業員です。 - ソフト404を情報漏えいとして報告すること。 必ず無関係なパスで対照テストを実施してください。
- タイポスクワッティング、ヘッダー不足、ブランド名の衝突があるリポジトリを、攻撃上の発見事項として数えること。 これらは防御や衛生管理上の問題、またはノイズです。報告を水増しし、信頼性を損ないます。
- 「時間の節約」のためにトリアージを省略すること。 トリアージをしなければ、エンゲージメント全体を他者の資産に費やし、本当の問題を何も見つけられません。
これが重要な理由（精度調整）
ブランド名が一般的な単語であるターゲットでは、自動的に「所有済み」と判定される資産の大半は、別のものとの衝突だと予想してください。
- リポジトリ：無関係なオープンソースプロジェクト（広告ブロック用リスト、スクレイパー、学生プロジェクト、別会社の SDK）で、単にその単語を含んでいるもの。
- モバイルアプリ：同じ名前を持つまったく別の会社が公開したもの。銀行、信用組合、出会い系アプリ、薬局、在宅介護サービスなどは、実際によくある名前の衝突例です。（優れた ASM ツールなら、所有済みとして受け入れた件数が ゼロ だと示します。）
- クラウドバケット：グローバルな名前空間にあり、別の組織のコンテンツ（他言語の文書、デモやサンプルデータ、別業界のファイル）を保管しているもの。
- 漏えいした認証情報の組み合わせ：名前の一部が似ている別会社（
<word>group.com、<region><word>.com）のメールアドレスが大量に含まれているもの。
辞書に載っている単語をブランド名に使うターゲットとの実際のエンゲージメントでは、こうしたノイズを除いたあとに残った、実際に所有されている高深刻度の発見事項は、手動の調査手法（JS バンドルから API を発見する方法。hunt-spa-api を参照）でしか見つけられませんでした。何百件ものスキャナーによる「Critical」には、まったく含まれていませんでした。最初にトリアージを行ったことで、エンゲージメントは当てずっぽうの探索ではなく、成果のあるものになりました。
関連スキルと連携
triage-validation— 資産の所有権トリアージ（このスキル）を行ってから、発見事項の妥当性トリアージ（7つの質問ゲート）を行います。まず所有権を確認し、その後に妥当性を確認します。redteam-mindset— 「積極的なデフォルト」とは、稼働中の 所有済み サーフェスをすべて調査することです。このスキルでは、どのサーフェスが所有済みかを定義し、名前の衝突に粘り強く取り組んで時間を無駄にしないようにします。hunt-spa-api— API ホストが所有権トリアージを通過したら、これを使ってテストします。offensive-osint/osint-methodology— OSINT から得た所有権の判断材料（検証済みドメイン、テナントのブランド、開発者アカウント）を、このトリアージに渡します。