PW-015Attack pathCertificate Services (AD CS)

AD CS ESC1: template lets requesters choose any identity

A certificate template lets whoever enrolls choose any identity, so they can get a logon certificate for a Domain Admin.

Category: Attack Path
Severity: At least High.
Typical owner: PKI / AD CS administrators
Data needed: AD CS objects (templates, Enterprise CAs and the NTAuth store), which SharpHound, RustHound-CE and the built-in collector^* all read. A CA only counts when domain controllers trust it for logon.

MITRE ATT&CKT1649

Most useful toDefensive engineers Identity and access engineers Offensive operators

On this page

In plain language

Active Directory Certificate Services (AD CS) issues certificates that can be used to sign in, like a password. A template defines who may request a certificate and what goes in it.

When a template lets the requester type in whose certificate it is, allows client authentication and needs no approval, anyone allowed to enroll can request a certificate that says "I am the Domain Admin", and sign in with it. No password is needed, nothing in AD changes, and the certificate keeps working after the admin's password is reset. SpecterOps named this ESC1 in their 2021 research Certified Pre-Owned.

What Pathwarden flags

A certificate template published by a CA that domain controllers trust for logon lets the requester type in any name they like as the certificate subject. The template also allows client authentication, needs no manager approval and no extra signatures. Anyone allowed to enroll can therefore obtain a logon certificate for any account, including Domain Admins.

How attackers use it

This is ESC1 from SpecterOps' "Certified Pre-Owned". With one request (tools such as Certipy or Certify do it in a single command) an attacker who controls any enrolling account asks for a certificate naming a Domain Admin in the subject alternative name, then uses it with PKINIT to get that admin's Kerberos ticket and NT hash. No password is needed, nothing is changed in AD, and the certificate stays valid until it expires (often a year), even if the admin's password is reset.

Find it with Pathwarden

Data needed: AD CS objects (templates, Enterprise CAs and the NTAuth store), which SharpHound, RustHound-CE and the built-in collector^* all read. A CA only counts when domain controllers trust it for logon.

In the web UI or the HTML report, open the Findings tab and expand PW-015: each finding shows who can use it (its exposure), the attack path drawn out, the affected objects, and the fix. The remediation path tells you whether a single plan step closes it. On the command line:

Shell

# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-015
# the step-by-step guide on this page, offline
pathwarden guide PW-015
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-015

Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.

Before you change anything

Find who actually uses the template. On the CA, list recent certificates issued from it (the CertificateTemplate column holds the template OID for version 2+ templates and the name for version 1): certutil -config "<CAHost>\<CAName>" -view -restrict "CertificateTemplate=<TemplateOID>" -out "RequestID,RequesterName,CommonName,NotBefore" You can also filter Issued Certificates in certsrv.msc by Certificate Template.
Typical legitimate users are web or application servers that need custom subject names (often managed by a small team). If the requesters are computers, the subject can usually be built from AD instead.
Check whether any autoenrollment GPO targets this template (Computer/User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment).
Note the template's current settings (screenshot the Subject Name, Issuance Requirements and Security tabs) so you can roll back.

How to fix it

Option A: Build the subject from Active Directory (recommended when requesters are computers or users enrolling for themselves)

Open certtmpl.msc on a computer with the AD CS management tools, signed in as an Enterprise Admin or the delegated PKI admin.
Right-click the template > Properties > Subject Name tab.
Select Build from this Active Directory information and choose the appropriate format (for example Common name, and DNS name for computers / User principal name for users).
Click OK. AD replication carries the change to the CA; new requests use it immediately after replication.

Option B: Require approval (when requesters genuinely must supply the subject)

certtmpl.msc > template > Properties > Issuance Requirements tab.
Tick CA certificate manager approval. Requests now wait in Pending Requests in certsrv.msc until a certificate manager reviews the requested names.
Make sure certificate managers check the subject alternative name on every request before issuing.

Option C: Restrict or unpublish

Restrict enrollment: Properties > Security tab, remove Enroll / Autoenroll (and Full Control, which includes Enroll) from broad groups (Domain Users, Authenticated Users, Domain Computers) and grant it only to a dedicated group of the accounts that need it.
If nobody uses the template: certsrv.msc > Certificate Templates > right-click the template > Delete. This only stops the CA issuing it; the template object stays in AD and existing certificates keep working.

Then: review certificates already issued

Certificates the template issued before the fix stay valid. In certsrv.msc > Issued Certificates, look at those from this template for a subject or subject alternative name that doesn't match the requester, and revoke them (certutil -config "<CAHost>\<CAName>" -revoke <SerialNumber> 1, reason 1 = key compromise).

PowerShell / certutil

PowerShell

# List the templates the CA currently issues
certutil -config "<CAHost>\<CAName>" -CATemplates

# Show the template's name flags (ENROLLEE_SUPPLIES_SUBJECT = 0x1)
certutil -dstemplate <Template> msPKI-Certificate-Name-Flag

# Stop the CA issuing the template (Option C); run on or against the CA
certutil -config "<CAHost>\<CAName>" -SetCATemplates -<Template>

Verify the fix

Re-open the template in certtmpl.msc and confirm the Subject Name / Issuance Requirements / Security settings.
Optionally try a test request with a different name in the SAN from an enrolling account: it should be ignored (Option A) or land in Pending Requests (Option B).
Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

Re-apply the settings you recorded: re-select "Supply in the request" on the Subject Name tab, untick manager approval, restore the Security entries, or re-publish with certutil -config "<CAHost>\<CAName>" -SetCATemplates +<Template> (or certsrv.msc > Certificate Templates > New > Certificate Template to Issue).

References

SpecterOps, Certified Pre-Owned (ESC1)specterops.io
Microsoft, Certificate template conceptslearn.microsoft.com
SpecterOps: Certified Pre-Owned (blog post)specterops.io
SpecterOps BloodHound docs: ADCSESC1bloodhound.specterops.io
MITRE ATT&CK T1649: Steal or Forge Authentication Certificatesattack.mitre.org

Very new and undergoing testing. These features haven't received a lot of testing yet. Try them out and let us know what's working.