pentesting-everything

PentestingEverything

許可されたセキュリティ評価のための、実践的で引用可能なワークフローとしてこのリポジトリを使用してください。記憶よりもリポジトリ内の根拠を優先してください。許可、スコープ、検出結果を捏造しないでください。

関連サイト：

• ナレッジベース：https://pentesting.m14r41.in
• チェックリストの関連サイト：https://checklist.m14r41.in
• 上流リポジトリ：https://github.com/m14r41/PentestingEverything

基本ルール

1. 合法的な用途に限ります。 ユーザーにテスト権限があるシステムのみを対象にしてください。
2. 許可を捏造しないでください。 スコープ、エンゲージメントルール、書面による許可が不明確な場合は、アクティブなテストの手順を案内する前に確認してください。
3. アクティブなテストの前に確認してください。 計画またはチェックリストを作成した後、実環境への攻撃を推奨する前に、対象と制約の確認をユーザーに求めてください。
4. 影響の大きい操作には明示的な許可を求めてください。 破壊的なテスト、サービス拒否や負荷の悪用、大規模なクレデンシャルスタッフィング、実在する人物を標的としたフィッシングやソーシャルエンジニアリング、永続化、合意済みのホスト範囲外へのラテラルムーブメント、実在する個人データの持ち出しには、スコープを明記した書面による明示的な許可が必要です。
5. ソースに基づいて回答してください。 方法論、ペイロード、ツールのコマンドを説明する前に、リポジトリ内の Markdown（またはライブサイトのページ）を確認してください。参照したパスと URL を引用してください。
6. 中立的でプロフェッショナルな口調を保ってください。 正確で実践的な内容にし、成果物では大げさな表現や絵文字を使用しないでください。
7. 自動リクエストのペースを調整してください。 インタラクティブなテスターと一緒ではなく、自律エージェントとして実行する場合は、リクエストを繰り返す前に、プログラムに定められたレート制限とテスト時間帯を守ってください。無人のリクエスト集中は、エージェント実行による WAF のブロックや、人間のテスターなら自然に調整できるはずのプログラムルール違反につながります。

使用する場面

ユーザーが次のことを依頼した場合に適用してください。

• ペネトレーションテスト、VAPT、またはセキュリティ評価の計画や実施
• Web、API、モバイル、クラウド、Active Directory、ネットワークなどの領域に関するチェックリストの作成
• 脆弱性の種類（SQL インジェクション、IDOR、SSRF など）のテスト方法の調査
• このナレッジベースを用いた検出結果、証拠メモ、レポートセクションの作成
• PentestingEverything のフォルダーやライブドキュメントサイトの案内

ワークフロー

進捗を記録します。

Engagement progress:
- [ ] 1. Confirm authorization and scope
- [ ] 2. Identify assessment domain(s)
- [ ] 3. Locate repository sources
- [ ] 4. Read source material
- [ ] 5. Produce plan + prioritized checklist
- [ ] 6. User confirms active testing
- [ ] 7. Provide non-destructive guidance with evidence capture
- [ ] 8. Draft report-ready findings

1. 許可とスコープを確認する

次の情報を収集するか、ユーザーに確認してください。

項目	例
許可	書面によるエンゲージメントルール、バグバウンティプログラム、ラボの所有権
対象	ドメイン、IP、アプリ、API、アカウント、クラウドアカウント
環境	ラボ／ステージング／本番環境
制約	時間帯、レート制限、対象外のホスト、データの取り扱い
目標	認証の回避、データ漏えい、権限昇格など

アクティブな作業でいずれかの項目が不明な場合は、作業を中断して確認してください。教育目的またはラボ限定の質問であれば、仮定を明示したうえで続行できます。

例：

仮定：ラボの対象は dvwa.local、本番システムは対象外、サービス拒否は禁止、フィッシングは禁止。

2. 評価対象の領域を特定する

依頼内容を1つ以上の最上位フォルダーに対応付けてください。すべての一覧については REPOSITORY_MAP.md を参照してください。

クイックガイド：

ユーザーの意図	最初に確認する場所
Web アプリ／OWASP／XSS／SQL インジェクション	Web Application Pentesting/
REST／GraphQL／BOLA	API Pentesting/
Android／iOS	Mobile Pentesting/
AWS／Azure／GCP	Cloud Pentesting/
内部ホスト／サービス	Network Pentesting/
Active Directory／Kerberos／BloodHound	Active Directory Pentesting/
SAST／ソースコードレビュー	Secure Code Review/
LLM／MCP アプリ	LLM Security Assessment/、MCP Security Assessment/

該当するカテゴリ内で、内容が最も絞られたトピックフォルダーを優先してください。

3. リポジトリのソースを見つける（まずローカル）

利用可能な場合は、このリポジトリのローカルクローンを優先してください。

1. カテゴリのランディングページ：<Category>/README.md（大文字・小文字が異なる場合があります：readme.md）
2. トピックまたは脆弱性のフォルダー：多くの場合、<Category>/Vulnerabilities/<Topic>/README.md
3. 専用のチートシート（*Cheatsheet*.md、Handy-command.md）。「手法を説明して」ではなく「コマンドを教えて」という依頼の場合に使用します。REPOSITORY_MAP.md のチートシート一覧を参照してください。
4. <Category>/References/ 内の PDF。存在を記録し、必要な場合にのみ内容を抽出してください。

クローンが開かれていない場合のリモートでの代替手段：

• GitHub ツリー：https://github.com/m14r41/PentestingEverything/tree/main/<path>
• ライブドキュメント：https://pentesting.m14r41.in

ローカルワークスペースでの検索手順：

1. カテゴリの README にあるテーブルで、脆弱性名またはトピック名を検索します
2. そのカテゴリ内で **/<Topic>/**/*.md を Glob で検索します
3. 要約する前に、トピックの README を最後まで読みます
4. チェックリストに影響する場合に限り、隣接するメモも確認します

4. 教える前に読む

推奨する各手法について：

1. 関連する Markdown ファイルを開きます
2. ユーザーの対象範囲に合った方法論、テストケース、コマンドを抽出します
3. 実際のシークレットやターゲットを <TARGET>、<USER_ID>、<TOKEN> などのプレースホルダーに置き換えます
4. まずは非破壊的な検証を優先します（偵察、認証のマッピング、自分のオブジェクトを使った IDOR、安全なプローブなど）
5. ガイダンスが古い、不完全、またはバージョンに依存する場合は、一次情報（OWASP、ベンダーのドキュメント、CVE アドバイザリー）で補足し、リポジトリ由来の情報と外部資料の情報を明示します

リポジトリの PDF をそのまま貼り付けないでください。要約してリンクしてください。

5. 成果物を作成する

OUTPUT_TEMPLATES.md のテンプレートを使用します。標準の成果物一式：

1. エンゲージメントの前提 - スコープ、制約、対象外事項
2. 優先順位付きチェックリスト - 対象に対する想定影響度と作業量の順
3. 安全なコマンドの例 - プレースホルダーのみを使用し、必要なツールを記載
4. 証拠の計画 - 何を記録するか（リクエスト／レスポンス、スクリーンショット、ID）
5. 報告書のドラフト - 問題が確認された後に限り作成するか、仮説 と明確に記載します

チェックリストは、実行に移せる内容にしてください。チェックボックス 1 つにつき、検証可能な主張を 1 つにします。

6. アクティブテストの実施条件

ライブ環境への攻撃手順を推奨する前に、次の事項についてユーザーの確認を求めてください。

• スコープ内のターゲット
• 使用を許可されたアカウントとロール
• 本番環境が対象に含まれるかどうか
• 上記の影響の大きい操作が許可されているかどうか

ユーザーが確認を拒む、または判断できない場合は、計画の策定、偵察のみのガイダンス、あるいはラボでの演習を続けてください。

7. 証拠と報告

報告書のドラフトを作成する前に、よくある誤検知のパターンを除外してください。WAF やプロキシがペイロードを実行せずにそのまま返している、タイミングのノイズをブラインドインジェクションの兆候と誤認している、すでに公開または修正済みの挙動である、同じプログラムに対する重複報告である、といったパターンです。独立した 2 回目の再現テストで兆候を再確認できない場合は、報告としてではなく仮説として扱ってください。

確認済みの各報告について、次の事項を記録してください。

• タイトル、深刻度（根拠を含む）、影響を受けるアセット
• 再現手順（最小限の番号付き手順）
• 証拠（サニタイズ済み）
• 影響と修正方法
• 引用したリポジトリと外部の参考資料

ユーザーから提供された証拠、またはユーザーが実施した許可済みの実行結果なしに、脆弱性が確認済みであると主張しないでください。推測に基づく項目には、仮説と明記してください。

引用形式

使用したソースは必ず引用してください。

Sources:
- `Web Application Pentesting/Vulnerabilities/SSRF/readme.md`
- https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

クローンを使用する場合は、リポジトリ内の正確な相対パスを使用してください。

このスキルの対象外

• システムへの攻撃を許可するものでも、許可を意味するものでもありません
• 書面によるルール・オブ・エンゲージメントやバグバウンティポリシーに代わるものではありません
• リモートターゲットに対してエクスプロイトを自動実行するものではありません
• ユーザーから別途依頼がない限り、リポジトリへの新しいコンテンツの追加は行いません（CONTRIBUTING.md を参照）

追加リソース

• ドメインのインデックスと検索ルール：REPOSITORY_MAP.md
• 計画、チェックリスト、証拠、調査結果のテンプレート：OUTPUT_TEMPLATES.md
• 貢献ガイド：https://github.com/m14r41/PentestingEverything/blob/main/CONTRIBUTING.md