AD-ADCS-006: ESC9: authentication template without the security extension¶

medium   Certificate services   MITRE ATT&CK T1649   Reads: LDAP

A published authentication template that broad groups can enroll in sets CT_FLAG_NO_SECURITY_EXTENSION, so its certificates carry no SID for strong mapping.

Also known as: esc9

Why it matters¶

Since the May 2022 updates (KB5014754), a CA writes the requester's SID into every certificate (szOID_NTDS_CA_SECURITY_EXTENSION), and domain controllers use it to tie the certificate to exactly one account. The template flag CT_FLAG_NO_SECURITY_EXTENSION tells the CA to leave that SID out, so the DC falls back to mapping by the UPN in the certificate.

The ESC9 attack needs write access to one other account, for example GenericWrite over jdoe:

1. Set jdoe's userPrincipalName to administrator (no domain suffix).
2. Enroll as jdoe in this template; the certificate's UPN is now administrator, and it carries no SID.
3. Set jdoe's UPN back, so the name no longer matches jdoe.
4. Authenticate with the certificate: a DC in compatibility mode maps it to administrator.

Domain controllers in full enforcement (StrongCertificateBindingEnforcement = 2, the default since the February 2025 updates) reject a certificate without the SID extension unless the account has a strong explicit mapping, which blocks this path for Kerberos.

How ad-doctor detects it¶

ad-doctor reads every certificate template and the enterprise CAs over LDAP and reports a template when all of these hold:

Each object names the template and the broad groups that can enroll, for example LabESC9 (enroll: Domain Users). The same effect configured CA-wide is reported by AD-ADCS-015.

Severity¶

Always medium: the template is only exploitable together with write access to another account's userPrincipalName, and only against domain controllers that are not in full enforcement mode for strong certificate mapping.

False positives and limits¶

• Full enforcement on every DC. ad-doctor does not read the DCs' StrongCertificateBindingEnforcement value, so it cannot tell whether all of them are in full enforcement mode. The finding still matters for Schannel logons that map certificates by UPN, and the flag has no legitimate use on an authentication template.
• Nobody can write other accounts' UPNs. The attack needs that write access; who holds it over privileged accounts is reported by AD-ACL-004 and AD-PATH-001.

Fix¶

1. Clear the flag on the template (CT_FLAG_NO_SECURITY_EXTENSION, 0x80000):

   $cfg = (Get-ADRootDSE).configurationNamingContext
   $dn  = "CN=LabESC9,CN=Certificate Templates,CN=Public Key Services,CN=Services,$cfg"
   $t   = Get-ADObject $dn -Properties 'msPKI-Enrollment-Flag'
   Set-ADObject $dn -Replace @{'msPKI-Enrollment-Flag' = ($t.'msPKI-Enrollment-Flag' -band -bnot 0x80000)} -WhatIf
   

2. Confirm full enforcement on every DC (read-only; the value should be 2 or absent on a fully updated DC):

   Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc' -Name StrongCertificateBindingEnforcement -ErrorAction SilentlyContinue
   

3. Re-enroll holders of certificates from this template so their certificates carry the SID, and remove write access to UPNs that non-admins should not have.

Verify¶

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ADCS-006

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ADCS-006"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

Related checks¶

• AD-ADCS-015
• AD-ADCS-009
• AD-ACL-004
• AD-PATH-001

References¶

Microsoft and vendors

• KB5014754: Certificate-based authentication changes on Windows domain controllers

Specifications

• [MS-CRTD] msPKI-Enrollment-Flag attribute (CT_FLAG_NO_SECURITY_EXTENSION)

Tools

• Certipy wiki: Privilege escalation (ESC9)

MITRE ATT&CK

• T1649

Available since 0.1.0.