AD CS ESC13: issuance policy linked to a group
A certificate template's issuance policy is linked to a group, so anyone who enrolls gets that group's access without being a member.
- Category
- Attack Path
- Severity
- From exposure; at least High for a Tier Zero group.
- Typical owner
- PKI / AD CS administrators (AD team for the linked group)
- Data needed
- AD CS objects including issuance policies and their group links (
msDS-OIDToGroupLink), from SharpHound, RustHound-CE or the built-in collector*.
On this page
In plain language
AD CS can link a certificate's issuance policy to an Active Directory group, so that signing in with such a certificate grants that group's rights. It is meant for things like "smart-card logons get extra access".
If the linked group is privileged and the template is open to ordinary accounts, anyone can enroll and sign in with the group's rights. Group membership reviews never show it, because nobody is a member. SpecterOps described this as ESC13 in 2024.
What Pathwarden flags
A certificate template carries an issuance policy, and that policy is linked to an AD group through the msDS-OIDToGroupLink attribute. When someone logs on with a certificate from this template, the domain controller adds the linked group's SID to their logon token, so they get that group's access without being a member. Accounts and groups outside Tier Zero can enroll in the template.
How attackers use it
This is ESC13 (a later addition to SpecterOps' "Certified Pre-Owned" series). The feature, "authentication mechanism assurance", is meant for things like "smart card logons get extra access". If the linked group is privileged and the template is broadly enrollable, an attacker enrolls (tools such as Certipy support this) and logs on with the certificate to gain the group's rights. Group membership reviews never show it, because nobody is actually a member.
Find it with Pathwarden
Data needed: AD CS objects including issuance policies and their group links (msDS-OIDToGroupLink), from SharpHound, RustHound-CE or the built-in collector*.
In the web UI or the HTML report, open the Findings tab and expand PW-021: 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:
# every finding of this rule, with its path and fix
pathwarden findings -i .\collect --rule PW-021
# the step-by-step guide on this page, offline
pathwarden guide PW-021
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-021Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- List linked issuance policies and their groups with the PowerShell below. Note which templates use each policy (template Properties > Extensions tab > Issuance Policies).
- Confirm whether authentication mechanism assurance is in use on purpose, and which systems grant access to the linked group (file shares, applications, admin rights). Removing the link removes that access for certificate logons.
- The linked group is, by design, a universal group with no members; check that this is still true.
How to fix it
Option A: Restrict enrollment on the template (recommended when the link is intentional)
- certtmpl.msc > template > Properties > Security tab.
- Remove Enroll / Autoenroll from broad groups; grant it only to the accounts that should have the linked group's access.
- Consider also requiring CA certificate manager approval (Issuance Requirements tab) for templates linked to privileged groups.
Option B: Remove the group link (when it is not needed)
- Open ADSI Edit, connect to the Configuration naming context.
- Browse to CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,<forest root DN>.
- Open the issuance policy object (its displayName matches the policy shown on the template's Extensions tab), select msDS-OIDToGroupLink and clear it.
Option C: Remove the policy from the template
certtmpl.msc > template > Properties > Extensions tab > Issuance Policies > Edit, remove the linked policy. Certificates already issued keep the policy until they expire or are revoked.
Then: review certificates already issued
Certificates issued before the fix still carry the policy and still add the group at logon. Revoke those held by accounts that shouldn't have the group's access (certsrv.msc > Issued Certificates, filtered by the template).
PowerShell / certutil
# Find issuance policies that are linked to a group (requires the ActiveDirectory module)
$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase "CN=OID,CN=Public Key Services,CN=Services,$config" `
-LDAPFilter "(msDS-OIDToGroupLink=*)" `
-Properties displayName, msPKI-Cert-Template-OID, msDS-OIDToGroupLink |
Select-Object displayName, msPKI-Cert-Template-OID, msDS-OIDToGroupLink
# Option B: remove the link from one policy object
Set-ADObject -Identity "<PolicyObjectDN>" -Clear msDS-OIDToGroupLink
# Option C, as a stopgap: stop the CA issuing the template
certutil -config "<CAHost>\<CAName>" -SetCATemplates -<Template>Verify the fix
- The Get-ADObject query no longer returns the policy (Option B), or the template's Security tab shows only the intended enrollees (Option A).
- Revoke any certificates already issued from the template to unintended accounts (certsrv.msc > Issued Certificates > All Tasks > Revoke Certificate).
- Collect again (or use Retest on the finding) and confirm the finding ID is gone. ESC13 needs the template's certificatepolicy property, which SharpHound collects and some other collectors do not.
Roll back
Re-set msDS-OIDToGroupLink to the group's distinguished name (Set-ADObject -Identity "<PolicyObjectDN>" -Replace @{'msDS-OIDToGroupLink' = '<GroupDN>'}), restore the template's Security entries or issuance policy, or re-publish the template with -SetCATemplates +<Template>.
References
- SpecterOps, Certified Pre-Ownedspecterops.io
- Microsoft, Certificate template conceptslearn.microsoft.com
- SpecterOps: ADCS ESC13 abuse techniquespecterops.io
- SpecterOps BloodHound docs: ADCSESC13bloodhound.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.