Nyx Learning AD CS abuse · Part 3 of 3
AD CS abuse · Part 3 of 3

AD CS abuse, Part 3: defeating the mapping, and remediation

ESC9, ESC10, ESC13–ESC17, and the full AD CS hardening program

Generated Thursday, October 8, 2026 · Depth: deep · ESC9 (CT_FLAG_NO_SECURITY_EXTENSION), ESC10 (StrongCertificateBindingEnforcement / CertificateMappingMethods), ESC13 (msDS-OIDToGroupLink), ESC14 (altSecurityIdentities), ESC15/EKUwu (CVE-2024-49019, patched Nov 12 2024), ESC16 (DisableExtensionList), and ESC17 (server-auth / WSUS, Coontz, Neff and Knüfer) checked against the ly4k/Certipy wiki and SpecterOps posts. Enforcement modes, the Feb 11 2025 Full-Enforcement default and the Sep 9 2025 end of the registry override, strong-vs-weak mapping types, and DC events 39/41 follow Microsoft's KB5014754 (see Part 1). Whether each technique works depends on the DC's actual enforcement mode; sources differ on some details and ESC numbering is informal. ESC17's deep interception mechanics are out of scope and left to the primary research.

01

Start here

Roadmap for this series
  1. Part 1: Templates and the escalation primitives. Public Key Infrastructure (PKI) foundations, how certificates authenticate, certificate-to-account mapping and the strong-mapping hardening, and ESC1–ESC4.
  2. Part 2: The Certificate Authority (CA), access control, and relay. ESC5–ESC8 and ESC11, certificate theft, and golden-certificate persistence.
  3. Part 3 (this page): Defeating the mapping, and remediation. ESC9 and ESC10 (stripping or dodging the Security Identifier (SID)), ESC16 (the CA-wide version), ESC13 (group-linked issuance policy), ESC14 (weak explicit mappings), ESC15/EKUwu (Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019), ESC17 (server-auth abuse), and the full hardening program that closes the series.
Highlight key
the term being defined
Key term: bold with a highlighter swash. A concept's defining phrase.
how something works
Mechanism: wavy underline. How a piece works or relates to another.
Risk: what makes an attack possible
Risk: warm highlight with a dashed edge. Attack prerequisites and dangerous conditions.
Fix: the mitigation to apply
Fix: solid green underline. A mitigation or configuration change.
Verify: how to confirm it worked
Verify: green underline with a check. How to prove a fix works.
only if, by default
Qualifier: bold italic. A word that changes the claim.
4769
Technical literal: monospace chip. Commands, settings, event IDs, exactly as typed.

Plain English first

Parts 1 and 2 were about getting a certificate. This part is about the step right after: convincing the domain controller that your certificate belongs to a privileged account. In 2022 Microsoft added a tamper-proof identity check to that step, which blunted the classic "name yourself an admin" trick. Every attack here is a way to remove, weaken, or sidestep that check.

The crucial, and reassuring, theme is that most of these only work where the strong check isn't fully turned on. Microsoft made full enforcement the default in February 2025. So Part 3 is really two stories: the techniques themselves, and the remediation program, centred on Fix: making that enforcement universal, that closes them and ties the whole series together.

The analogy: forging the employee number

Back to the badge office. In Part 1 the door learned to check a tamper-proof employee number, not the typed name, so forging the name stopped working. These attacks go after the number itself: Risk: print badges with no number (ESC9, one template; ESC16, the whole office), Risk: bribe the door to accept names again (ESC10), or Risk: register a forged number against someone's file (ESC14). Two don't touch the number at all: one Risk: hides a VIP group inside the badge (ESC13), another Risk: tricks an old form into printing a badge type it shouldn't (ESC15). The fix is to insist the door always demand a real number, everywhere, and clean up the forms, which is the remediation program.

Why it matters now

Attacker

Wherever enforcement is still in Compatibility mode, which is common after cautious rollouts, Risk: the SID-strip attacks bring classic ESC1 back to life. And several techniques here, group-linked policies and Enhanced Key Usage (EKU) injection, Risk: ignore the mapping check entirely, so even a fully enforced domain isn't automatically safe.

Defender

The keystone is concrete and already the default: Fix: Full Enforcement on every domain controller, with strong-only mappings. Around it, remove the no-SID flags, ensure the CA adds the SID extension, audit group links and explicit mappings, and patch CVE-2024-49019. This part is where the series' Fix: remediation program comes together.

If you remember only 5 things

  1. Enforcement mode decides everything here. ESC9, ESC16 and ESC10 case 1 work in Compatibility mode and are denied under Full Enforcement (Domain Controller (DC) event 39). Verify each DC's actual setting, not the default.
  2. Full Enforcement is the keystone fix. Fix: StrongCertificateBindingEnforcement = 2, the default since Feb 11, 2025, neutralises the whole SID-strip class and caps template-misconfig damage.
  3. Some attacks ignore mapping entirely. Risk: ESC13 (group-linked issuance policy) and ESC15 (EKU injection, CVE-2024-49019) aren't touched by enforcement, so they need their own fixes.
  4. The User Principal Name (UPN) swap is the shared primitive. Write an account's UPN to a victim's, enroll, revert; Verify: a privileged UPN changed and back is a strong signal.
  5. Closing Active Directory Certificate Services (AD CS) is a program, not a patch. Templates (Part 1) + CA and key (Part 2) + Fix: strong mapping and clean configs (Part 3), with the CA as Tier 0 and continuous checking.
02

Core concepts

Twelve ideas, from "the mapping is the battleground" to the remediation program that closes the series. Open "Go deeper" for expert detail.

01The mapping is the battlegroundPart 3 is about attacks that target how a certificate maps to an account, not how it's issued.
In plain terms

Parts 1 and 2 got you a certificate. This part is about the step after: convincing the domain controller that your certificate belongs to a privileged account. Since 2022 that step got a strong, unforgeable check, so these techniques are all ways to get around, remove, or weaken that check.

Example

You can request a certificate naming an admin, but the Domain Controller (DC) maps it back to you by Security Identifier (SID). These attacks strip or dodge that SID so the name wins again.

TechnicalGo deeper

Recall Part 1: the DC maps by the SID extension first, then strong explicit mappings, then falls back to the name. Everything here attacks one of those: ESC9 and ESC16 remove the SID extension (template- and CA-wide), ESC10 weakens the DC's mapping rules, ESC14 plants a weak explicit mapping, while ESC13 and ESC15 sidestep mapping entirely (group tokens and Enhanced Key Usage (EKU) injection). Which of them actually work depends heavily on the DC's enforcement mode, the theme that runs through this part.

02Enforcement modes, revisitedStrongCertificateBindingEnforcement has three modes, and which one the Domain Controller (DC) is in decides whether most of these attacks work.
In plain terms

The domain controller can be in Disabled (0), Compatibility (1), or Full Enforcement (2). In Compatibility it still falls back to name-based mapping when there's no Security Identifier (SID). In Full Enforcement, a certificate with no strong mapping and no SID is simply denied.

Example

An ESC9 certificate (no SID extension) naming an admin authenticates fine in Compatibility mode, but is denied in Full Enforcement with DC event 39.

TechnicalGo deeper

Full Enforcement has been the default since February 11, 2025, and the registry override stopped being honored on September 9, 2025. That is the single most important fact for this part: Fix: under true Full Enforcement, the SID-stripping attacks (ESC9, ESC16) and the implicit-UPN forms of ESC10 are denied. They remain dangerous because many environments still run Compatibility mode to avoid breaking legacy certificates, because the Schannel path uses a different setting, and because Risk: ESC13, ESC14 and ESC15 don't depend on this at all. So the first question for any of these findings is: what mode are the DCs actually in?

03The UPN-swap primitiveSeveral attacks share one trick: temporarily change an account's User Principal Name (UPN) to a victim's, enroll, then change it back.
In plain terms

Implicit mapping matches the name in the certificate to an account's UPN. If you can edit an account you control and set its UPN to "administrator," enroll a certificate, then set it back, the certificate now names the administrator, and the Domain Controller (DC) may map it there.

Example

With write access over a service account, set its UPN to a domain admin's, enroll in an ESC9 template, revert the UPN, and authenticate as the admin.

TechnicalGo deeper

This needs Risk: write access to an account's userPrincipalName (GenericWrite or similar) and a certificate that lacks a conflicting Security Identifier (SID). For computer targets, the equivalent is the machine's dNSHostName/sAMAccountName. It only lands if the DC falls back to name mapping, i.e. no SID extension and not Full Enforcement, which is why ESC9/ESC10/ESC16 pair this primitive with a SID-strip or a weak-mapping setting. The swap is also detectable: Verify: a UPN changed to a privileged name and back is a strong signal.

04ESC9: No Security Extension (template)ESC9 is a template flagged to omit the Security Identifier (SID) security extension from the certificates it issues.
In plain terms

A template can be set so its certificates leave out the tamper-proof SID. Combined with the UPN-swap trick, that lets a certificate be mapped by name again, defeating the strong check, on Domain Controllers (DCs) that aren't in Full Enforcement.

Example

A template has the no-security-extension flag. An attacker with write over a service account swaps its User Principal Name (UPN) to an admin, enrolls, reverts, and logs on as the admin in a Compatibility-mode domain.

TechnicalGo deeper

The flag is CT_FLAG_NO_SECURITY_EXTENSION in the template's msPKI-Enrollment-Flag (value 0x80000). Discovered by Oliver Lyak. Prerequisites: Risk: an enrollable no-security-extension template, write over a victim account's UPN, and a client-auth Enhanced Key Usage (EKU). Crucially, under Full Enforcement a no-SID certificate with only name mapping is denied (event 39), so ESC9's reach is really "anywhere still in Compatibility mode." Fix: Fix: remove the flag from all templates and move to Full Enforcement.

05ESC16: the Certificate Authority (CA) omits the Security Identifier (SID) extension for everyoneESC16 is a CA configured to leave the SID extension off every certificate it issues.
In plain terms

ESC9 was one template; ESC16 is the whole CA. If the CA is set to never include the tamper-proof SID, then every certificate it issues is mappable by name, which turns the CA into a domain-wide impersonation engine where enforcement allows it.

Example

The CA's policy lists the SID-extension Object Identifier (OID) as disabled, so no certificate carries a SID. Any user-supplied Subject Alternative Name (SAN) (ESC6) then maps by name.

TechnicalGo deeper

The CA's DisableExtensionList includes the SID-extension OID (1.3.6.1.4.1.311.25.2). Reported by Oliver Lyak (May 2025). Risk: ESC16 chains powerfully with ESC6: a CA that both accepts a user-supplied SAN and omits the SID extension lets any requester impersonate anyone, across every template. Like ESC9, it depends on Domain Controllers (DCs) not being in Full Enforcement for the implicit-name path. Fix: Fix: ensure the SID extension is not disabled on the CA, and enforce strong binding.

06ESC10: weak mapping settings on the Domain Controller (DC)ESC10 is the domain controller's own mapping settings set too weakly, so names are trusted.
In plain terms

Two DC registry settings can re-open name-based mapping: one turns off strong binding for Kerberos, the other allows weak certificate mapping for Transport Layer Security (TLS) (Schannel). Either lets a renamed account be impersonated.

Example

With strong binding set to 0, the attacker swaps an account's User Principal Name (UPN) to a victim, enrolls in any client-auth template, reverts, and authenticates, no special template flag needed.

TechnicalGo deeper

Case 1: Risk: StrongCertificateBindingEnforcement = 0 (Kerberos) means name mapping is trusted outright, so ESC10 is ESC9 without needing a template flag. Case 2: Risk: CertificateMappingMethods including the weak UPN bit (0x4) lets the Schannel path (LDAP over SSL (LDAPS), Internet Information Services (IIS)) map by UPN, which is governed separately from Kerberos enforcement, so it can work even where Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) is strict. Fix: Fix: set strong binding to 2 and remove the weak Schannel bits.

07ESC14: weak explicit mappings (altSecurityIdentities)ESC14 abuses explicit certificate mappings on an account that are weak or attacker-writable.
In plain terms

Admins can explicitly tie a certificate to an account by writing to its altSecurityIdentities. If an attacker can write that attribute, or if it already contains a weak, forgeable mapping, they can map a certificate they hold onto the victim.

Example

An attacker with write over a victim's altSecurityIdentities adds a weak email-based mapping, then presents a certificate with that email to log on as the victim.

TechnicalGo deeper

Two shapes: Risk: write access to altSecurityIdentities (add a mapping to a cert you control), or an Risk: existing weak mapping (X509RFC822 email, or X509IssuerSubject) that you satisfy, sometimes by setting the victim's mail attribute. Weak mapping types (email, subject) are the problem; Fix: strong ones (issuer+serial, Subject Key Identifier (SKI), public key) resist this. Described by SpecterOps (2024). Fix: Fix: only strong explicit mappings, and restrict write on altSecurityIdentities and mail.

08ESC13: issuance policy linked to a groupESC13 is a certificate issuance policy linked to an Active Directory (AD) group, so holding the certificate grants the group's access.
In plain terms

A template can carry an issuance policy, and that policy can be linked to a security group. When you authenticate with such a certificate, your token includes that group, as if you were a member, without being one.

Example

An issuance policy on an enrollable template is linked to a privileged group. Enrolling and logging on gives a token containing that group, no membership change needed.

TechnicalGo deeper

The link lives in Risk: msDS-OIDToGroupLink on the issuance-policy object (an msPKI-Enterprise-Oid). Reported by Jonas Bülow Knudsen (SpecterOps, 2024). This doesn't touch certificate mapping at all, so Full Enforcement doesn't help; it's about token group membership. Prerequisites: enroll rights on a template with a group-linked issuance policy and a client-auth Enhanced Key Usage (EKU), or write over the policy object to add the link. Fix: Fix: audit msDS-OIDToGroupLink and never link issuance policies to privileged groups.

09ESC15 / EKUwu: application-policy injectionESC15 is injecting application policies into a certificate from a schema v1 template to gain an Enhanced Key Usage (EKU) it shouldn't have.
In plain terms

Old version-1 templates let the requester specify extra "application policies." On v1 templates those can override the template's intended purpose, so a template meant only for web servers can be coaxed into issuing a logon or enrollment-agent certificate.

Example

Using the built-in WebServer template, the attacker injects the Client Authentication application policy and gets a certificate usable for logon.

TechnicalGo deeper

This is Risk: Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019, "EKUwu," disclosed October 2024 and patched November 12, 2024. It works because v1 templates treat requester-supplied application policies as overriding the EKU. The injected policy can be Client Authentication, Certificate Request Agent, or code signing. It sidesteps mapping entirely, it's about getting an auth-capable certificate from a template that shouldn't give one. Fix: Fix: patch the Certificate Authoritys (CAs), then review or retire v1 templates that behave this way.

10ESC17: server-authentication certificate abuseESC17 abuses a server-authentication certificate to impersonate an Hypertext Transfer Protocol Secure (HTTPS) service such as a Windows Server Update Services (WSUS) server.
In plain terms

Most Escalations (ESCs) impersonate users. ESC17 is about impersonating a server: if an attacker can get a certificate with a chosen server name and the Server Authentication purpose, they can stand up a fake HTTPS service that clients trust, which for something like Windows Update can mean pushing malicious content.

Example

A template allows a requester-supplied subject but uses Server Authentication instead of Client Authentication; the attacker requests a cert for the WSUS server's name and intercepts update traffic.

TechnicalGo deeper

Newer and less settled than the others: research by Austin Coontz and, extending it, Alex Neff and Phil Knüfer ("WSUS Is SUS," 2025–2026), who proposed the ESC17 label. A common own-goal: Risk: "fixing" ESC1 by switching the Enhanced Key Usage (EKU) from Client to Server Authentication without removing enrollee-supplied subject creates ESC17 instead. The deep TLS-interception mechanics and relay specifics are beyond this note's scope and detection-and-defense focus; see the primary posts and an authorized lab. Fix: Fix: don't allow enrollee-supplied subject on server-auth templates either, and protect update/Transport Layer Security (TLS) infrastructure.

11Enforcement reality versus theoryOn paper Full Enforcement closes the SID-strip attacks; in practice many domains aren't fully there.
In plain terms

Microsoft made Full Enforcement the default, which should neutralise ESC9, ESC16 and the Kerberos side of ESC10. But organisations often loosened it to avoid breaking old certificates, and some attacks don't depend on it at all.

Example

A domain shows Full Enforcement on new Domain Controllers (DCs) but Compatibility on others after a migration, so an ESC9 path still works against the lagging ones.

TechnicalGo deeper

What survives Full Enforcement: Risk: ESC13 (group tokens), ESC15 (Enhanced Key Usage (EKU) injection), ESC14 where a strong-looking but attacker-controlled mapping exists, and ESC10 case 2 (Schannel). What it closes: Fix: ESC9, ESC16, and ESC10 case 1 (Kerberos name mapping). So verification matters: Verify: confirm every DC's actual StrongCertificateBindingEnforcement and CertificateMappingMethods, not just the domain default, before calling a mapping-defeat finding dead.

12The remediation programClosing Active Directory Certificate Services (AD CS) is a program across all three parts, with strong mapping as the keystone.
In plain terms

No single setting fixes AD CS. The durable posture combines the template fixes from Part 1, the Certificate Authority (CA) and key protections from Part 2, and the mapping hardening here, plus monitoring and treating the CA as Tier 0.

Example

A remediation plan: remove enrollee-supplied subject and scope templates (Part 1), lock CA rights and move the key to an Hardware Security Module (HSM) (Part 2), and enforce strong binding and clean mappings (Part 3).

TechnicalGo deeper

The keystone is Fix: Full Enforcement plus strong-only mappings: it neutralises the SID-strip class and caps the damage of a misconfigured template. Around it: Fix: remove CT_FLAG_NO_SECURITY_EXTENSION, ensure the CA includes the Security Identifier (SID) extension, fix CertificateMappingMethods, audit msDS-OIDToGroupLink and altSecurityIdentities, patch Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019, and retire risky v1 templates. Then Verify: continuous checking with Certipy/BloodHound, Locksmith for remediation, and CA/Domain Controller (DC) auditing, with the CA managed as Tier 0. That program, not any one patch, is what actually closes the series.

03

Visual map

Step through the ESC9 UPN-swap, the mapping-independent ESC13 and ESC15, and the hardening that denies them. Verify: Each attack step names the defense that breaks it.

The mapping-defeat attacks at a glance

Escalation (ESC)MechanismKey artefactClosed by Full Enforcement?Primary fix
ESC9No-SID templateCT_FLAG_NO_SECURITY_EXTENSIONFix: YesRemove the flag
ESC16No-SID CA-wideDisableExtensionListFix: YesRe-enable the Security Identifier (SID) extension
ESC10Weak Domain Controller (DC) mappingCertificateMappingMethods / binding valueCase 1 yes, Risk: case 2 noSet binding 2, fix Schannel
ESC14Weak explicit mapaltSecurityIdentitiesRisk: Not if the mapping looks strongStrong mappings only
ESC13Group-linked policymsDS-OIDToGroupLinkRisk: NoAudit group links
ESC15Enhanced Key Usage (EKU) injection (v1)schema v1 templateRisk: NoPatch Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019
ESC17Server-auth certenrollee-supplied Subject Alternative Name (SAN) + Server AuthRisk: NoRemove supplied subject

Enforcement modes

ModeValueBehaviour
Disabled0Risk: No strong-mapping check; name mapping trusted (no longer honored since Apr 2023)
Compatibility1Strong map used if present; Risk: falls back to name mapping when no SID extension
Full Enforcement2Fix: Deny if no strong mapping and no valid SID extension (the default since Feb 11, 2025)

What survives Full Enforcement

Closed by Full EnforcementSurvives it
ESC9 (no-SID template)ESC13 (group-linked policy)
ESC16 (no-SID CA-wide)ESC15 (EKU injection)
ESC10 case 1 (Kerberos name mapping)Risk: ESC10 case 2 (Schannel)
Classic ESC1 / ESC6 name spoofingRisk: ESC14 where a trusted-but-controlled mapping exists
ESC17 (server-auth, separate problem)
04

Technical deep dive

Technical

Under the hood

The mapping decision, and where each attack hits it

From Part 1, the Domain Controller (DC) binds a certificate to an account in order: the Security Identifier (SID) security extension (unforgeable), then strong explicit mappings in altSecurityIdentities, then the Subject Alternative Name (SAN) name. Each attack targets one rung:

  • Remove the SID extension so the name wins: Risk: ESC9 (per template) and ESC16 (per Certificate Authority (CA)).
  • Weaken the DC's rules so the name is trusted: Risk: ESC10, either the Kerberos binding value or the Schannel mapping methods.
  • Plant a weak explicit mapping: Risk: ESC14, via a writable or pre-existing weak altSecurityIdentities entry.
  • Skip mapping altogether: Risk: ESC13 (the token gets a group) and Risk: ESC15 (the certificate gets an Enhanced Key Usage (EKU) it shouldn't).

The UPN-swap primitive in detail

ESC9 and ESC10 both lean on implicit name mapping, so they need the certificate to name the victim. The reliable way is to control an account, set its userPrincipalName to the victim's User Principal Name (UPN), enroll (the issued certificate now names the victim), then set the UPN back. For a computer target the analogue involves dNSHostName/sAMAccountName and the machine's identity. This needs Risk: write over the account (GenericWrite, or control via a service account) and lands only when the DC falls back to name mapping, i.e. no SID extension present and not Full Enforcement. The swap-and-revert is a strong detection: Verify: a privileged UPN appearing briefly on a non-privileged account.

ESC9 and ESC16: removing the SID extension

CT_FLAG_NO_SECURITY_EXTENSION (0x80000 in msPKI-Enrollment-Flag) makes a single template omit the extension (ESC9). The CA-wide version (ESC16) adds the SID-extension Object Identifier (OID) (1.3.6.1.4.1.311.25.2) to the CA's DisableExtensionList, so Risk: no certificate from that CA carries a SID. ESC16 chains with ESC6: a CA that both accepts a requester-supplied SAN and omits the SID lets anyone impersonate anyone. Both depend on the DC not being in Full Enforcement; under enforcement a no-SID certificate without a strong explicit mapping is denied (event 39).

ESC10: the DC's own settings

Two registry values on the DC:

  • StrongCertificateBindingEnforcement = 0 (Kerberos) trusts name mapping outright, so Risk: ESC10 case 1 is ESC9 without needing a template flag.
  • CertificateMappingMethods with the weak UPN bit (0x4) lets the Risk: Schannel path (LDAP over SSL (LDAPS), Internet Information Services (IIS)) map by UPN. This is governed separately from Kerberos, so case 2 can work even where Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) is strictly enforced.

Neither value is readable by unprivileged users, so Verify: defenders should audit them directly on every DC; BloodHound now collects these as computer-node properties.

ESC13 and ESC14: tokens and explicit mappings

ESC13 links a certificate issuance policy to a group through msDS-OIDToGroupLink on an msPKI-Enterprise-Oid object. Enroll in a template carrying that policy and the resulting logon token Risk: includes the group, granting its access without membership. It doesn't touch mapping, so enforcement is irrelevant.

ESC14 abuses explicit mappings: either write access to a victim's altSecurityIdentities (add a mapping to a certificate you hold), or an existing weak mapping (X509RFC822 email, X509IssuerSubject) that you can satisfy, sometimes by setting the victim's mail. Fix: Strong mappings (issuer+serial, Subject Key Identifier (SKI), public-key) resist it; weak name/email mappings do not, even under Full Enforcement.

ESC15 and ESC17: not about mapping at all

ESC15 / EKUwu (Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019): schema v1 templates let the requester specify application policies that Risk: override the template's EKU. A WebServer-type template can thus yield a Client Authentication, Certificate Request Agent, or code-signing certificate. Patched November 12, 2024, the fix is the update plus reviewing v1 templates.

ESC17: abuse of a Risk: server-authentication certificate to impersonate an Hypertext Transfer Protocol Secure (HTTPS) service such as Windows Server Update Services (WSUS). A frequent cause is "fixing" ESC1 by switching the EKU to Server Authentication while leaving enrollee-supplied subject on. The deep TLS-interception and relay mechanics are beyond this note's detection-and-defense scope; see the primary research by Austin Coontz and by Alex Neff and Phil Knüfer, and an authorized lab.

Common misconceptions

MisconceptionReality
"Full Enforcement killed all these."It closes ESC9/ESC16/ESC10-case-1; Risk: ESC13, ESC15, ESC10-case-2 and some ESC14 survive.
"The domain default is Full Enforcement, so we're fine."Enforcement is Risk: per-DC; verify every DC's actual value.
"ESC9 is always critical."Only in Compatibility mode; denied under Full Enforcement.
"Strong Kerberos mapping covers Transport Layer Security (TLS) too."Schannel uses Risk: a separate setting (CertificateMappingMethods).
"Switching to Server Auth fixed our ESC1 template."If supplied-subject stayed on, Risk: that's now ESC17.
"Active Directory Certificate Services (AD CS) is closed once we enforce mapping."It's a program across all three parts, Fix: plus CA-as-Tier-0 and monitoring.

Verifying enforcement and configs

# Per-DC enforcement (run on each DC, or remotely with rights)
reg query "HKLM\SYSTEM\CurrentControlSet\Services\Kdc" /v StrongCertificateBindingEnforcement
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v CertificateMappingMethods

# CA-wide SID-extension suppression (ESC16)
certutil -config 'CA-HOST\CA-NAME' -getreg policy\DisableExtensionList

# Templates with the no-security-extension flag, group-linked policies, weak mappings
certipy find -vulnerable -stdout
05

Attacker's view

Attacker

Attacker's view, for defenders

Each technique is covered at recognition-and-defense level: the condition, what makes it vulnerable, the evidence it leaves, and how it reads as a finding, with a sharp eye on the enforcement-mode dependency. Weaponized syntax is omitted; the Certipy wiki and an authorized lab are for hands-on work.

ESC9: No Security Extension templateATT&CKT1649 Steal or Forge Authentication Certificates · T1098 Account Manipulation
How it works

The attacker enrolls in a template flagged to omit the Security Identifier (SID) security extension, after using write access to swap a controlled account's User Principal Name (UPN) to a victim's. The resulting certificate names the victim and carries no SID, so a non-enforcing Domain Controller (DC) maps it by name.

Prerequisites

Risk: An enrollable CT_FLAG_NO_SECURITY_EXTENSION template, write over a victim's UPN, a client-auth Enhanced Key Usage (EKU), and a DC not in Full Enforcement.

What makes an environment vulnerable

Templates created with the no-security-extension flag (sometimes set to fix SID-mismatch errors), plus Risk: domains left in Compatibility mode and loose write permissions on account UPNs.

Tools

Certipy (find flags it; req/auth), BloodHound (models the flag and the write edge).

# Recognise: UPN swap, enroll from the no-SID template, revert, authenticate
certipy find -vulnerable -stdout     # flags ESC9 templates
DefenderEvidence it leaves

Verify: A UPN changed to a privileged value and back (5136 on userPrincipalName), issuance from a no-SID template, and a Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) logon under Compatibility mode. Denied with Verify: DC event 39 under Full Enforcement.

ExecutiveAs a pentest finding

"A no-security-extension template plus UPN write enables impersonation." Critical in Compatibility-mode domains; largely mitigated under Full Enforcement. Retest: flag removed, Full Enforcement on, UPN write scoped.

ESC10: weak mapping settings on the Domain Controller (DC)ATT&CKT1649 Steal or Forge Authentication Certificates · T1098 Account Manipulation
How it works

The attacker relies on the DC's own mapping being weak: Kerberos strong binding disabled (case 1), or Schannel allowing weak User Principal Name (UPN) mapping (case 2). With a UPN swap, any client-auth certificate then impersonates the victim.

Prerequisites

Risk: StrongCertificateBindingEnforcement = 0 (case 1) or CertificateMappingMethods with the weak UPN bit (case 2), plus write over an account's UPN and enroll rights.

What makes an environment vulnerable

DCs left at weak settings, often from compatibility work. Case 2 matters because the Risk: Schannel path is governed separately from Kerberos enforcement.

Tools

Certipy, BloodHound (exposes the DC mapping properties it now collects).

# Recognise: no template flag needed; the DC's registry is the weakness
# Case 2 targets Schannel services (LDAPS/IIS), not PKINIT
DefenderEvidence it leaves

Verify: UPN changes on an account, certificate logons for a renamed account, and Schannel (LDAPS) authentications for case 2. The DC registry values are the root cause.

ExecutiveAs a pentest finding

"Weak DC certificate-mapping settings allow impersonation." Critical where present. Retest: strong binding = 2, weak Schannel bits removed, verified on every DC.

ESC16: Certificate Authority (CA) omits the Security Identifier (SID) extension globallyATT&CKT1649 Steal or Forge Authentication Certificates
How it works

The CA is configured to leave the SID extension off every certificate, so all its certificates are mappable by name. Combined with a user-supplied Subject Alternative Name (SAN) (ESC6) or a User Principal Name (UPN) swap, this impersonates anyone, CA-wide.

Prerequisites

Risk: The SID-extension Object Identifier (OID) in the CA's DisableExtensionList, plus a client-auth path and a Domain Controller (DC) not in Full Enforcement.

What makes an environment vulnerable

CAs configured to suppress the SID extension (sometimes to avoid breaking legacy clients); Risk: especially dangerous with ESC6 also set.

Tools

Certipy (find/req), certutil -getreg policy\DisableExtensionList.

certutil -config 'CA-HOST\CA-NAME' -getreg policy\DisableExtensionList
DefenderEvidence it leaves

Verify: Certificates issued CA-wide with no SID extension, and the DisableExtensionList value. Under Full Enforcement the name path is denied (event 39).

ExecutiveAs a pentest finding

"The CA suppresses the SID extension, enabling domain-wide impersonation." Critical, and worse with ESC6. Retest: SID extension re-enabled on the CA, Full Enforcement on.

ESC13: issuance policy linked to a groupATT&CKT1649 Steal or Forge Authentication Certificates · T1098.007 Additional Local or Domain Groups
How it works

An enrollable template carries an issuance policy linked to an Active Directory (AD) group. Authenticating with the certificate yields a token containing that group, granting its access without membership.

Prerequisites

Risk: An issuance policy linked to a privileged group via msDS-OIDToGroupLink, enroll rights on a template with that policy, and a client-auth Enhanced Key Usage (EKU), or write over the policy object to add the link.

What makes an environment vulnerable

Issuance policies linked to privileged groups (sometimes for legitimate assurance tiers), Risk: combined with broad enroll rights on the template.

Tools

Certipy (find/req/auth), BloodHound (models the OID-to-group link).

# Recognise: enroll in the group-linked template, then authenticate; token carries the group
certipy find -vulnerable -stdout     # flags ESC13 links
DefenderEvidence it leaves

Verify: Logons whose token includes a group the account doesn't belong to, and msDS-OIDToGroupLink on issuance-policy objects. Not visible as a mapping failure.

ExecutiveAs a pentest finding

"A certificate issuance policy grants privileged group access." Critical when the group is privileged; unaffected by strong-mapping enforcement. Retest: the link removed, enroll rights scoped.

ESC14: weak explicit mappings (altSecurityIdentities)ATT&CKT1649 Steal or Forge Authentication Certificates · T1098 Account Manipulation
How it works

The attacker exploits explicit certificate mappings that are weak or writable: writing a mapping to a certificate they control onto the victim, or satisfying an existing weak mapping (for example by setting the victim's mail).

Prerequisites

Risk: Write access to a victim's altSecurityIdentities, or a pre-existing weak mapping (X509RFC822 email, X509IssuerSubject) the attacker can satisfy, plus a suitable certificate.

What makes an environment vulnerable

Accounts carrying weak explicit mappings, or Risk: delegations that allow writing altSecurityIdentities or mail.

Tools

Certipy and direct Lightweight Directory Access Protocol (LDAP) tooling (some sources note ESC14 may need LDAP inspection rather than automated detection), BloodHound.

# Recognise: inspect altSecurityIdentities for weak mapping types
# (X509RFC822 / X509IssuerSubject are weak; issuer+serial / SKI / public-key are strong)
DefenderEvidence it leaves

Verify: 5136 changes to altSecurityIdentities or mail, and the presence of weak mapping types on accounts.

ExecutiveAs a pentest finding

"Weak or writable explicit certificate mappings allow impersonation." High to critical. Retest: only strong mappings remain, and write on altSecurityIdentities/mail is restricted.

ESC15 / EKUwu: application-policy injectionATT&CKT1649 Steal or Forge Authentication Certificates
How it works

On a schema v1 template, the requester injects application policies that override the template's Enhanced Key Usage (EKU), obtaining a certificate with a purpose it shouldn't have (client auth, enrollment agent, or code signing).

Prerequisites

Risk: An enrollable schema v1 template (such as the built-in WebServer) on a Certificate Authority (CA) not patched for Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019.

What makes an environment vulnerable

Risk: Unpatched CAs with enrollable v1 templates. Because v1 templates are common built-ins, the surface is wide until patched.

Tools

Certipy (supports ESC15), Certify.

# Recognise: v1 template + injected application policy = unintended EKU
# e.g. inject Client Authentication into a WebServer-template request
DefenderEvidence it leaves

Verify: Issuance from a v1 template whose cert carries an EKU/application policy it wasn't meant to, then a Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) or agent request.

ExecutiveAs a pentest finding

"Application-policy injection yields auth-capable certificates from v1 templates (CVE-2024-49019)." Critical until patched. Retest: CAs patched, v1 templates reviewed/retired.

ESC17: server-authentication certificate abuseATT&CKT1649 Steal or Forge Authentication Certificates · T1557 Adversary-in-the-Middle
How it works

The attacker obtains a server-authentication certificate for a chosen service name and uses it to impersonate an Hypertext Transfer Protocol Secure (HTTPS) service (for example Windows Server Update Services (WSUS)), intercepting or tampering with client traffic.

Prerequisites

Risk: A template allowing a requester-supplied subject with the Server Authentication Enhanced Key Usage (EKU) (often created by mis-fixing ESC1), plus a position to intercept the target service.

What makes an environment vulnerable

Risk: Server-auth templates with enrollee-supplied subject, and HTTPS services like WSUS that clients trust implicitly.

Tools

Certipy/Certify for the certificate; the interception tooling is beyond this note's scope. Research: Austin Coontz; Alex Neff and Phil Knüfer.

# Recognise: a server-auth cert for an internal service name requested by a non-owner
# Deep interception mechanics are out of scope here (see the primary research)
DefenderEvidence it leaves

Verify: Server-auth certificates issued for infrastructure hostnames to unexpected requesters, and anomalous Transport Layer Security (TLS) for services like WSUS.

ExecutiveAs a pentest finding

"Server-authentication certificate abuse enables service impersonation (e.g. WSUS)." Severity follows the service. Newer and less settled; retest: enrollee-supplied subject removed from server-auth templates too, and update/TLS infrastructure protected.

How these findings are rated

  1. Establish the enforcement mode on the target Domain Controllers (DCs) first; it decides whether the SID-strip attacks are live or latent.
  2. Separate mapping-dependent from mapping-independent: ESC13/ESC15 stand regardless; ESC9/ESC16/ESC10-case-1 hinge on Compatibility mode.
  3. Validate by attempting the auth, and record the mode and the exact artefact (flag, link, registry value).
  4. Report with the condition stated: "critical in Compatibility mode" is a different finding from "critical outright," and clients need to know which.
06

Defender's playbook

Defender

The strategy: make strong-binding enforcement universal and verified, keep only strong mappings, remove the SID-stripping flags, close the mapping-independent paths (group links, Enhanced Key Usage (EKU) injection, server-auth templates), and fold it all into the series' program with the Certificate Authority (CA) managed as Tier 0.

Quick wins (days)

  1. Verify enforcement on every Domain Controller (DC) (not just the default), then plan to bring any laggards to Full Enforcement.
    reg query "HKLM\SYSTEM\CurrentControlSet\Services\Kdc" /v StrongCertificateBindingEnforcement
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v CertificateMappingMethods
  2. Inventory weak certs before enforcing: in Compatibility mode, Verify: collect DC events 39/41 to find every certificate that lacks a strong mapping, so enforcing won't break them.
  3. Remove CT_FLAG_NO_SECURITY_EXTENSION from all templates (ESC9), and Fix: ensure the CA does not suppress the Security Identifier (SID) extension (ESC16: check DisableExtensionList).
  4. Audit msDS-OIDToGroupLink on issuance-policy objects and Fix: remove any link to a privileged group (ESC13).
  5. Clean up altSecurityIdentities: remove weak mappings, keep only strong ones, and Fix: restrict write on altSecurityIdentities and mail (ESC14).
  6. Patch Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019 on the CAs and review schema v1 templates (ESC15); and Fix: remove enrollee-supplied subject from server-auth templates too (ESC17).

Longer-term fixes (weeks to months)

  1. Make Full Enforcement universal and keep it there: remediate weak certs, flip every DC to 2, and Verify: alert if any DC drifts back.
  2. Fix the Schannel path: remove the weak User Principal Name (UPN) bit from CertificateMappingMethods so Fix: LDAP over SSL (LDAPS)/Internet Information Services (IIS) don't map by name (ESC10 case 2).
  3. Tighten account-attribute permissions: restrict who can write userPrincipalName, altSecurityIdentities, mail, and issuance-policy objects, since these are the write-primitives behind ESC9/10/13/14.
  4. Complete the series program: templates (Part 1), CA config/rights/relay/key with the CA as Tier 0 and the key in an Hardware Security Module (HSM) (Part 2), and this part's mapping hardening.
  5. Continuous checking: schedule Certipy/BloodHound collection across all Escalation (ESC) classes and Verify: alert on new no-SID templates, group links, weak mappings, and enforcement drift.
  6. Keep Active Directory Certificate Services (AD CS) in the Incident Response (IR) playbook: forged-cert hunting, NTAuthCertificates review, and enforcement verification during any suspected identity incident.

Detection signals

SignalSourceAlert on
DC events 39 / 41DC System log (Kdcsvc)Verify: 39 no strong mapping / no SID; 41 SID mismatch, which flag both weak certs and active probing
5136: userPrincipalName changedDC Security logA UPN set to a privileged value (and reverted) — the ESC9/ESC10 swap
5136: altSecurityIdentities / mail changedDC Security logNew or weak explicit mappings, or a mail set to match one (ESC14)
5136: msDS-OIDToGroupLink changedDC Security logA link added from an issuance policy to a group (ESC13)
Token carries an unexpected groupAuthentication / Security Information and Event Management (SIEM)A logon whose groups include one the account isn't a member of (ESC13)
Issuance from a v1 template with an odd EKUCA Security log (4887)A WebServer-type template issuing an auth or agent certificate (ESC15)
Enforcement/registry driftConfig monitoringStrongCertificateBindingEnforcement or CertificateMappingMethods moving away from strong values

Verify the fix worked

  1. Verify: Confirm StrongCertificateBindingEnforcement = 2 on every DC, and that CertificateMappingMethods has no weak UPN bit.
  2. Re-run certipy find and confirm no ESC9/ESC13 flags, and that the CA's DisableExtensionList doesn't suppress the SID extension.
  3. Confirm no privileged msDS-OIDToGroupLink, and only strong altSecurityIdentities mappings remain.
  4. Confirm the CAs are patched for CVE-2024-49019 and server-auth templates don't allow enrollee-supplied subject.
  5. Attempt the ESC9 UPN-swap against a hardened DC and Verify: confirm it's denied (event 39) and the swap alerts fire.

Why remediation stalls, and workable compromises

ObjectionWorkable compromise
"Full Enforcement broke auth before."Verify: Inventory weak certs via 39/41 in Compatibility first, remediate, then enforce, so nothing breaks at flip time.
"We can't reissue every legacy cert yet."Add strong altSecurityIdentities mappings as a bridge while re-enrollment proceeds, then enforce.
"The Schannel setting is obscure and risky to touch."Test on one DC, confirm LDAPS/IIS clients still work, then roll out; the weak UPN bit is the exposure.
"Issuance policies are linked to groups for an assurance tier."Keep the assurance tier but Fix: link to a non-privileged group, or gate access another way; never link to Tier 0 groups.
"Patching the CAs needs a maintenance window."Prioritise CVE-2024-49019; in the meantime Fix: restrict enroll on v1 templates as a stopgap.
"This is a lot across three parts."Sequence by leverage: Fix: enforcement verification and the CA key first, then templates and attribute hygiene.
07

Executive brief

Executive

The risk in plain language

In 2022 Microsoft added a tamper-proof identity to certificates, and in 2025 made checking it mandatory, which stopped the simplest impersonation. The attacks in this part are the ways around that: Risk: issuing certificates without the tamper-proof identity, exploiting settings we may have loosened for compatibility, or using tricks that don't involve that identity at all, Risk: such as hiding privileged group access inside a certificate. The good news is that finishing the 2025 change, everywhere, removes a whole class of these.

Business impact

  • Where the strict check isn't fully on, Risk: the original "become an administrator" attack comes back, a quiet path to full control.
  • One technique Risk: grants privileged group access without changing group membership, so our access reviews wouldn't catch it.
  • These are the final pieces of a certificate-system risk that, unaddressed, Risk: undermines the trust our whole network places in logins.

What drives likelihood

  • Domain controllers left in the weaker compatibility mode after a cautious rollout.
  • Certificates or settings that omit the tamper-proof identity.
  • Loose permissions on the account attributes and policy objects these attacks edit.
  • An unpatched 2024 flaw on the certificate servers.

Cost of inaction

The fixes are mostly configuration, plus one software update: finish enforcing the strict check everywhere, clean up a few settings and permissions, and patch the 2024 flaw. Leaving them means we've Risk: done most of the 2025 work but left the door ajar, and some attacks that bypass it entirely remain open.

What good looks like

  • The strict identity check is Fix: on and verified on every domain controller, not just set as a default.
  • Certificates and the certificate server Fix: always include the tamper-proof identity.
  • Privileged group access Fix: can't be smuggled into a certificate, and explicit exceptions use only unforgeable mappings.
  • The 2024 flaw is Fix: patched, and we Verify: monitor for any of these settings drifting back.

Questions executives ask

Didn't the 2025 Microsoft change fix the certificate impersonation problem?

"For the simplest version, largely yes, once it's actually enforced everywhere. The attacks in this part are the ways around it: removing the tamper-proof identity from certificates, or exploiting settings we loosened for compatibility. Some don't involve that check at all. So the fix is real but partial, and the work is making enforcement complete and cleaning up the enabling settings."

Why would our own domain controllers be set to the weaker mode?

"To avoid breaking older certificates during the rollout. Microsoft gave a compatibility mode so authentication didn't suddenly fail. Risk: The risk is leaving it there. We should confirm every domain controller is on the strict setting, which is now the default, and fix any that lag."

You said one attack grants admin-group access without joining the group. How?

"A certificate can carry a policy that's linked to a group. When you log in with it, the system treats you as if you had that group, Risk: without your account ever being added. Our access reviews wouldn't show it, which is what makes it sneaky. The fix is to stop linking those policies to privileged groups and to audit for it."

Is any of this a vulnerability we patch, or all configuration?

"Mostly configuration, with one notable patch: a 2024 flaw (we'll give the reference) that let certain old templates issue the wrong kind of certificate. Fix: That one needs the update on our certificate servers; the rest are settings and permissions we tighten and verify."

How do we know we're actually closed out after all three parts?

"We re-run the same tools an attacker uses and confirm nothing flags, then verify the strict certificate setting on every domain controller and the key protections on the certificate server. Verify: It becomes a number we can track and a quarterly check, not a one-time cleanup."

What's the one thing to get right if we do nothing else?

"Make the strict certificate-mapping setting truly universal, the 2025 default, on every domain controller. Fix: It neutralises the whole class of impersonation attacks that remove the tamper-proof identity, and caps the damage of a misconfigured template. Then protect the certificate server's key."

Presenting this finding to leadership

  1. Headline: "We largely finished the 2025 certificate hardening; these are the remaining gaps and the bypasses that ignore it, Risk: with a clear, mostly-configuration fix."
  2. Make it concrete: show a domain controller still in compatibility mode, or a certificate policy linked to an admin group.
  3. Frame the keystone: universal enforcement neutralises a whole class; the rest are targeted cleanups.
  4. The ask: finish enforcement everywhere, clean up the enabling settings, patch the 2024 flaw, and stand up monitoring, completing the three-part program.
08

Talk the talk

Jargon decoder

ESC9

A template flagged to omit the Security Identifier (SID) security extension, enabling name-based impersonation.

"ESC9 plus a User Principal Name (UPN) write gets us the admin, if they're in Compatibility mode."

ESC10

Weak certificate-mapping settings on the domain controller itself.

"Strong binding is 0 here, textbook ESC10 case 1."

ESC13

An issuance policy linked to a group, so the certificate grants that group.

"The high-assurance policy is linked to a privileged group, ESC13."

ESC14

Weak or attacker-writable explicit mappings in altSecurityIdentities.

"They can write altSecurityIdentities on the Domain Admin (DA), that's ESC14."

ESC15 / EKUwu

Application-policy injection on v1 templates (Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019).

"The Certificate Authority (CA)'s unpatched, so EKUwu turns WebServer into a logon cert."

ESC16

A Certificate Authority (CA) configured to omit the Security Identifier (SID) extension for every certificate.

"ESC16: the whole CA drops the SID extension, worse with ESC6."

ESC17

Abuse of a server-authentication certificate to impersonate an Hypertext Transfer Protocol Secure (HTTPS) service.

"They mis-fixed ESC1 into ESC17; now the Windows Server Update Services (WSUS) name is enrollable."

Security Identifier (SID) security extension

The tamper-proof account SID the Certificate Authority (CA) embeds; strong mapping checks it.

"No SID extension means the Domain Controller (DC) falls back to the name."

StrongCertificateBindingEnforcement

The Domain Controller (DC) registry value (0/1/2) controlling Kerberos strong mapping.

"Confirm StrongCertificateBindingEnforcement is 2 on every DC."

CertificateMappingMethods

The Domain Controller (DC) registry value governing Schannel (TLS) certificate mapping.

"CertificateMappingMethods still has the weak User Principal Name (UPN) bit, that's the Schannel path."

User Principal Name (UPN) swap

Temporarily setting a controlled account's UPN to a victim's to impersonate by name.

"The UPN-swap-and-revert is the primitive behind ESC9 and ESC10."

altSecurityIdentities

The account attribute holding explicit certificate mappings.

"Keep only strong mappings in altSecurityIdentities."

Issuance policy

A policy Object Identifier (OID) a certificate can carry, optionally linked to a group (ESC13).

"Which issuance policies are linked to groups?"

Full Enforcement

Strong-binding mode 2: deny certs without a strong mapping or Security Identifier (SID). The 2025 default.

"Under Full Enforcement the no-SID tricks are denied."

Smart questions to ask

Sysadmins

  • Is StrongCertificateBindingEnforcement set to 2 on Verify: every Domain Controller (DC), verified, not just the default?
  • Does CertificateMappingMethods still carry the Risk: weak User Principal Name (UPN) bit for Schannel?
  • Do any templates have Risk: CT_FLAG_NO_SECURITY_EXTENSION, or does the Certificate Authority (CA) suppress the Security Identifier (SID) extension?
  • Are any issuance policies Risk: linked to privileged groups via msDS-OIDToGroupLink?
  • Are the CAs patched for Fix: Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019, and are v1 templates reviewed?
  • Who can write userPrincipalName, altSecurityIdentities and mail?

Executives

  • Did we finish the 2025 certificate change everywhere, or just set it as a default?
  • Could someone gain admin-group access without being added to the group?
  • Do we Verify: monitor for these certificate settings slipping back?

Coworkers

  • Did we confirm the enforcement mode per DC before rating the SID-strip findings?
  • Is this finding mapping-dependent or mapping-independent?
  • Did we check the Risk: Schannel path, not just Kerberos?

Say this, not that

Not this

"The 2025 update fixed Active Directory Certificate Services (AD CS)."

Say this

"Full Enforcement closes the SID-strip attacks where it's actually on; ESC13, ESC14 and ESC15 are independent of it."

Not this

"ESC9 is critical, full stop."

Say this

"ESC9 is critical in Compatibility mode; under Full Enforcement the no-SID cert is denied, so check the Domain Controller (DC)'s mode first."

Not this

"We enforce strong mapping, so mapping attacks are dead."

Say this

"That closes the Kerberos SID-strip paths; the Schannel path and the non-mapping Escalations (ESCs) still need fixing."

Not this

"They're not in the admin group, so they're not admin."

Say this

"With ESC13 the token carries the group without membership, so group reviews won't show it."

Not this

"We switched the template to Server Authentication to fix ESC1."

Say this

"If enrollee-supplied subject is still on, that's now ESC17, server impersonation; remove the supplied subject."

Not this

"Weak mappings are fine, they still require a cert."

Say this

"Email and subject mappings are forgeable; keep only issuer+serial, Subject Key Identifier (SKI) or public-key mappings."

Not this

"One setting will close Active Directory Certificate Services (AD CS)."

Say this

"It's a program: templates (Part 1), the Certificate Authority (CA) and key (Part 2), and strong mapping plus clean configs (Part 3)."

Same point, two audiences

Enforcement is the keystone, but must be universal.
Executive

"The 2025 strict setting neutralises a whole class of these attacks, but only on the servers where it's actually turned on. We need it everywhere."

Sysadmin

"Confirm StrongCertificateBindingEnforcement = 2 on every Domain Controller (DC), not just the domain default, and remediate certs that relied on weak mappings."

Some attacks ignore the mapping entirely.
Executive

"A few of these don't touch the identity check at all, so that fix won't catch them; they need their own cleanup."

Sysadmin

"ESC13 (group-linked issuance policy) and ESC15 (Enhanced Key Usage (EKU) injection) are mapping-independent; audit msDS-OIDToGroupLink and patch Common Vulnerabilities and Exposures (CVE) entry CVE-2024-49019."

Mis-fixing one issue can create another.
Executive

"A quick fix to one certificate problem can quietly open a different one if it's done without the full picture."

Sysadmin

"Switching ESC1's Enhanced Key Usage (EKU) to Server Auth without removing enrollee-supplied subject creates ESC17; remove the supplied subject instead."

Closing Active Directory Certificate Services (AD CS) is a program, not a patch.
Executive

"There's no single switch. It's a short program across the certificate system that we can complete and then keep verified."

Sysadmin

"Templates, Certificate Authority (CA) config and key, then strong mapping and clean attributes, plus continuous Certipy/BloodHound checks and CA/Domain Controller (DC) auditing."

09

Keep going

You've finished the Active Directory Certificate Services (AD CS) series

Across three parts you've covered the certificate templates (ESC1–ESC4), the Certificate Authority (CA), access control and relay (ESC5–ESC8, ESC11), theft and golden-certificate persistence, and the mapping-defeat and newer techniques (ESC9, ESC10, ESC13–ESC17), plus the remediation program that ties them together. The keystone is universal strong-mapping enforcement, with the CA managed as Tier 0.

What to learn next, in order

  1. NT LAN Manager (NTLM) relay and coercion in depth. The engine behind ESC8/ESC11, and a topic in its own right (PetitPotam, Coercer, Extended Protection for Authentication (EPA), signing). It connects AD CS to the wider relay problem.
  2. The enterprise access model and Tier 0. How to actually build and verify the tiering that makes "the CA is Tier 0" real.
  3. Entra and hybrid certificate trust. Certificate-based authentication and device identity as environments move to the cloud, where some of this trust is re-homed.
  4. Detection engineering for AD CS. Turning the events in this series (4886/4887, 4876/4877, 39/41, 5136 on the key attributes) into reliable, low-noise alerts.

Related notes

  • AD CS abuse, Parts 1 and 2, the rest of this series.
  • Active Directory attack paths, thinking in graphs, where AD CS appears as ADCSESC edges and the GoldenCert edge.
  • The Kerberos series, for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), delegation, coercion and DCSync.

Resources worth seeking out

  • SpecterOps' AD CS research, including the ESC13 and ESC14 write-ups and the BloodHound AD CS attack-path posts.
  • The Certipy wiki (ly4k/Certipy), for per-ESC conditions and the current ESC1–ESC17 coverage.
  • Microsoft's KB5014754, the authoritative reference on strong certificate mapping and the enforcement timeline.
  • The ESC17 primary research (Austin Coontz; Alex Neff and Phil Knüfer), for the server-authentication and Windows Server Update Services (WSUS) angle left out of scope here.
  • Locksmith and PSPKIAudit, for defensive enumeration and remediation across the whole AD CS attack surface.
My private notebook

Personal notes and bookmarks are private. Unsaved text is temporarily kept in this tab’s browser storage to recover supported sign-in redirects and reloads. Closing the tab may lose unsaved text.

Checking sign-in…

Sign in in another tab Sign in in this tab All my notes