pentest-playbook について
ペネトレーションテスト担当者向けの7段階ワークフロースキルです。パッシブ調査からエクスプロイト、報告までを扱い、各段階に対応するスキルを示します。行き詰まった際の別経路の判断点と、同じ試行を続けないためのルールも含みます。
主な機能
- 017段階のペンテストワークフロー
- 02段階別スキルの案内
- 03別経路を探す判断点
- 04攻撃ベクトルの切り替えルール
- 05報告と修正のワークフロー
- 06発見事項の検証
活用シーン
- 01未知の対象に対するペンテスト全体を計画
- 02攻撃経路が停滞した際に別の調査方向を選択
- 03証拠を整理し報告内容を検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ uphiago/ recon-skills --skill pentest-playbookインストール後、Claude Code で/pentest-playbookを入力して読み込まれたか確認します。
詳細
ペンテストプレイブックスキル
パッシブな偵察からエクスプロイトとレポート作成まで、ライフサイクル全体を網羅する7フェーズのペンテストパイプラインです。政府、ヘルステック、フィンテック、Eコマース、ISP、中小企業の各セクターで、100以上のターゲットから得られた知見をまとめています。これは「メタプレイブック」です。エンゲージメントの各段階で何をすべきか、各フェーズでどのスキルを読み込むべきかを示します。
使用するタイミング
- ターゲットが不明な新しいペンテストエンゲージメントを開始するとき。
- あらゆる種類のターゲットに対応する標準的なワークフローが必要なとき。
- サーフェス偵察の後、次に何をすべきかを確認するとき。
- トレーニングで、プロフェッショナルなペンテストのライフサイクル全体を理解するとき。
7フェーズのパイプライン
| フェーズ | 名前 | 焦点 | 主なスキル | 所要時間 |
|---|---|---|---|---|
| 1 | パッシブ偵察 | OSINT、サブドメイン、漏えい、技術スタック | subdomain-enumeration, offensive-osint | 30-60 min |
| 2 | アクティブ偵察 | ポートスキャン、稼働中のホスト、技術の検出 | port-mass-scan, port-service-discovery, web2-recon | 30-60 min |
| 3 | Web 列挙 | 機密ファイル、.env、CORS、JS シークレット | web-enumeration, cors-credential-wordpress, js-secrets-extraction | 20-40 min |
| 4 | フレームワークのエクスプロイト | WordPress、Laravel、Spring、.NET | hunt-wordpress, hunt-laravel, hunt-springboot, hunt-aspnet | 30-60 min |
| 5 | クラウドとインフラストラクチャ | Firebase、Supabase、S3、Cloud Functions | hunt-firebase, hunt-supabase, cloud-iam-deep | 30-60 min |
| 6 | 詳細なエクスプロイト | SQLi、SSRF、RCE、ATO、攻撃チェーン | hunt-sqli, hunt-ssrf, cross-attack-chains | 1-4 hours |
| 7 | レポートと修正 | ドキュメント、PoC、CVSS スコアリング | report-writing, triage-validation, evidence-hygiene | 1-3 hours |
フェーズごとの手順
フェーズ 1 — パッシブ偵察
# 1. Subdomain enumeration
subfinder -d $TARGET -silent | tee subs.txt
curl --max-time 30 --connect-timeout 10 -s "https://crt.sh/?q=%.$TARGET&output=json" | jq -r '.[].name_value' >> subs.txt
# 2. Tech stack detection via response headers
curl --max-time 30 --connect-timeout 10 -sI "https://$TARGET" | grep -iE "server|x-powered-by|x-aspnet|x-generator|x-runtime"
# 3. Google dorks
# site:$TARGET filetype:env DB_PASSWORD
# site:$TARGET "-----BEGIN RSA PRIVATE KEY-----"
# 4. GitHub code search (SA keys, .env, credentials)
# See google-dorks-catalog skill for full list
フェーズ 2 — アクティブ偵察
# 1. Port scan (top 1000 ports)
rustscan -a $TARGET --ulimit 5000 -g | tee ports.txt
# 2. HTTP probe on alive hosts
cat subs.txt | httpx -silent -status-code -title -tech-detect | tee live.txt
# 3. CORS quick test
curl --max-time 30 --connect-timeout 10 -skI "https://$TARGET/wp-json/wp/v2/users" -H "Origin: https://evil.com" | grep -i "access-control"
フェーズ 3 — Web 列挙
web-enumeration スキルを完全に実行します。200以上の機密ファイルパス、.env の抽出、パストラバーサルのバイパス、vHost の列挙が含まれます。
フェーズ 4 — フレームワークのエクスプロイト
検出されたフレームワークに応じて、該当する hunt-* スキルを読み込みます。
- WordPress:
hunt-wordpress+wp-mass-recon - Laravel:
hunt-laravel - Spring Boot:
hunt-springboot - ASP.NET:
hunt-aspnet
フェーズ 5 — クラウドとインフラストラクチャ
- Firebase:
hunt-firebase(API キー → Firestore → Storage) - Supabase:
hunt-supabase(匿名キー → RLS のバイパス) - Cloud IAM:
cloud-iam-deep(SA キー → GCP トークン → IAM ポリシー) - Docker:
docker-privesc(コンテナーにアクセスできる場合)
フェーズ 6 — 詳細なエクスプロイト
cross-attack-chains スキルを使って、発見事項を連鎖させます。確認済みの5つのチェーン(A-E)により、個別の Medium/High の発見事項を Critical な影響へと高められます。
フェーズ 7 — レポート
バグバウンティには report-writing スキルを、クライアント向けの成果物には redteam-report-template を使用します。提出前に triage-validation の7つの質問によるゲートを適用してください。
横方向へのピボットを判断するポイント(重要な手法)
ブルートフォースや直接攻撃で結果が得られない場合は、固執せず、横方向の探索に切り替えてください。 これはペンテストにおいて、最も重要な判断です。
ピボットのきっかけ — ベクトルの切り替え時を見極める
| シグナル | 現在のベクトル | 切り替え先 |
|---|---|---|
| 100 個以上のパスワードを試しても、一致するものがない | ブルートフォース(ログイン) | SSRF、CORS、サブドメイン列挙、API 発見、ソース漏えい、オープン登録、Firebase/Supabase |
| MySQL/SSH で一般的な認証情報がすべて失敗する | データベース/SSH のブルートフォース | API 発見(HTTP サービスのポートスキャン)、JS バンドル内のシークレット、Firebase 設定、CORS によるデータ窃取 |
| すべてのペイロードで WAF/403 が返される | Web エクスプロイト | CDN のバイパス(オリジン IP の特定)、サブドメイン列挙(ステージング/開発環境には WAF がない可能性があります)、標準外ポートの API、HTTP メソッド/ヘッダーの改ざん |
| レート制限 / CAPTCHA / ロックアウト | 認証ブルートフォース | SameSite のバイパス、OAuth の設定ミス、MFA 疲労攻撃、パスワードリセットの汚染、SSO トークンの再利用 |
| すべての API エンドポイントで 401/403 が返される | API エクスプロイト | OPTIONS プリフライト、メソッドの改ざん(GET→POST、PUT→PATCH)、Content-Type の切り替え(JSON→XML→form)、ヘッダーインジェクション(X-Forwarded-User、X-Original-URL)、JWT の alg=none |
| SPA がすべてのパスで同じ HTML を返す | パス列挙 | 他のポート上の API を確認(8080、8443、3000、5000、8084)、JS バンドルからルートを抽出、ソースマップ、Firebase/Supabase、CORS によるデータ窃取 |
| メインアプリで脆弱性が見つからない | アプリのエクスプロイト | 関連アプリ(同じ IP/証明書/ヘッダーなら同じコードの可能性があります)、サブドメイン、ステージング/開発環境、モバイル APK、CMS 管理パネル、フォーラム/コミュニティソフトウェア |
横方向の発見チェックリスト(行き詰まったら実行)
あるベクトルで成果が出ないときは、対象に問題がないと判断する前に、以下を体系的に確認してください。
- 上位 20 位以外のポート — 重要な対象には nmap -p-、/24 の範囲には masscan を実行します
- 標準外ポートの API — 8080、8081、8084、8443、3000、5000、9090、9000
- サブドメイン — subfinder + crt.sh(staging、dev、admin、api、mail、cpanel、shop)
- JS バンドル内のシークレット — Firebase API キー、AWS/GCP 認証情報、内部エンドポイント、JWT
- オープン登録 — wp-login.php?action=register、/signup、/register エンドポイント
- CORS によるデータ窃取 — ACAO の反射 + ACAC:true = 認証済みの被害者からブラウザーで読み取り可能なデータ
- Firebase / Supabase — JS 内の API キー → 匿名認証 → Firestore/RTDB の読み取り
- エラーログ — /error_log、/debug.log、/wp-content/debug.log(パス、SQL、認証情報が 1MB 以上記録されていることがよくあります)
- ソースコードの漏えい — .git/HEAD、.env、sitemap.xml、robots.txt の disallow パス、ソースマップ
- 関連アプリの一斉調査 — 同じ IP / 証明書 / ヘッダーなら、別のパスにも同じ脆弱なコードテンプレートがある可能性があります
3 回試行ルール
単一の攻撃ベクトルに 5 分以上費やす前に、次のことを行ってください。
- 主なアプローチを試します(例:multicall でパスワードを 100 個試す)
- 横方向のピボットを 1 つ試します(例:オープン登録を確認する)
- 独創的な代替手段を 1 つ試します(例:CORS、Firebase、JS のシークレットを確認する)
異なる 3 回の試行すべてが失敗した場合、そのベクトルの成功確率は低いと考えられます。試した内容を記録して、次に進んでください。同じことをさらに繰り返して、同じベクトルに戻らないでください。質的に異なる切り口を探してください。
アンチパターン:ブルートフォースの罠
"Let me just try 100 more passwords..."
"Maybe I need a bigger wordlist..."
"Let me try one more round..."
🚫 中止してください。 最初の 100 個の標的型パスワードが通らなかったなら、次の 10,000 個も通りません(実際に使われているパスワードの場合)。代わりに、次のことを確認してください。
- 認証自体があるかどうかを確認します(CORS の認証不要エンドポイント)
- 登録がオープンかどうかを確認します(自分でアカウントを作成する)
- 偽造可能な JWT が使われているかどうかを確認します(alg=none、弱い HMAC)
- 別の認証経路があるかどうかを確認します(SSO、OAuth、SAML)
- まったく別の対象に移ります
注意点
- フェーズ 1 を省略しないでください。 重大な発見の多くは、受動的な偵察(ソースの漏えい、GitHub SA キー)から得られます。
- フェーズ 2 に 15 分以上かけないでください。 簡易的な絞り込みで十分です。詳細な調査はフェーズ 6 まで取っておいてください。
- OPSEC は必須です。 最初から proxy-ns または proxychains + Tor を使用してください。接続元 IP を決して露呈させないでください。
- .env が常に発見事項になるとは限りません。 実際の認証情報(DB_、APP_KEY)が含まれていることを確認してください。SPA のキャッチオール HTML だけの場合は該当しません。
- 作業しながら記録してください。 フェーズ 7 まで待たないでください。正確なコマンドを忘れてしまいます。
- ピボットのトリガーを超えてブルートフォースしないでください。 横展開に移る前に、ベクトルごとに対象を絞ったパスワードを最大 100 個まで試してください。
検証
- 各フェーズには明確な終了条件があります(例:「スコア >= 6 → フェーズ 6 にエスカレーション」)。
- すべての発見事項は、正確なコマンドを使って再現できなければなりません。
- 報告する前に、すべての発見事項が 7 つの質問によるゲートを通過している必要があります。