PW-017Attack pathCertificate Services (AD CS)

AD CS ESC4: write access to a template from outside Tier Zero

Accounts outside Tier Zero can edit a certificate template, and can turn it into one that issues certificates for any identity.

Category: Attack Path
Severity: At least High.
Typical owner: PKI / AD CS administrators (AD team for delegated permissions)
Data needed: AD CS objects and their permissions, from SharpHound, RustHound-CE or the built-in collector^*.

MITRE ATT&CKT1649

Most useful toDefensive engineers Identity and access engineers Offensive operators

On this page

In plain language

Certificate templates are objects in Active Directory with their own permissions. If someone outside Tier Zero can change a template that a trusted CA publishes, they don't need it to be vulnerable today: they can make it vulnerable, request a certificate as a Domain Admin, and change it back.

Templates live in AD's Configuration partition, which ordinary permission reviews tend to skip, so this access is easy to miss. SpecterOps calls it ESC4.

What Pathwarden flags

Accounts and groups outside Tier Zero can change the settings of a certificate template that a logon-trusted CA publishes, and can also enroll through that CA. The rights involved are Full Control, Write, Write DACL, Write Owner, ownership, or write access to the template's name and enrollment flags. Changing those settings turns an ordinary template into one that issues certificates for any identity.

How attackers use it

This is ESC4 from SpecterOps' "Certified Pre-Owned". With write access, an attacker (tools such as Certipy have a one-command "make it vulnerable" option) flips the template to "supply in the request", removes manager approval, enrolls as a Domain Admin, and can even put the template back afterwards. Certificate templates live in the Configuration partition, so the permissions are easy to overlook in normal AD delegation reviews.

Find it with Pathwarden

Data needed: AD CS objects and their permissions, from SharpHound, RustHound-CE or the built-in collector^*.

In the web UI or the HTML report, open the Findings tab and expand PW-017: 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-017
# the step-by-step guide on this page, offline
pathwarden guide PW-017
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-017

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

Review the template's full permission list and who owns it: dsacls "CN=<Template>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<tld>"
Find out why the account or group has write access: often a helpdesk or application team was given Full Control "to manage" a template, or a former PKI admin account still owns it.
Keep Enroll / Autoenroll entries that are legitimately needed; only write rights are the problem.
Record the current permissions (screenshot the Security tab, Advanced view) for rollback.

How to fix it

Option A: Remove the write permissions (recommended)

Open certtmpl.msc as an Enterprise Admin or the delegated PKI admin.
Right-click the template > Properties > Security tab > Advanced.
For each account or group named in the finding, remove the rights the finding lists: Full Control, Write, Modify permissions, Modify owner, and any entries granting "Write msPKI-Certificate-Name-Flag" or "Write msPKI-Enrollment-Flag". Keep Read and, if needed, Enroll.
On the same Advanced dialog, check the Owner. If it is not a PKI administrator group, change it to Enterprise Admins: the owner can always change the permissions.
If an entry is inherited, fix it on the Certificate Templates container (or the container above it it comes from) and check inheritance on the other templates.
Click OK.

Only the PKI administrators (by default Enterprise Admins and the forest root's Domain Admins) should be able to change certificate templates.

Option B: Unpublish the template if it is unused

certsrv.msc > Certificate Templates > right-click the template > Delete. The template stops being issued; its permissions still need fixing before it is ever re-published.

PowerShell / certutil

PowerShell

# Show the template's permissions (adjust the configuration DN to your forest)
dsacls "CN=<Template>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<tld>"

# Show the flags an attacker would change, to compare with your baseline
certutil -dstemplate <Template> msPKI-Certificate-Name-Flag
certutil -dstemplate <Template> msPKI-Enrollment-Flag

# Unpublish the template from the CA (Option B)
certutil -config "<CAHost>\<CAName>" -SetCATemplates -<Template>

Verify the fix

The Security tab shows write access only for Tier Zero (Enterprise Admins, Domain Admins of the root domain, SYSTEM) and the owner is a Tier Zero group.
Compare the template flags with your recorded baseline to make sure nobody already modified the template.
Collect again (or use Retest on the finding) and confirm the finding ID is gone.

Roll back

Re-add the removed permissions from your recorded list via the Security tab, or re-publish the template with certutil -config "<CAHost>\<CAName>" -SetCATemplates +<Template>.

References

SpecterOps, Certified Pre-Owned (ESC4)specterops.io
Microsoft, Certificate template conceptslearn.microsoft.com
SpecterOps: Certified Pre-Owned (blog post)specterops.io
SpecterOps BloodHound docs: ADCSESC4bloodhound.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.