Shikata Ga Nai

Private? There is no such things.

Perplexity AIを使ったバグバウンティ向けレコン入門

Hello there, ('ω')ノ

なぜPerplexityを使うのか(要点)

  • 大量のツール出力に埋もれず、目的に沿った調査計画を立てられる。
  • スコープ(許可された範囲)を明確にし、法的に安全なパッシブ情報収集に集中できる。

事前準備(Step 0:基本の「土台」プロンプト)

Perplexityに何をしてほしいかを明確に与えると結果が格段に良くなります。最小限のテンプレート例:

  • Context(状況):この調査は次の対象(ドメイン/IPなど)に対してパッシブ手法で行う許可がある。
  • Goal(目的):攻撃面の洗い出しと優先順位付け(スキャン不可:パッシブのみ)。
  • Scope(対象)example.com, *.example.net, 10.0.0.0/24 のように明確に。
  • Deliverable(出力形式):表・箇条書き・JSON。出典を添えて、不明点はフラグ。
  • Constraints(制約):スキャン不可、パッシブのみ。

(上の項目を毎回ペーストしてセッションを開始すると良いです。)


ステップ別ワークフロー(初心者向け)

Step 1:スコープの正確な理解

バウンティポリシー(ルール)全文を読み、Perplexityに「平易なリスト(ドメイン、FQDN、CIDR、例外)」に分解してもらう。見落としがちなIPレンジや個別ルールが見つかることがあります。

Step 2:サブドメイン列挙の設計

単に大量のサブドメインを掘るのではなく、段階的(フェーズ式)戦略を作る: - 利用する情報源(CTログ、DNS履歴、解析IDなど)
- 具体的な検索クエリ例
- 各手法の信頼性スコア
- 安全に確認する方法
Perplexityにこの設計を作らせると効率的。

Step 3:ASN / インフラの把握

WHOIS、Shodan、Censysなどの公開情報を使い、関連するASNとネットブロック、ホスティングベンダーを表にまとめる。これで「本番の裏側にある放置されたIP」などが発見しやすくなります。

Step 4:Certificate Transparency(CT)ログ活用

CTログは「過去に使われたサブドメイン」を知る宝庫。
各FQDNについて「初出日・最終確認日・組織名の不一致」などを抜き出すことで、忘れ去られたシステムの手がかりが見つかります。

Step 5:スマートなGoogle dork(検索クエリ)

単純な site: 検索ではなく、Perplexityにターゲット向けのdork例を作らせると、開発・ステージングページ、公開されたドキュメント、GitHubでの言及などを効率よく探せます。文書のメタデータも手がかりになります。

Step 6:サードパーティサービスの把握

解析ID、トラッキングピクセル、サポートウィジェット等から外部サービスを特定し、それを手がかりに他の関連ドメインへピボットする。サードパーティ経由で本来の対象外ドメインがつながっていることがあります。

Step 7:公開コードの言及チェック

GitHubなどでドメインや社内メールが言及されていないかを探す。秘密情報狙いではなく、内部ツールやAPIエンドポイントの手がかりを拾うのが目的です。

Step 8:アーカイブ(Wayback)レコン

Wayback Machine等の過去保存から、古い管理パネルやAPIドキュメントのURLを抽出。今は消えているが別ドメインで動いている可能性もあるので確認します。

Step 9:DNSのミスコンフィグチェック

未解決のCNAME、放置されたMXレコード、使われていないTXTなどはドメイン乗っ取りや侵入の可能性につながる。送信パケット不要で見つかるローエフォートな成果が多いです。

Step 10:優先順位付け(スコアリング)

各資産を1〜5で採点: - 脆弱性が見つかる可能性
- 侵害された場合の業務影響
優先度の高いものから能動的テスト(許可範囲内)へ進むと時間対効果が良いです。

Step 11:時間を区切ったスプリント化

60分でできる「クイックリコン」と4時間の「深掘り」など、時間ボックスを設定して効率的に探索するテンプレをPerplexityに作らせると便利です。

Step 12:報告用フォーマットで記録する

そのまま報告に貼れるように「資産 | 証拠ソース | 発見内容 | 優先度 | 安全なフォローアップ」の形式で記録しておくと作業がスムーズです。


Perplexityにさらに“絞り出す”ための3つの追加プロンプト

以下を投げると通常のチェックを超えた観点が得られます。Perplexityセッションで試してみてください。

  1. 「まだ試していないリコン角度は何か?」
  2. 「発見がサードパーティサービスにどう結びつくか?」
  3. 「過去の変更履歴から、新しいデプロイの兆候はあるか?」

初心者が気をつける点(まとめ)

  • 常にスコープを明確に:許可されていない調査は行わない。
  • パッシブ優先:まずはパッシブな情報収集だけで多くがわかる。
  • 出力は報告用に整える:発見→証拠→優先度の順で残すと後工程が楽。
  • ツールは“考える補助”:Perplexityは結論を出す道具ではなく、洞察を与える相棒として使う。

おわりに

Perplexityをただの検索補助として使うのではなく、「調査を設計する・優先順位を付ける・報告に落とし込む」ためのアシスタントとして使うことで、初心者でも効率的に価値あるリコーンができます。元記事はSAEED氏による実践的なワークフロー解説を参考にしています。

Best regards, (^^ゞ