AD CS ESC6: CA accepts requester-supplied SANs
A certificate authority lets every request name its own identity, which turns ordinary templates into ESC1.
- Category
- Attack Path
- Severity
- At least High.
- Typical owner
- PKI / AD CS administrators (AD team for domain controller settings)
- Data needed
- AD CS objects plus the CA's EditFlags registry value, read over Remote Registry from the CA's host: by SharpHound with access to the CA, by RustHound-CE with a password or NT hash, or by the built-in collector* in a Full collection. Without the flag, the report shows ESC6 as not checked. Whether the combination still works depends on the domain controllers' certificate mapping settings (see PW-020); without them the finding is reported as unverified.
On this page
In plain language
A setting on the certificate authority itself, EDITF_ATTRIBUTESUBJECTALTNAME2, lets any certificate request name an arbitrary identity, whatever the template says. Combined with a template that ordinary users can enroll in, it lets them obtain certificates for someone else.
Microsoft's 2022 certificate-binding changes blunted this for Kerberos logons where certificates carry the account's SID, so Pathwarden reports the combinations that still work: templates without that security extension, or domain controllers that still map certificates weakly. This is ESC6.
What Pathwarden flags
The CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 policy flag enabled. With it, any request may name an arbitrary identity in a subject alternative name attribute, regardless of how the template is configured. Accounts and groups outside Tier Zero can enroll in an authentication template on this CA, so they can request logon certificates for other accounts. ESC6a covers templates without the security extension (Kerberos logon); ESC6b covers Schannel logon where domain controllers map certificates by UPN.
How attackers use it
This is ESC6 from SpecterOps' "Certified Pre-Owned". The flag turns every authentication template on the CA into an ESC1-style template. Tools such as Certipy add a SAN attribute naming a Domain Admin to an ordinary request and log on with the result. Since the May 2022 certificate-binding updates, plain ESC6 against Kerberos needs a template without the SID security extension or weak mapping on DCs, which is the combination this finding reports.
Find it with Pathwarden
Data needed: AD CS objects plus the CA's EditFlags registry value, read over Remote Registry from the CA's host: by SharpHound with access to the CA, by RustHound-CE with a password or NT hash, or by the built-in collector* in a Full collection. Without the flag, the report shows ESC6 as not checked. Whether the combination still works depends on the domain controllers' certificate mapping settings (see PW-020); without them the finding is reported as unverified.
In the web UI or the HTML report, open the Findings tab and expand PW-018: 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-018
# the step-by-step guide on this page, offline
pathwarden guide PW-018
# after the fix: collect again, then check it is gone
pathwarden retest -i .\collect-after --rule PW-018Exit codes make retest easy to script: 0 Fixed, 1 Still open, 3 Can't tell. See findings lifecycle and retest.
Before you change anything
- Confirm the flag is set:
certutil -config "<CAHost>\<CAName>" -getreg policy\EditFlagsand look for EDITF_ATTRIBUTESUBJECTALTNAME2. - Find out why it was enabled. It is commonly turned on for web server or Exchange certificates with several DNS names, or by an old how-to. Those templates can instead use "Supply in the request" with manager approval, or build DNS names from AD.
- Restarting Certificate Services briefly interrupts issuance (seconds); schedule it.
How to fix it
Option A: Disable the flag on the CA (recommended)
- On the CA (or remotely with -config), remove the flag with certutil as shown below.
- Restart Certificate Services (certsrv.msc > right-click the CA > All Tasks > Stop Service, then Start Service, or Restart-Service certsvc).
- Repeat for every CA listed in findings for this rule.
Option B: Also close weak mapping on the domain controllers the finding names
- ESC6b: on each domain controller, check
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\CertificateMappingMethodsand remove the UPN bit (0x4). The value 0x18 (S4U2Self mappings only) is Microsoft's recommended setting after the 2022 updates. - A DC with no value set and a build older than the May 2022 update (KB5014754) uses the old default 0x1F, which includes UPN mapping. The finding names such DCs and their build: install the current Windows updates. Only the updates close it on a DC older than May 2022: 0x18 maps through the KDC, which checks no mapping before that update.
- ESC6a on a DC the finding names by its build: install the current Windows updates. Before the May 2022 update the KDC checks no certificate mapping, whatever StrongCertificateBindingEnforcement says.
- Test client-certificate (TLS/LDAPS) logons first; applications relying on UPN mapping will fail.
PowerShell / certutil
# Check the current policy flags
certutil -config "<CAHost>\<CAName>" -getreg policy\EditFlags
# Remove the flag (the minus sign clears only this bit)
certutil -config "<CAHost>\<CAName>" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
# Restart Certificate Services on the CA so the change takes effect
Restart-Service certsvc
# ESC6b only, on each domain controller: inspect the Schannel mapping methods
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel" -Name CertificateMappingMethodsVerify the fix
certutil -getreg policy\EditFlagsno longer lists EDITF_ATTRIBUTESUBJECTALTNAME2.- A test request carrying a SAN attribute (for example certreq with
-attrib "SAN:upn=someone@domain") is issued without that SAN. - Collect again (or use Retest on the finding) and confirm the finding ID is gone. The flag is read from the CA registry; make sure your collector reports it (SharpHound does), or run
scripts\Get-PathwardenTierZeroSettings.ps1on the CA and add its file.
Roll back
certutil -config "<CAHost>\<CAName>" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 followed by Restart-Service certsvc. For ESC6b, restore the previous CertificateMappingMethods value.
References
- SpecterOps, Certified Pre-Owned (ESC6)specterops.io
- Microsoft KB5014754, certificate-based authentication changes on domain controllerssupport.microsoft.com
- SpecterOps: Certified Pre-Owned (blog post)specterops.io
- SpecterOps BloodHound docs: ADCSESC6abloodhound.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.