$npx -y skills add zhaoxuya520/reverse-skill --skill competition-ad-certificate-abuseInternal downstream skill for ctf-sandbox-orchestrator. CTF-sandbox workflow for AD CS, certificate templates, enrollment rights, EKUs, SAN controls, PKINIT, certificate mapping, and cert-based privilege paths. Use when the user asks about ESC-style abuse, certificate templates,
| 1 | # Competition AD Certificate Abuse |
| 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 decisive identity edge is certificate-based and the hard part is proving how a template or CA policy turns into accepted privilege. |
| 6 | |
| 7 | Reply in Simplified Chinese unless the user explicitly requests English. |
| 8 | |
| 9 | ## Quick Start |
| 10 | |
| 11 | 1. Identify the CA, template, enrolling principal, and accepting service before diving into every certificate detail. |
| 12 | 2. Separate template enrollability from cert-based authentication or privilege acceptance. |
| 13 | 3. Record EKUs, subject or SAN controls, issuance requirements, enrollment rights, and mapping behavior in compact blocks. |
| 14 | 4. Tie the issued cert to one accepted path: PKINIT, Schannel, LDAPS, WinRM, or another mapped service. |
| 15 | 5. Reproduce the smallest certificate issuance-to-acceptance chain that yields the decisive privilege. |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | ### 1. Map CA And Template Trust |
| 20 | |
| 21 | - Record CA configuration, template name, enrollment permissions, manager approval, authorized signatures, EKUs, subject requirements, and SAN behavior. |
| 22 | - Note whether the path depends on alternate subject names, `UPN`, DNS names, enrollment agent behavior, or template supersedence. |
| 23 | - Keep principal, template, and issuance policy tied together. |
| 24 | |
| 25 | ### 2. Prove Cert-To-Privilege Acceptance |
| 26 | |
| 27 | - Show how the issued certificate is mapped or accepted: PKINIT, smartcard logon, Schannel auth, service mapping, or explicit certificate mapping. |
| 28 | - Record serial, subject, SAN, EKU, validity, and the exact service or domain edge that accepts it. |
| 29 | - Distinguish certificate issuance from the separate step where privilege is actually granted. |
| 30 | |
| 31 | ### 3. Reduce To The Decisive Abuse Chain |
| 32 | |
| 33 | - Compress the path to the smallest sequence: enrollment right or misconfig -> issued cert -> accepted mapping -> resulting privilege. |
| 34 | - State clearly whether the weakness lives in template config, CA policy, mapping logic, relay path, or enrollment rights. |
| 35 | - If the task is really about delegation or ticket transformation after PKINIT, switch back to the tighter Kerberos skill. |
| 36 | |
| 37 | ## Read This Reference |
| 38 | |
| 39 | - Load `references/ad-certificate-abuse.md` for the AD CS checklist, template checklist, and evidence packaging. |
| 40 | |
| 41 | ## What To Preserve |
| 42 | |
| 43 | - CA names, template names, rights, EKUs, issuance flags, SAN controls, and mapping details |
| 44 | - Issued certificate fields, serials, subjects, SANs, and the accepting service or logon path |
| 45 | - The smallest reproducible enrollment-to-privilege chain |