competition-kerberos-delegation

Name: competition-kerberos-delegation
Author: zhaoxuya520

8.8kstars1.4kforks

How to install competition-kerberos-delegation?

zhaoxuya520/reverse-skill/competition-kerberos-delegation

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-kerberos-delegation

Installs into the current project.

Summary

Internal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for Kerberos delegation, SPN trust edges, S4U abuse, RBCD, constrained or unconstrained delegation, and service-ticket acceptance. Use when the user asks about constrained delegation, unconstrained deleg

Files · 1

View on GitHub

SKILL.md

1	# Competition Kerberos Delegation
2
3	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.
4
5	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.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Write the trust chain first: principal -> delegation edge -> ticket type -> target SPN -> accepting service -> resulting privilege.
12	2. Separate ticket possession from accepted privilege.
13	3. Keep SPNs, delegation mode, PAC/group data, encryption type, and service acceptance in one compact evidence block.
14	4. Reproduce one minimal delegation chain before broadening into variants.
15	5. Tie every privilege claim to a specific accepted ticket or service-side effect.
16
17	## Workflow
18
19	### 1. Identify The Delegation Edge
20
21	- Determine whether the path is constrained delegation, unconstrained delegation, resource-based constrained delegation, protocol transition, or another trust edge.
22	- Inspect SPNs, ACLs, service accounts, SIDHistory, certificate templates, and replication rights only when they affect the active path.
23
24	### 2. Trace Ticket Minting And Acceptance
25
26	- Record TGT/TGS type, S4U steps when relevant, delegation flags, PAC or group data, encryption type, cache location, and target SPN.
27	- Prove which service actually accepts the ticket and what capability appears after acceptance.
28
29	### 3. Report The Effective Edge
30
31	- Compress the chain into one replayable path, not a vague "domain compromise" statement.
32	- Separate candidate edges from the edge that really lands privilege.
33
34	## Read This Reference
35
36	- Load `references/kerberos-delegation.md` for the delegation checklist, ticket fields to preserve, and common proof mistakes.
37
38	## What To Preserve
39
40	- SPN, ticket type, delegation mode, PAC/group data, encryption type, cache location, accepting service
41	- Service-side logs, event IDs, logon session changes, or group changes proving effective privilege
42	- The exact trust edge that makes the ticket replayable

People who liked this also viewed

6 picks

Type

competition-kerberos-delegation

8.8kstars1.4kforks

View on GitHub

How to install competition-kerberos-delegation?

zhaoxuya520/reverse-skill/competition-kerberos-delegation

$npx -y skills add zhaoxuya520/reverse-skill --skill competition-kerberos-delegation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Competition Kerberos Delegation
2
3	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.
4
5	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.
6
7	Reply in Simplified Chinese unless the user explicitly requests English.
8
9	## Quick Start
10
11	1. Write the trust chain first: principal -> delegation edge -> ticket type -> target SPN -> accepting service -> resulting privilege.
12	2. Separate ticket possession from accepted privilege.
13	3. Keep SPNs, delegation mode, PAC/group data, encryption type, and service acceptance in one compact evidence block.
14	4. Reproduce one minimal delegation chain before broadening into variants.
15	5. Tie every privilege claim to a specific accepted ticket or service-side effect.
16
17	## Workflow
18
19	### 1. Identify The Delegation Edge
20
21	- Determine whether the path is constrained delegation, unconstrained delegation, resource-based constrained delegation, protocol transition, or another trust edge.
22	- Inspect SPNs, ACLs, service accounts, SIDHistory, certificate templates, and replication rights only when they affect the active path.
23
24	### 2. Trace Ticket Minting And Acceptance
25
26	- Record TGT/TGS type, S4U steps when relevant, delegation flags, PAC or group data, encryption type, cache location, and target SPN.
27	- Prove which service actually accepts the ticket and what capability appears after acceptance.
28
29	### 3. Report The Effective Edge
30
31	- Compress the chain into one replayable path, not a vague "domain compromise" statement.
32	- Separate candidate edges from the edge that really lands privilege.
33
34	## Read This Reference
35
36	- Load `references/kerberos-delegation.md` for the delegation checklist, ticket fields to preserve, and common proof mistakes.
37
38	## What To Preserve
39
40	- SPN, ticket type, delegation mode, PAC/group data, encryption type, cache location, accepting service
41	- Service-side logs, event IDs, logon session changes, or group changes proving effective privilege
42	- The exact trust edge that makes the ticket replayable

People who liked this also viewed

6 picks

Type