hack

HACKING SKILLS / HackSkills

概要

これは、許可を得たバグバウンティ、Web／API セキュリティ、ペネトレーションテスト、コード監査、ソース漏えい調査、および（タスクがブルーチームの場合の）SOC／検知／インシデント対応（IR）におけるマスター品質ゲートおよび技術ルーターです。

専門的な手法に取って代わるものではありません。エージェントが次のことを行えるようにします。

1. 開始ゲートを通過する（認可、役割、スコープ、成功の定義）
2. 実際の制御につながる経路に労力を注ぐ
3. 観測された挙動に基づき、適切なカテゴリ／詳細トピックのスキルに振り分ける
4. ベースラインモデルの記憶やスキャナーの出力より、体系的な手法を優先する

このファイルは品質ゲートであり、能力の上限ではありません。ここに記載されていない対象領域も、現場の証拠があれば引き続き対象となります。

このファイルはエクスプロイトの手引きではありません。悪用可能な詳細は詳細トピックのスキルに記載され、認可されたターゲットにのみ使用されます。

必要に応じて読み込みます。

• レッドチームの実行 → RED_TEAM.md
• テストマトリックスと工数 → TEST_MATRIX.md
• ブルーチームの実行 → BLUE_TEAM.md
• コード監査 → CODE_AUDIT.md
• ソース漏えい → SOURCE_LEAK.md
• 証拠とレポート → EVIDENCE_REPORT.md

0. タスク開始ゲート

順番に完了してください。項目が不足している場合は中止します。

1. 認可：書面による認可、RoE、スコープ、禁止事項、連絡先、緊急停止手順。認可がない場合は拒否します。
2. 役割：レッドチームテスト／コード監査／ソース漏えい／ミドルウェア監査／ブルーチームのトリアージ／検知エンジニアリング／IR。並行作業は可能ですが、主たる役割は1つだけです。
3. スコープモード：
   • ユーザーから固定 URL／システム／リポジトリが指定された場合 → 固定スコープ：同一製品のホスト、ゲートウェイ、API ドメイン、およびビジネスフローで自然に露出する同一ホスト上の追加パスを対象とします。無関係なブランド系列をスキャンしてはいけません。
   • ユーザーから組織名が提示され、境界資産の特定を求められた場合 → 探索スコープ：次の対象へ進む前に、現在の資産クラスターを調査し終えます。多数の起点を浅く調査してはいけません。
4. 成功の定義：このタスクで「完了」が何を意味するかを定めます。スキャナーの完了、レポートの出力、チケットのクローズは成功ではありません。
5. 破壊行為の境界：決して行ってはならない操作を列挙します。
6. テスト前の作業ディレクトリ：assets/（URL、API インベントリ、スクリプトの抜粋）、evidence/（リクエスト、差分、スクリーンショット）、reports/（確認済みの検出事項のみ）。
7. 質問：スコープが不明確な場合は、技術的な阻害要因（ターゲット、スタック、アカウントの有無）のみを1～3個質問します。中断するために「続行してよいですか」と尋ねてはいけません。2つ目のアカウントがない場合は、テスト可能な範囲に縮小し、アカウントBを待って何もせずにいてはいけません。

認可されていない資産に対象を広げてはいけません。

1. 厳守事項

• スコープ内にとどめてください。スコープ外の手掛かりは記録し、対象範囲の拡大を依頼してください。黙って対象範囲を広げてはいけません。
• 破壊的なテストや破壊的な封じ込めは禁止です。他者の業務データの削除、DROP/TRUNCATE、一括設定変更、暗号化・ランサムウェアのような操作、無制限のDoS、ログの消去、イメージの消去を行ってはいけません。
• アクセスを証明する書き込み操作では、識別可能なテストオブジェクトのみを作成し、そのオブジェクトをただちに削除してください。他者の注文、住所、パスワード、ロール、バインディングを変更してはいけません。課金、在庫の消去、アカウントロックも行ってはいけません。
• ユーザーから提供されたセッションをログアウト、失効、無効化してはいけません。影響を証明するためにパスワードやバインディングの変更が必要な場合は、ただちに元に戻してください。元に戻せない場合は、そこで対応を止めてください。アカウントを使用不能にしてはいけません。
• 侵害を証明するために、取り返しのつかない損害を与えてはいけません。読み取り専用、コピー、または低い権限での証明を優先してください。
• 証拠は読みやすく、再現可能でなければなりません。再現手順のない結論は仮説です。
• PoC、ログ、エクスプロイトチェーンを捏造してはいけません。パス、ファイル、クエリ、スクリーンショットに整合性がない場合は、評価を引き下げるか撤回してください。
• コピーしたシークレットは、有効性確認ゲートを通過するまでは手掛かりです。本番環境で実際の値が受け入れられ（偽の値は拒否され）、読み取り専用の呼び出しでIDまたはオブジェクト一覧が返される必要があります。
• セッションを使って見つかった問題は、「匿名での不正アクセス」ではありません。侵害時にログイン状態がなかった場合に限り、匿名とみなします。
• 内部ユーザーについては、タイムラインで裏付けられるまでは、誤検知またはミスだと想定してください。
• セキュリティ制御が実際の業務を妨げる場合、その制御は回避されます。修正には、利用可能で安全な手段を含める必要があります。

2. 役割の振り分け

ユーザーの意図	主なフロー	読み込む資料
ペネトレーションテスト／レッドチーム／足掛かりの確保／SRC	§§3–5	RED_TEAM.md、TEST_MATRIX.md
コード監査／ホワイトボックス／シンクの特定	§3 R6	CODE_AUDIT.md
ソース漏えい／Git漏えい／シークレット漏えい	§3 R5	SOURCE_LEAK.md、insecure-source-code-management
ミドルウェア／ゲートウェイ／コンポーネントの監査	§3 R7	RED_TEAM.md のミドルウェアセクション、unauthorized-access-common-services
アラートのトリアージ／SOC／脅威ハンティング	ブルーチーム品質ゲート	BLUE_TEAM.md
検知ルール	ブルーチーム B6	BLUE_TEAM.md、EVIDENCE_REPORT.md のテンプレート
IR／フォレンジック／封じ込め	ブルーチーム B7	BLUE_TEAM.md、memory-forensics-volatility、traffic-analysis-pcap
レポートの作成	§6	EVIDENCE_REPORT.md

タスクがレッドチームとブルーチームにまたがる場合は、役割を切り替える前に、現在のフェーズの証拠を保全してください。

3. 運用モデル

ステップ 1：アプリケーションから攻撃対象領域を把握する

URLまたはアプリケーションを受け取ったら、まず攻撃対象領域をマッピングしてください：attack-surface-mapping。プロファイル、ビジネスプレーン、JS／トラフィックの一覧（パスだけでなくキーも含む）、レスポンスの分類、オブジェクトグラフを把握します。プロファイルが空のままスキャンを始めてはいけません。ディレクトリの総当たりやペイロードの大量送信から始めてはいけません。

ステップ 2：観察された挙動から振り分ける

シグナル	最初に確認する項目	読み込む内容
入力が HTML ／ JS に反映される	XSS ／ SSTI	injection-checking
サーバーが URL ／ホスト名を取得する	SSRF	ssrf-server-side-request-forgery
XML ／ Office ／ SVG を受け付ける	XXE	xxe-xml-external-entity
パス、ファイル名、またはダウンロードを制御できる	パストラバーサル ／ LFI	path-traversal-lfi
API にオブジェクト ID が多数ある	IDOR ／ BOLA ／ BFLA	auth-sec、idor-broken-object-authorization
ログイン、リセット、2FA、セッション	認証バイパス ／ JWT ／ OAuth	auth-sec
金銭、クーポン、在庫、承認を伴う複数ステップの処理	ビジネスロジック ／ 競合状態	business-logic-vuln
MongoDB ／ JSON クエリ構文	NoSQL	nosql-injection
CLI ツール、画像処理、インポーター	コマンドインジェクション	cmdi-command-injection
HTTP の解析 ／ フロントエンドとバックエンドのフレーミングの不一致	リクエストスマグリング	request-smuggling
Node の JSON ／ 制御可能な __proto__	プロトタイプ汚染	prototype-pollution
PHP の弱い比較 ／ 0e ハッシュ	型ジャグリング	type-juggling
パラメーター名の重複 ／ WAF とアプリの解析の不一致	HPP	http-parameter-pollution
使い切りクーポン ／ 在庫 ／ リセット ／ 招待	競合状態	race-condition
XML ／ XSLT テンプレート	XSLT	xslt-injection
.git ／ .svn ／ .env ／ バックアップ ／ 公開バケット	ソースコード漏えい	SOURCE_LEAK.md
CSV ／ Excel のエクスポート	CSV 数式インジェクション	csv-formula-injection
WebSocket アップグレード	WebSocket	websocket-security
内部パッケージ名	依存関係の混同	dependency-confusion
業務 API が 401 ／ 403 を返す	パス ／ メソッド ／ ヘッダーのバイパス	401-403-bypass-techniques
公開ミドルウェアの管理画面 ／ デフォルトポート	デフォルト認証情報、デバッグ、バージョンの不具合	unauthorized-access-common-services
コマンドツールを備えたチャットアシスタント	ツールが実際に実行されるか	llm-prompt-injection
ファイルのアップロード ／ プレビュー ／ 変換	アップロードの連鎖 — 保存とダウンロードだけで終わらせないでください	upload-insecure-files
GraphQL ／ OAuth JWT ／ ゲートウェイ	該当する専門項目を確認し、完了にチェックするか N/A と記入する	api-sec、jwt-oauth-token-attacks

1 つのチェック項目を開いても、その項目だけを試せばよいわけではありません。残りのマトリックスも確認してください。

ステップ 3：次の順で取り組みます

完全な合否基準：TEST_MATRIX.md。デフォルトの順序：

1. 認証されていない状態で、別のユーザー、テナント、または対象にアクセスできるか
2. 認証の乗っ取り（セッションの発行、リセット、再バインド、チケットの差し替え）— セッション内またはパスワード変更も該当します
3. オブジェクト識別子を差し替える（フィールド名は問いません：id / userId / tenantId / fileKey / openid / 暗号文の PK）
4. セッションがある場合は、オブジェクトグラフをたどります：一覧 → 詳細 → 添付ファイル／エクスポート／承認、その後に書き込みとビジネスロジック
5. 差分が確認できる箇所に限り、インジェクション／SSRF／XSS／コマンドまたはテンプレートの実行を調べる
6. ページやスクリプト内のソルト、ハードコードされたキー、デモアカウント

中途半端な攻撃チェーンで止めてはいけません。 保存されるアップロード、送信される OTP、コピーされた秘密の文字列だけでは完了ではありません。オブジェクトで中程度の問題を確認したら、対象を変える前に、書き込み／他ユーザーへの影響／乗っ取り／実行に至るかを追跡します。

ビジネスフィールドを含まない、完全な「ログインしてください」という応答は、インジェクションの攻撃対象ではありません。空の一覧、エラー、タイムアウトは「ログインしてください」には該当しません。

対象を広げる前に、現在のアセットクラスターを調べ終えてください。

R1. コンプライアンスではなく、影響を重視する

影響力のある制御につながる最短の経路を優先します。各候補について、攻撃者は今、実際のユーザーやシステムに被害を与えられるでしょうか？報告では攻撃チェーンを説明し、CVSS は補足資料として扱います。「ロール上許可されている」テナント管理者の権限でも、プラットフォーム管理者、他のテナント、または他のユーザーに到達するなら、指摘対象です。RED_TEAM.md の影響度の段階に従って指摘事項を順位付けします。レイヤー 7（純粋なコンプライアンス）は補足資料のみです。

R5. ソースコードの漏えい：手掛かりを最後まで追う

「.git が公開されている」や「リポジトリが公開されている」だけで終わらせてはいけません。SOURCE_LEAK.md：ツリー全体と履歴 → シークレットと隠れた攻撃対象の一覧化 → 有効なままのシークレットを最小限の読み取り専用リクエストで実環境にて検証 → 漏えいを新たな攻撃対象リストとして扱います。

R6. コード監査：シンクからソースへ、またはソースから先へ

CODE_AUDIT.md。完全な汚染経路がない場合、またはサニタイザーの有効性が確認された場合は、確定した問題として報告しないでください。

R7. ミドルウェア監査はドキュメントに基づいて行う

対象のメジャーバージョンに対応する公式ドキュメントを読み、チェックリストを作成し、項目ごとに検証の記録を残します。比較表のないミドルウェアの結論は未完了です。

Blue 品質ゲート（主な役割が Blue の場合）

成功の指標は対応完了率ではなく、滞留時間の短縮です。詳細：BLUE_TEAM.md。

• B1. まず、今すぐデータ、権限、または事業に損害が及ぶかを確認します。文脈のないアラートを 100 件出すより、確度の高いイベント 1 件とタイムラインのほうが有効です。
• B2. 主なリスクはアラート疲れです。人が確認する前に情報を付加します。すべてのルールに担当者、誤検知の特性、遡及期間、廃止条件を設定します。6 か月間アラートがない場合は、まずログソースを確認します。
• B3. 封じ込めは、元に戻せる方法を基本とします。証拠を保全し、その後に封じ込め、最後に根絶します。ログの消去は封じ込めではありません。
• B4. 結論には、再現可能なクエリ、タイムゾーン、アセット／ユーザー／送信元 IP、生の抜粋、ラベル（TP / benign TP / FP / insufficient evidence）が必要です。
• B5. 対象期間内に、同じユーザー、ホスト、IP、トークン、ハッシュを範囲に含めます。インテリジェンス、IOC、漏えいサンプルがケースに持ち込まれた場合は、ソースコード漏えいと同じ重大度で扱います。
• B6. 検知エンジニアリングでは、検知すべき挙動から逆向きにたどります。まず厳格で確度の高いルールを設定します。BLUE_TEAM.md の品質ゲートを参照してください。
• B7. IR は承認済みのプレイブックに従います。新しいログソースについては、ルールのリリース前に、フィールド辞書、カバレッジマップ、既知の誤検知、担当者、廃止基準を用意します。

4. 中核スキルマップ

リポジトリ全体が含まれている場合は、これらをまとめて使用してください。以前は独立していたミニスキル（payload-selection、brute-selection）は、メインスキルに再統合されました。

• 攻撃対象領域のマッピング · 偵察と手法
• XSS · SQLi · SSRF · XXE · SSTI
• IDOR · CMDi · パストラバーサル／LFI · CSRF
• API セキュリティルーター · JWT／OAuth · OAuth／OIDC · SAML · 認証バイパス
• ビジネスロジック · アップロード · NoSQL · リクエストスマグリング
• プロトタイプ汚染 · 型ジャグリング · HPP · 競合状態
• XSLT · 安全でない SCM · CSV 数式 · WebSocket · 依存関係の混同
• CORS · Ghost Bits Cast · 401/403 バイパス · 一般的なサービス

5. 価値の高い専門家の直感

現実のバグ報奨金活動で頻繁に役立つ、ベースラインモデルが見落とすポイント：

1. 同じフィルターが複数のページで再利用される：一度見つけたバイパスは、ほかのページにも適用できることが多いです。
2. パラメーター名も攻撃対象領域です：WAF は値を検査し、名前を検査しないことがよくあります。
3. 二次的な脆弱性はよくあります：保存時に安全でも、後から危険なコンテキストに読み込まれると安全とは限りません。
4. BOLA は「認証済みだが認可されていない」状態です：アカウント A と B を切り替えながらリプレイしてください。
5. 古い API バージョンにはパッチが適用されていないことがあります：v2 を修正しても、v1 が廃止されるわけではありません。
6. ビジネスロジックのバグは、最も影響が大きいことがよくあります：スキャナーは見落とし、脆弱性は長く残ります。
7. 競合状態では、一度限りの操作を優先してください：引き換え、獲得、リセット、招待、トライアル、在庫の減算などです。
8. JWT では、まず鍵とアルゴリズムのコンテキストを確認してください：alg、kid、JWKS、鍵の取得元を調べ、手当たり次第に試さないでください。

6. 出力基準

対象読者に応じて、デフォルトでは次の3層で構成します。

1. 判断：何が起きたか、影響、今すべきこと（1ページ）
2. 技術情報：攻撃チェーンまたはイベントのタイムライン、再現手順またはクエリ、証拠
3. 改善：修正／検知／ログの欠落／プロセスの欠落。それぞれ担当者と検証方法を明記

EVIDENCE_REPORT.md のテンプレートを使用してください。中程度以上の場合は、すぐにディスクに書き込んでください。深刻な場合は、許可された連絡先に直ちに通知してください。

調査結果を「確認済み」とする前に、次の2つのゲートを通過してください。

• セッション帰属ゲート：問題を引き起こしたリクエストにセッションが含まれていた場合は、「匿名の不正アクセス」ではなく、IDOR／認証の問題として記述してください。
• シークレットの有効性ゲート：偽のシークレットが拒否され、実際のシークレットが受け入れられること、さらに読み取り専用の呼び出しで ID または一覧が返ることを確認してください。そうでなければ、手掛かりにすぎません。

7. アンチパターン

• スキャナーの出力をペンテストレポートとして扱うこと。ビジネスへの影響の代わりに CVSS を示すこと。件数を水増しするために、悪用できない仮説を報告すること
• .git や秘密の文字列を単なる情報漏えいとして報告すること。ソースからシンクまでの経路を示さず、危険な関数名を列挙するだけのコード監査
• 公式ドキュメントと比較せず、記憶だけに基づいてミドルウェアの結論を出すこと
• ロックアウトポリシーを読む前にパスワードを大量に試すこと。各パスでクォートを1つ試しただけで「インジェクション完了」とすること
• アップロードによる保存、OTP の送信、またはコピーされた秘密情報の段階で止めること
• セッションに関する指摘を、匿名ユーザーによる不正アクセスとして記述すること
• 空のプロファイルでスキャンすること、またはパスだけを抽出したスクリプトを使うこと
• すべての項目を「ログインしてください」という同じ応答に押し込むこと
• ブルーチームをクローズ率で評価すること。証拠が不十分なアラートを FP として扱い、そのまま忘れること。実際のログで一度もテストしていないルールを本番適用すること。封じ込め中に唯一の証拠を消去すること
• 誰も使えず、シャドー IT を強いる「安全な」フローを設計すること
• 一覧にないフィールドの攻撃面が存在しないふりをすること
• このファイルに記載がないものはすべて禁止だと扱うこと

推奨プロンプト

• 「この URL しかありません。テストの前に、アプリケーションから攻撃面を洗い出してください。」
• 「バグバウンティの手法を使い、影響を優先して、このターゲットのテスト経路を計画してください。」
• 「これは REST API です。BOLA、BFLA、マスアサインメント、JWT を優先してください。」
• 「このパラメーターはサーバー側リクエストを引き起こします。SSRF の検証ポイントを列挙してください。」
• 「決済／クーポン／在庫のフローです。ビジネスロジックと競合状態を優先してください。」
• 「ログインとパスワードリセットしか見当たりません。Auth Bypass ＋ OAuth/JWT ＋ CSRF を調べてください。」
• 「このリポジトリをシンクからソースへ監査してください。汚染経路のない指摘は出さないでください。」
• 「.git が公開されています。履歴を調べ、秘密情報が現在も有効か確認してから、新たな攻撃面の一覧として扱ってください。」

インストールに関する注意

推奨スキル名：hack

検索キーワード：HackSkills、HACKING SKILLS、bug bounty、security engineer ops

ガイドライン

• 無作為にペイロードを列挙するのではなく、ターゲットの種類と観測された挙動に基づいて経路を選んでください。
• ペイロードには、該当する深掘りスキルの初回テスト用サンプルを使い、中間ルーターを追加しないでください。
• 再利用可能なフィルター、共通コンポーネント、複数ページにまたがる再現を優先してください。
• 深く悪用する前に、認証、認可、バージョンの境界を確認してください。
• プロセスを説明可能、監査可能、再現可能な状態に保ってください。
• リポジトリ全体のコンテキストがある場合は、悪用の詳細について各トピックのドキュメントに戻ってください。