Hermes Agent Wiki 非公式・日本語wiki
この skill をそのまま使う: GitHub で原文を見る

英語原文・frontmatter 込みで、Hermes が読み込む実体そのままです（このページの本文は日本語版）。

Web Pentest

目次

許可を得た Web ペンテスト: 偵察、証拠ベースの攻撃、レポート。

skill の情報
提供元 オプション — hermes skills install official/security/web-pentest で導入します
パス optional-skills/security/web-pentest
バージョン 1.0.0
作者 Teknium (teknium1), Hermes Agent
ライセンス MIT
対応プラットフォーム linux, macos
タグ Security, Pentest, Web, Recon

参考: SKILL.md 全文

Web アプリケーションのペネトレーションテスト

稼働中の Web アプリケーションに対する、フェーズ分けされたペンテストのワークフローです。 Shannon のパイプライン（Keygraph、AGPL — 概念のみで、コードは借用していません）を 参考にしています。3 つのルールを軸に組み立てられています。

  1. 攻撃なくしてレポートなし — すべての発見には、再現可能な証拠が必要です。
  2. 範囲を限定する — すべての能動的リクエストは、オペレーターが事前に宣言した対象に対して

行います。範囲外のホストは拒否します。

  1. 偽陽性と切り捨てる前にバイパスを尽くす — 「ブロックされた」ペイロードは、バイパスの

セットを試すまで、無害の証明にはなりません。

⚠️ ハードガードレール — すべての実施の前に読むこと

これらのいずれかに違反すると実施は無効になり、違法となる場合があります。

  1. 認可のゲート。 セッションで最初の能動スキャンを行う前に、対象を所有しているか、

テストする書面の許可があることを、ユーザーと書面で確認しなければなりません。承認を engagement/authorization.md に記録します（テンプレートを参照）。承認がなければ、能動 スキャンはしません。curl で公開ページを読むのは可ですが、ペイロードを送るのは不可です。

  1. 範囲の許可リスト。 engagement/scope.txt を維持します — 1 行に 1 つのホスト名または

CIDR です。すべての nmap、curl、whatweb、ブラウザナビゲーション、ペイロードを伴う リクエストは、範囲内のエントリに対して行わなければなりません。対象が範囲外へリダイレクト したら（別ホストへの 3xx、HTML 内のリンク）、そこで止めて、たどる前にユーザーに確認します。

  1. 書面なしに本番システムはなし。 ユーザーが「はい、本番は範囲内で、書面の承認があります」と

言っていなければ、範囲外と仮定します。既定の対象はステージング、ローカル docker、専用の テストインスタンスです。

  1. クラウドのメタデータは既定でオフ。 実施が SSRF からメタデータへの到達を目標として明示的に

含み、かつ対象が自分の管理下にあるのでない限り、169.254.169.254、metadata.google.internal、 100.100.100.200、[fd00:ec2::254]、あるいは同等のものをプローブしてはいけません。エージェントの ブラウザツールは、自分のインフラの内側からこれらに到達できてしまいます — してはいけません。

  1. 破壊的なペイロードには承認が必要。 DROP／DELETE する SQLi ペイロード、ファイル書き込みの

SSTI、rm／shutdown／mkfs を伴うコマンドインジェクション、単一のテスト行を超えて変更する もの → まず尋ねます。approval.py のしくみは一部を捕まえますが、それだけに頼ってはいけません。

  1. 補助クライアントの漏えいリスク（Hermes 固有）。 この skill は、SQLi／XSS／RCE のペイロード、

取得した認証情報、JWT トークンでいっぱいのセッションを生み出します。Hermes の圧縮とタイトル生成の 経路は、履歴を補助クライアント（多くは主モデル）を通して再生します。会話に書き込んだ機微なものは すべて、次の圧縮でこの箱の外に出ていく可能性があります。緩和策:

  • 取得したトークン／認証情報は、メッセージに記録する前に末尾 6 文字まで伏せます。完全な値は

engagement/evidence/ のファイルに置き、会話履歴には決して入れません。

  • 実施が機微なら、そのセッション用に ~/.hermes/config.yaml で

auxiliary.title_generation.enabled: false を設定します。

  1. 自らレート制限する。 既定では、単一ホストへの能動リクエストの間隔は 200ms です。

recon-scan.sh スクリプトがこれを強制します。オペレーターの承認なしにこれを回避しないでください。

  1. レポートの位置づけ。 この skill が生み出すのはセキュリティ評価であって、「PASS」では

ありません。クリーンな実行でも、「範囲 X で時間 T の中、手法 Y を使って、悪用可能な問題は 見つからなかった」であって、「アプリケーションは安全だ」ではありません。レポートでもその言い回しを 守ります。

フェーズ 0: 実施のセットアップ

スキャンを始める前に、実施ディレクトリと認可の承認を作成します。

ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"
  1. ユーザーに尋ねます（そのままの文言で）:

> 「確認します。(a) 対象 URL は [X] であること、(b) このアプリケーションを所有しているか、 > テストする書面の許可があること、(c) 実施は今から最大 [N] 時間まで行ってよいこと。 > 進めるなら『authorized』と返信してください。」

  1. 明示的な authorized の返答を待ちます。 それ以外の答えは、止めることを意味します。
  1. templates/authorization.md のテンプレートを使って、認可を engagement/authorization.md に

記録します。次を含めます。

  • 対象の URL と IP
  • 認可の根拠（所有 / $name からの書面による認可）
  • 実施の期間
  • 範囲外の項目（本番、第三者サービスなど）
  • オペレーター名（このセッションを操作するユーザー）
  1. scope.txt を作ります:
localhost
127.0.0.1
staging.example.com
192.168.1.0/24    # internal lab only, with operator OK
  1. 最初の能動リクエストを出す前に references/scope-enforcement.md を読みます — その文書には、

出ていくすべてのコマンド／URL に適用するホスト抽出のルールがあります。

フェーズ 1: 事前偵察（コード解析、任意）

ソースにアクセスできない場合（ブラックボックスの実施）は飛ばします。

アプリケーションのソースへの読み取りアクセスがある場合:

  1. アーキテクチャを把握する — フレームワーク、ルーティング、ミドルウェアのスタック
  2. シンクを棚卸しする — すべての execute(、os.system(、eval(、テンプレートの

レンダリング、ファイルの読み書き、リダイレクト先

  1. 認証を把握する — セッションクッキー vs JWT、OAuth のフロー、パスワードリセット、

特権エンドポイント

  1. 信頼境界を特定する — 何が認証済みで、何が未認証か、何が request.* から来るか
  2. 各シンクからリクエストのソースへ後方テイントします。適切なサニタイズ（パラメータ化

クエリ、許可リスト、shlex.quote、よく知られたエスケーパー）が見つかったら早期に打ち切ります。

出力: evidence/pre-recon.md — アーキテクチャマップ、シンクの棚卸し、疑わしい脆弱なコード経路。

これはオフラインの作業です。対象へのトラフィックはありません。

フェーズ 2: 偵察（ライブ、読み取り専用）

攻撃面を把握します。すべてのリクエストは公開ページの GET で、まだペイロードはありません。 それでも範囲は限定されます。

  1. 範囲を確認する。 すべての対象ホスト名 → IP を解決します。IP が範囲内であることを確認します

（「DNS が予期しない先を指す」罠を避けます）。

  1. ネットワーク面（範囲がポートスキャンを許すときのみ）:
nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET

-T4/-T5 ではなく -T3（既定）を使います。よりステルスで、共有環境で IDS/IPS を 引っかけずに済みます。

  1. 技術の指紋採取:
whatweb -v $TARGET_URL > evidence/whatweb.txt
curl -sIk $TARGET_URL > evidence/headers.txt
  1. エンドポイントの発見:
  • ブラウザツール（browser_navigate、browser_get_images、リンクをたどる）でアプリを

クロールします。

  • robots.txt、sitemap.xml、.well-known/* を調べます。
  • ブラウザツールで開発者ツールのネットワークパネルを使い、XHR/fetch の呼び出しを取得します。
  1. 認証面: ログイン、登録、パスワードリセット、セッションクッキー名、トークンの形式を

特定します。まだ認証情報は送りません — 観察するだけです。

  1. 事前偵察と突き合わせる（ソースがある場合）。evidence/pre-recon.md の各発見について、

ライブの面で到達可能だと確認できるか印を付けます。

出力: evidence/recon.md — エンドポイント、技術、認証モデル、入力ベクトル。

フェーズ 3: 脆弱性の解析

脆弱性クラスごとに 1 つの delegate_task を使います。各エージェントは evidence/recon.md （あれば evidence/pre-recon.md も）を読み、templates/exploitation-queue.json を使って findings/<class>-queue.json を生成します。

これらの焦点を絞ったサブエージェントを delegate_task で使います（可能なところは並列で）。

クラス 目標 参照
injection SQLi、コマンド、パストラバーサル、SSTI、LFI/RFI、デシリアライズ references/vuln-taxonomy.md（スロットタイプ）
xss 反射型、格納型、DOM ベース references/vuln-taxonomy.md（レンダーコンテキスト）
auth ログインバイパス、JWT の混同、セッション固定、OAuth の欠陥 references/exploitation-techniques.md
authz IDOR、垂直／水平の権限昇格、ビジネスロジック references/exploitation-techniques.md
ssrf 内部到達性、メタデータ、プロトコルスマグリング 明示的に認可されない限りメタデータは飛ばす
infra 設定ミス、情報漏えい、既定の認証情報、露出した管理画面 references/exploitation-techniques.md

各キューエントリは次を持ちます。id、脆弱性クラス、ソース（わかれば file:line）、 エンドポイント、パラメータ、スロットタイプ、疑われる防御、判定 （identified / partial / confirmed / critical）、ウィットネスペイロード、 確信度（0-1）、メモ。

解析フェーズはまだ悪意あるペイロードを送りません — それらを準備するだけです。 攻撃フェーズが実際にそれらを撃ちます。

フェーズ 4: 攻撃（証拠ベース、条件付き）

解析キューに実行可能なエントリ（identified または partial）があるクラスについてのみ、 そのクラスごとにサブエージェントを走らせます。

各候補について:

  1. 送信前チェック — ホストは範囲内か。認証ゲートは満たしたか。破壊的なら

ペイロードは承認済みか。

  1. ウィットネスペイロードを送る — 最小限の証明。SQLi: ' AND 1=1-- の次に

' AND 1=2--。XSS: <svg/onload=console.log("HERMES-PENTEST-XSS")> のような無害な マーカー。格納型 XSS では決して alert(1) を使いません — 共有環境で他のユーザーに 対して発火してしまいます。

  1. ウィットネスが発火することを確認する — ブラインドインジェクションでは、スリープ

プローブ（SLEEP(5)）を使ってレスポンス時間を計ります。SSRF では、自分が所有する テスター管理のコールバックホストを使います（機微な実施では webhook.site のような公開 サービスは NG — 漏えい経路になります）。

  1. レベルを昇格する:
  • L1 特定 — パターンが一致、挙動の変化なし
  • L2 部分 — シンクに到達したが、防御が働いている
  • L3 確認 — ペイロードがアプリの挙動を観察可能な形で変えた
  • L4 重大 — データが抽出された、コードが実行された、アクセスが昇格した
  1. 偽陽性と分類する前にバイパスを尽くす。 ブロックする各候補について、そのクラスの

references/bypass-techniques.md にあるバイパスセットを少なくとも試します。セットを 尽くしたあとにだけ verdict: false_positive と書けます。

  1. すべての L3/L4 について証拠を記録する:
  • 完全なリクエスト（メソッド、URL、ヘッダー、ボディ）
  • レスポンス（ステータス、ヘッダー、該当するボディの抜粋）
  • 再現コマンド（curl のワンライナー）
  • 影響の記述

出力: findings/exploitation-evidence.md

証拠ファイルでは伏せる:

  • 取得した認証情報／トークン → 会話では末尾 6 文字のみ。完全な値は

findings/secrets-vault.md（gitignore 対象）へ。

  • 他のユーザーの PII → 伏せます。
  • 自分のテスト用認証情報 → そのままで可。

フェーズ 5: レポート

templates/pentest-report.md を使って最終レポートを生成します。セクション:

  1. エグゼクティブサマリー
  2. 実施の範囲（engagement/scope.txt から）
  3. 認可（engagement/authorization.md から）
  4. 発見（L3/L4 のみ — 証拠必須）。発見ごとに:
  • タイトル、深刻度（CVSS 3.1）、CWE
  • 影響を受けるエンドポイント
  • 証拠（リクエスト＋レスポンスの抜粋）
  • 再現手順
  • 影響
  • 是正策
  1. 悪用されなかった候補（L1/L2 と、何がブロックしたかのメモ）
  2. 範囲外の観察
  3. 手法／使用ツール
  4. 制約と、テストしなかったもの

深刻度の方針: CVSS は L3/L4 のみ。L1/L2 は「確認待ちの候補」です — 未確認の発見に CVSS を割り当てません。

いつ止めるか

  • ユーザーが認可を取り消したとき。
  • 候補の発見が明らかに本番データに影響し、破壊的テストの承認がないとき — 止めて尋ねます。
  • 対象が 503/429 の嵐を返し始めたとき — 手を引き、オペレーターと立て直します。
  • 契約された範囲の*外*で何かを見つけたとき（例: 無関係なエンドポイントをテスト中に露出した

顧客データベースを見つけた）。止めて、記録し、オペレーターに報告します。明示的な承認なしに そこへ踏み込まないでください — その踏み込みこそが、ペンテストを違法にするものです。

この skill が扱わないこと

  • ポートスキャンを超えたネットワーク層のペンテスト（Metasploit、Cobalt Strike、AD 攻撃、

ネットワークプロトコルのファジングはなし）。

  • リバースエンジニアリング／バイナリ解析（issue #383 を参照）。
  • ソースのみの静的解析（issue #382 を参照）。
  • 能動的なソーシャルエンジニアリング／フィッシング。
  • オペレーターが事前認可していないシステムに対する一切のもの。

実施にこれらのいずれかが必要なら、専門のペンテスターにエスカレーションします。この skill は 専門のペンテストを補完するもので、置き換えるものではありません。

さらに読む

  • references/scope-enforcement.md — すべての能動リクエストの範囲を限定する方法
  • references/vuln-taxonomy.md — スロットタイプ、レンダーコンテキスト、OWASP マップ
  • references/exploitation-techniques.md — クラスごとのペイロードパターン
  • references/bypass-techniques.md — よくある WAF／フィルターのバイパス
  • templates/authorization.md — 実施の認可テンプレート
  • templates/pentest-report.md — 最終レポートのテンプレート
  • templates/exploitation-queue.json — クラスごとの発見キューのスキーマ
  • scripts/recon-scan.sh — レート制限付きの nmap+whatweb+headers ラッパー