AD CS ESC attacks: certificate security assessment

An Active Directory Certificate Services security assessment determines whether an ordinary user, service operator or compromised host can obtain a certificate that authenticates as a more privileged identity. The most serious paths do not break cryptography. They combine write permissions, template settings, certificate extensions, account mapping and domain-controller trust.

The answer-first point is that an authentication-capable certificate is a credential. It can remain valid after a password rotation and may not appear in a conventional review of administrative groups. Treat AD CS as part of the Active Directory identity plane; certification authorities, CA private keys, templates and enrolment endpoints are tier-critical assets.

This guide explains the technical model behind ESC classes, a safe penetration testing method and hardening priorities. It deliberately omits commands for requesting another person’s certificate and turnkey domain-compromise chains. Active validation should use dedicated identities, an approved lab template and a nonprivileged target account.

How can a certificate replace a password?

In certificate authentication, a client possesses a private key and presents a certificate issued by a trusted authority. For Kerberos, PKINIT uses public-key cryptography while obtaining a Ticket Granting Ticket. The domain controller must then determine which AD object the certificate represents. That mapping — not simply the displayed certificate name — determines identity.

A certificate contains a Subject, Subject Alternative Name (SAN), Extended Key Usage (EKU), validity interval, issuer, serial and other extensions. EKUs such as Client Authentication, Smart Card Logon or an appropriate PKINIT purpose can enable authentication depending on the consuming path and configuration. A SAN may contain a UPN or another identity. If the requester can insert someone else’s identity and the CA issues without an additional control, impersonation becomes possible.

Through KB5014754, Microsoft introduced and eventually enforced stronger binding between a certificate and its directory account. Current domain controllers should not accept weak mappings in the same way as legacy configurations. That change does not eliminate every ESC path. Rights over templates, the CA, enrolment agents, the authority key or enrolment endpoints remain material risks.

Model the AD CS trust graph

Start with a graph, not a server list. Relevant nodes include:

enterprise and standalone CAs, their hierarchy and the NTAuth store;
CA computer accounts, services and private keys;
certificate-template objects in AD’s Configuration partition;
groups holding Enroll, Autoenroll, Write, WriteDACL and WriteOwner;
Manage CA and Manage Certificates roles;
Web Enrollment, CES/CEP, NDES and RPC surfaces;
users and computers with explicit certificate mappings;
issuance policies, application policies and approval requirements.

A critical path exists when a principal controls enough edges to change a template, publish it, enrol, influence the represented identity, approve a request or direct someone else’s authentication to an endpoint without channel protection. Enrol alone is not necessarily a defect. Risk is the combination of conditions.

ESC1: the requester supplies certificate identity

The classic ESC1 configuration combines broad enrolment, requester-supplied Subject/SAN, an authentication-capable EKU and no manager approval or required authorised signatures. An unprivileged user can then request a certificate representing another identity.

Finding “Supply in the request” is not sufficient evidence. Confirm whether the template is published, who may enrol, which EKUs and application policies it carries, whether the CA accepts SAN attributes, whether signatures are required, how fully patched domain controllers map the result and which authentication service accepts it. Microsoft Defender for Identity documents these combined conditions in its assessment for certificates valid for arbitrary users.

Remediation commonly unpublishes the template pending review, removes broad enrolment groups, builds Subject from AD, narrows EKUs, introduces approval or signatures where justified, and reissues affected certificates. Do not delete a template before inventorying dependent services.

ESC2 and ESC3: Any Purpose and enrolment agents

A template with Any Purpose or no restrictive EKU may produce a certificate with broader use than its owner intended. Actual impact depends on which services and validation paths accept it. Assess certificate consumers rather than rating the template label in isolation.

An Enrollment Agent legitimately allows an authorised principal to sign requests on another person’s behalf. If poorly constrained, it creates a chain: one template issues an agent certificate and another accepts the agent signature for a user’s authentication certificate. Controls include CA-level agent restrictions, permitted templates and target groups, approval, separation of duties and use monitoring.

A safe test confirms configuration and, only after approval, performs issuance for a controlled identity. Do not choose a Domain Administrator as the demonstration target: obtaining that certificate itself creates a durable sensitive credential.

ESC4 and ESC5: control of PKI configuration objects

A certificate template is an Active Directory object with an owner and ACL. If an unprivileged group can change its properties, DACL or owner, that group can potentially create the conditions of another ESC class. That is the essence of ESC4: a nominally safe template becomes dangerous through control of its configuration.

ESC5 describes broader PKI objects and dependencies whose compromise changes trust: CA objects, publication containers, services, hosts and management components. Review ACLs in the Configuration partition, ownership, delegated groups and the ability to modify GPOs applied to CA servers. Combine this with a full Active Directory security review, because control of the CA host may originate from a distant domain path.

Remediation restores a known minimal owner-and-rights set and creates monitoring for object changes. A one-time ACL export is insufficient; configuration drift must be detected.

ESC6 and ESC7: authority settings and CA roles

A CA-wide flag that accepts SAN attributes from a request can extend risk beyond templates explicitly configured for requester-built subjects. Strong-mapping changes affect the impact of particular variants on current patched controllers, but a global SAN flag still expands the attack surface unnecessarily.

Manage CA and Manage Certificates are powerful roles. Depending on configuration they can alter authority settings, publish templates, approve pending requests or defeat manager approval. Microsoft recommends removing these rights from broad unprivileged groups. Separation of duties works only if one person or compromise-prone service identity cannot trivially collect the full chain.

CA administration should use dedicated workstations and time-bound activation under privileged access management. A PKI operator identity should not be used for email, web browsing or ordinary work.

ESC8 and ESC11: relay to enrolment endpoints

ESC8 concerns NTLM relay to HTTP enrolment endpoints such as Web Enrollment or CES when the service accepts NTLM without effectively binding authentication to the channel. HTTPS encrypts transport but does not stop relay by itself. Extended Protection for Authentication uses a Channel Binding Token or service binding to tie authentication to the correct TLS channel or service.

Microsoft Defender for Identity identifies IIS enrolment endpoints without enforced HTTPS or EPA as ESC8 exposure. Remove Web Enrollment roles when they are not needed. Where they remain, require TLS, EPA, correct SPNs, reduced NTLM, network segmentation and a minimal set of templates reachable through that endpoint.

Later research nomenclature also covers relay to RPC enrolment interfaces under ESC11 when integrity protection is insufficient. Conditions differ from HTTP, so a report should name the protocol, endpoint, required flags and system versions rather than merely say “AD CS is vulnerable.” Our analysis of NTLM relay, SMB signing, LDAP and EPA explains the wider relay model.

ESC9, ESC10 and ESC14: certificate mapping weaknesses

These classes focus on binding a certificate to an account. Missing security extensions in a template, weak mapping methods or writable explicit altSecurityIdentities mappings can make a certificate resolve to an unintended identity. The current KB5014754 state is central to impact.

During the 2025 update timeline, domain controllers entered full strong-mapping enforcement, and Microsoft later removed the compatibility rollback according to its published schedule. An assessment must examine patch levels across every DC, actual KDC events, certificate origin and explicit mappings. Do not “fix” an outage automatically by adding a name-based mapping that weakens the binding again.

Review write permissions over UPN, DNS host name, SPN and altSecurityIdentities. Control of an identity attribute can create a path even when the template appears correct. After mapping changes, assess already-issued certificates and renewal workflows, not only new requests.

ESC13 and ESC15: issuance and application policies

An issuance policy can be linked to an AD group, allowing a certificate satisfying that policy to influence authorisation. Incorrect OID-to-group links, broad enrolment or writable related objects can grant rights outside ordinary IAM visibility. Review OIDs, groups, ACLs and every application that interprets the policy.

ESC15 is a newer class involving arbitrary application policies under particular template conditions on unpatched AD CS, associated with CVE-2024-49019. Microsoft added a Defender for Identity posture assessment for it. Remediation requires patches and template review; restricting the management-console UI does not change protocol behaviour.

ESC labels provide a helpful industry vocabulary but are not a Microsoft product standard and continue to evolve with research. A strong report always documents the underlying condition, version and evidence so remediation does not depend on category numbering.

A safe AD CS penetration testing methodology

1. Passive inventory

Collect authorities, hierarchy, published templates, issuance settings, ACLs, enrolment groups, endpoints and patch level. Review NTAuth, CDP/AIA, validity periods and algorithms. Query the directory as a standard user to model what a normal domain principal can see.

2. Permission-graph analysis

For each template, connect enrolment rights, object control, mutable principal attributes, CA settings, EKUs, approval and mapping. Separate direct paths from those requiring host compromise or relay. A graph is a hypothesis; confirm each condition independently.

3. Controlled validation

Perform active issuance only with approval and a synthetic identity carrying no business access. Do not export the CA key, request an administrator certificate or retain an authentication certificate after the test. Record request ID, serial, template, issuer, time and revocation process.

4. Cleanup and retest

Revoke assessment certificates, publish CRLs according to procedure, remove artefacts from controlled stores and verify that no persistent changes remain. After remediation, repeat configuration collection and the negative test rather than relying on a management-console screenshot.

AD CS detection and monitoring

The Advanced Audit Policy category Audit Certification Services produces events for requests, issuance, settings and CA database operations. Valuable events include 4886 for received requests, 4887 for approval and issuance, 4888 for denials, plus authority and template changes. Exact coverage depends on system and enabled subcategories, so validate telemetry with an approved test request.

Correlate requester, template, SAN/Subject, issuer, request ID, target account and subsequent certificate authentication. High-value alerts include:

an authentication certificate for a privileged identity requested by an unusual principal;
a rare or newly published template being used;
changes to template ACL, owner, EKU, application policy or Subject flags;
enabling global request SAN acceptance or changing CA roles;
bursts of requests following coerced authentication to an enrolment endpoint;
certificate authentication after password rotation or from an unusual device.

Export logs and configuration backups beyond the administrative boundary of the domain. An actor controlling the CA or Domain Admin can alter local evidence. AD CS monitoring complements cloud identity controls in our Microsoft 365 security guide; it does not replace them.

AD CS hardening priorities

Remove unused endpoints and unpublish unused templates. Confirm the owner and dependencies first.
Restrict Enroll and Autoenroll. Avoid broad groups for authentication-capable certificates.
Build Subject from AD. Keep requester-supplied identity only for documented cases with compensating controls.
Narrow EKUs and application policies. A certificate should carry only its required purpose.
Enforce strong mapping. Maintain DC and CA updates, investigate KB5014754 events and reissue incompatible certificates.
Require TLS and EPA for IIS enrolment. Then reduce or remove NTLM where possible.
Protect CA roles and hosts. Dedicated administration, JIT, MFA, segmentation, EDR, protected key backups and export control.
Baseline configuration. Alert on drift in templates, ACLs, OIDs, CA settings and NTAuth.
Use risk-appropriate validity. Automate renewal and make revocation effective.
Exercise CA compromise recovery. Plan trust removal, hierarchy replacement, reissuance and service dependencies.

A Zero Trust security model means continuously verifying certificate issuance and use, not accepting every artefact from a trusted CA without context.

AD CS assessment checklist

Conclusion

Securing AD CS is not a scanner run against a list of ESC numbers. Teams need the full relationship: who can change configuration, who can enrol, which identity the certificate represents, how the KDC maps it and where the certificate is accepted. Only this model distinguishes a harmless-looking setting from a path to domain compromise.

If you need an independent review of templates, authorities and certificate attack paths under controlled rules, contact Breachroad. The deliverable will contain technical conditions, prioritised remediation, safe evidence and detection scenarios without leaving new privileged credentials behind.