
Competition Ad Certificate Abuse
Internal downstream skill for ctf-sandbox-orchestrator.
Install
npx skills add zhaoxuya520/reverse-skill --skill competition-ad-certificate-abuse -g -a claude-code -y- Repository
- zhaoxuya520/reverse-skill43.9k
- Category
- AI and agents
- Updated
- 1mo ago
- License
- MIT
- Context cost
- Lightabout 673 tokens
- Runs scripts
- No, instructions only
What it does
Internal 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, enrollment agents, EKUs, SAN or subject controls, smartcard or PKINIT logon, CA policy, or how an issued cert turns into accepted privilege. Use only after `$ctf-sandbox-orchestrator` has already established sandbox assumptions and routed here.
Competition AD Certificate Abuse
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 decisive identity edge is certificate-based and the hard part is proving how a template or CA policy turns into accepted privilege.
Reply in Simplified Chinese unless the user explicitly requests English.
Quick Start
- Identify the CA, template, enrolling principal, and accepting service before diving into every certificate detail.
- Separate template enrollability from cert-based authentication or privilege acceptance.
- Record EKUs, subject or SAN controls, issuance requirements, enrollment rights, and mapping behavior in compact blocks.
- Tie the issued cert to one accepted path: PKINIT, Schannel, LDAPS, WinRM, or another mapped service.
- Reproduce the smallest certificate issuance-to-acceptance chain that yields the decisive privilege.
Workflow
1. Map CA And Template Trust
- Record CA configuration, template name, enrollment permissions, manager approval, authorized signatures, EKUs, subject requirements, and SAN behavior.
- Note whether the path depends on alternate subject names,
UPN, DNS names, enrollment agent behavior, or template supersedence. - Keep principal, template, and issuance policy tied together.
2. Prove Cert-To-Privilege Acceptance
- Show how the issued certificate is mapped or accepted: PKINIT, smartcard logon, Schannel auth, service mapping, or explicit certificate mapping.
- Record serial, subject, SAN, EKU, validity, and the exact service or domain edge that accepts it.
- Distinguish certificate issuance from the separate step where privilege is actually granted.

