Back to Details

competition-kerberos-delegation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Competition Kerberos Delegation

竞赛场景Kerberos委托

Use this skill only as a downstream specialization after 
$ctf-sandbox-orchestrator
is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to 
$ctf-sandbox-orchestrator
first.
Use this skill when the hard part is not "is there Kerberos here," but which delegation edge exists, which ticket is being minted, and which service really accepts it.
Reply in Simplified Chinese unless the user explicitly requests English.
本技能仅作为下游专项能力使用，需在
$ctf-sandbox-orchestrator
已激活并完成沙箱假设、节点归属判定、证据优先级设定后再调用。如果还未完成上述步骤，请先返回
$ctf-sandbox-orchestrator
执行。
当问题的难点不是「这里是否存在Kerberos」，而是存在哪种委托边、正在生成哪种票据、以及哪个服务会实际接受该票据时，使用本技能。
除非用户明确要求英文回复，否则请使用简体中文回复。

Quick Start

快速开始

  1. Write the trust chain first: principal -> delegation edge -> ticket type -> target SPN -> accepting service -> resulting privilege.
  2. Separate ticket possession from accepted privilege.
  3. Keep SPNs, delegation mode, PAC/group data, encryption type, and service acceptance in one compact evidence block.
  4. Reproduce one minimal delegation chain before broadening into variants.
  5. Tie every privilege claim to a specific accepted ticket or service-side effect.
  1. 先梳理信任链：主体 -> 委托边 -> 票据类型 -> 目标SPN -> 接受服务 -> 最终权限。
  2. 将票据持有和可获得的权限分开处理。
  3. 将SPN、委托模式、PAC/组数据、加密类型、服务接受情况整合到一个紧凑的证据块中。
  4. 在扩展到变体之前，先复现一条最小委托链。
  5. 每一条权限声明都要对应到具体的已接受票据或服务端效果。

Workflow

工作流

1. Identify The Delegation Edge

1. 识别委托边

  • Determine whether the path is constrained delegation, unconstrained delegation, resource-based constrained delegation, protocol transition, or another trust edge.
  • Inspect SPNs, ACLs, service accounts, SIDHistory, certificate templates, and replication rights only when they affect the active path.
  • 判定路径属于约束委托、非约束委托、基于资源的约束委托（RBCD）、协议转换还是其他类型的信任边。
  • 仅在SPN、ACL、服务账户、SIDHistory、证书模板、复制权限会影响当前活动路径时，再对其进行检查。

2. Trace Ticket Minting And Acceptance

2. 追踪票据生成与接受

  • Record TGT/TGS type, S4U steps when relevant, delegation flags, PAC or group data, encryption type, cache location, and target SPN.
  • Prove which service actually accepts the ticket and what capability appears after acceptance.
  • 记录TGT/TGS类型、相关的S4U步骤、委托标识、PAC或组数据、加密类型、缓存位置和目标SPN。
  • 证明哪个服务会实际接受该票据，以及接受后会获得什么能力。

3. Report The Effective Edge

3. 上报有效边

  • Compress the chain into one replayable path, not a vague "domain compromise" statement.
  • Separate candidate edges from the edge that really lands privilege.
  • 将链压缩为一条可复现的路径，不要给出模糊的「域接管」类表述。
  • 区分候选边和实际能落地权限的边。

Read This Reference

参考资料说明

  • Load 
    references/kerberos-delegation.md
    for the delegation checklist, ticket fields to preserve, and common proof mistakes.
  • 加载
    references/kerberos-delegation.md
    查看委托检查清单、需要留存的票据字段以及常见的证明错误。

What To Preserve

需要留存的内容

  • SPN, ticket type, delegation mode, PAC/group data, encryption type, cache location, accepting service
  • Service-side logs, event IDs, logon session changes, or group changes proving effective privilege
  • The exact trust edge that makes the ticket replayable
  • SPN、票据类型、委托模式、PAC/组数据、加密类型、缓存位置、接受服务
  • 证明有效权限的服务端日志、事件ID、登录会话变更或组变更记录
  • 让票据可重放的具体信任边