mcpField
C
competition-kerberos-delegation

competition-kerberos-delegation

github.com/zhaoxuya520セキュリティ43.7k93 回インストール5 週間前に更新
リポジトリ

competition-kerberos-delegation について

Kerberos 委任の信頼関係からチケット発行、サービスによる受け入れ、実効権限までを追跡する CTF 向けスキルです。`$ctf-sandbox-orchestrator` がサンドボックスと証拠の優先順位を確立した後に使用します。

主な機能

  1. 01委任経路の分類
  2. 02チケット発行と受け入れの追跡
  3. 03SPN、チケット項目、PAC データの記録
  4. 04候補経路と実証済み権限の区別

活用シーン

  1. 01サービスが受け入れる委任チケットの検証
  2. 02再現可能な Kerberos 権限チェーンの記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/zhaoxuya520/reverse-skill --skill competition-kerberos-delegation

インストール後、Claude Code で/competition-kerberos-delegationを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yamlreferences/kerberos-delegation.md

詳細

競技 Kerberos 委任

このスキルは、$ctf-sandbox-orchestrator がすでに有効であり、サンドボックスの前提、ノードの所有権、および証拠の優先順位を確立した後の下流の専門分野としてのみ使用してください。まだそれが行われていない場合は、まず $ctf-sandbox-orchestrator に戻ってください。

このスキルは、難しい部分が「ここに Kerberos があるかどうか」ではなく、どの委任エッジが存在するか、どのチケットが発行されているか、そしてどのサービスが実際にそれを受け入れるかである場合に使用してください。

ユーザーが明示的に英語を要求しない限り、簡体字中国語で回答してください。

クイックスタート

  1. まず信頼チェーンを書きます：プリンシパル -> 委任エッジ -> チケットタイプ -> ターゲット SPN -> 受け入れサービス -> 結果として得られる権限。
  2. チケットの所持と受け入れられた権限を分離します。
  3. SPN、委任モード、PAC/グループデータ、暗号化タイプ、およびサービスの受け入れを 1 つの簡潔な証拠ブロックにまとめます。
  4. バリエーションに広げる前に、最小限の委任チェーンを 1 つ再現します。
  5. すべての権限の主張を、特定の受け入れられたチケットまたはサービス側の効果に結び付けます。

ワークフロー

1. 委任エッジを特定する
  • パスが制約付き委任、制約なし委任、リソースベースの制約付き委任、プロトコル遷移、または別の信頼エッジであるかを判断します。
  • SPN、ACL、サービスアカウント、SIDHistory、証明書テンプレート、およびレプリケーション権限は、アクティブなパスに影響を与える場合にのみ検査します。
2. チケットの発行と受け入れを追跡する
  • TGT/TGS タイプ、該当する場合は S4U ステップ、委任フラグ、PAC またはグループデータ、暗号化タイプ、キャッシュの場所、およびターゲット SPN を記録します。
  • どのサービスが実際にチケットを受け入れ、受け入れ後にどのような機能が現れるかを証明します。
3. 有効なエッジを報告する
  • チェーンを、漠然とした「ドメイン侵害」という記述ではなく、1 つの再現可能なパスに圧縮します。
  • 候補エッジと、実際に権限をもたらすエッジを分離します。

このリファレンスを読む

  • 委任チェックリスト、保持すべきチケットフィールド、およびよくある証明の誤りについては、references/kerberos-delegation.md を読み込んでください。

保持すべきもの

  • SPN、チケットタイプ、委任モード、PAC/グループデータ、暗号化タイプ、キャッシュの場所、受け入れサービス
  • 有効な権限を証明するサービス側のログ、イベント ID、ログオンセッションの変更、またはグループの変更
  • チケットを再現可能にする正確な信頼エッジ

コメント

Markdown 対応