competition-relay-coercion-chain について
強制認証から、中継されたIDをサービスが受け入れるまでを追跡するCTFセキュリティ向けスキルです。`$ctf-sandbox-orchestrator`がサンドボックスの前提と証拠の優先順位を確立した後に使用します。
主な機能
- 01認証強制の発生源を特定
- 02中継先と受け入れ箇所を追跡
- 03取得・再送・受け入れを区別
- 04決定的な証拠へ連鎖を整理
- 05再現可能な証明を保持
活用シーン
- 01強制認証の中継経路を証明
- 02中継IDを受け入れるサービスを特定
- 03トリガーから結果までの証拠を整理
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ zhaoxuya520/ reverse-skill --skill competition-relay-coercion-chainインストール後、Claude Code で/competition-relay-coercion-chainを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yamlreferences/relay-coercion-chain.md
詳細
競合リレー強制チェーン
このスキルは、$ctf-sandbox-orchestrator がすでに有効であり、サンドボックスの前提、ノードの所有権、および証拠の優先順位を確立した後でのみ、下流の専門分野として使用してください。まだそれが行われていない場合は、まず $ctf-sandbox-orchestrator に戻ってください。
このスキルは、強制認証から実際にリレーされた ID を受け入れるサービスまでの完全なチェーンを証明することが難しい部分である場合に使用します。
ユーザーが明示的に英語を要求しない限り、簡体字中国語で回答してください。
クイックスタート
- チェーンを強制の発生源、キャプチャされた認証、リレー先、受け入れポイント、および結果として生じる効果に分割します。
- 各ホップでのトランスポート、プロトコル、およびサービス ID を記録します。
- 強制認証の生成を、リレーの成功および下流の権限から分離します。
- 強制トリガー、リレートランスクリプト、および受け入れサービスを 1 つの証拠チェーンにまとめます。
- 決定的なエッジを証明する最小の強制から受け入れまでのパスを再現します。
ワークフロー
1. 強制の発生源をマッピングする
- 認証を強制するサービス、RPC、ファイルパス、プリンターパス、WebDAV エッジ、またはプロトコルトリガーを特定します。
- ソースホスト、強制されたプリンシパル、トランスポート、および環境上の前提条件を記録します。
- 認証がソースから出る原因を正確に記した簡潔なメモを 1 つ保持します。
2. リレー先を追跡する
- 認証がどこに到達するか、どのように転送されるか、およびどのプロトコルまたはサービスがそれを消費するかを記録します。
- キャプチャのみ、リプレイのみ、および実際のリレー受け入れを区別します。
- サービス名、ターゲットホスト、プロトコル、リレートランスクリプト、および受け入れ応答を結び付けて保持します。
3. 決定的なリレーチェーンに還元する
- 結果を最小のシーケンスに圧縮します: 強制トリガー -> リレーされた認証 -> 受け入れられたサービス -> 結果として生じる権限または成果物。
- 決定的な弱点が強制の発生源、リレー先、署名設定、または受け入れられた下流サービスにあるかどうかを明確に述べます。
- パスが最終的に証明書登録の問題または純粋な Kerberos 委任エッジになる場合は、より厳密な専門スキルに引き継ぎます。
このリファレンスを読む
- 強制チェックリスト、リレーチェックリスト、および証拠のパッケージ化については
references/relay-coercion-chain.mdをロードします。
保持すべきもの
- 強制トリガーの詳細、ソースホスト、強制された ID、ターゲットホスト、受け入れサービス、および結果として生じる効果
- リレートランスクリプト、エラーまたは受け入れ応答、および各ホップで使用された正確なプロトコル
- 最小のリプレイ可能な強制から受け入れまでのシーケンス
コメント
Markdown 対応