# AD CS certificate template abuse Source: https://startwithidentity.com/techniques/adcs-certificate-template-abuse/ Last updated: 2026-08-29 License: content by Start with Identity. Cite the source URL. --- ## How it works Active Directory Certificate Services (AD CS) issues X.509 certificates that domain-joined systems use for authentication, code signing, and other purposes, governed by templates that define who can request a certificate and what that certificate is allowed to do. A template can be configured to let a low-privileged user enroll for a certificate that carries a subject alternative name they control, or that includes an enhanced key usage granting client authentication rights, or that inherits weaker restrictions than the administrators who published it intended. Certified, tracked as CVE-2022-26923, exploited how the domain controller mapped a certificate to an Active Directory account: an authenticated user with permission to modify an attribute on their own computer object could obtain a certificate that Active Directory then mapped to a domain controller account, because the mapping logic trusted an attacker-controllable field. ESC15, tracked as CVE-2024-49019, is a distinct flaw in how legacy V1 templates handle an Application Policy extension: it can take precedence over the enhanced key usage the template administrator intended, letting a certificate carry usage rights the template was never meant to grant. Both are template and mapping trust failures rather than cryptographic breaks; the certificate authority signs exactly what it was configured to sign, and the configuration is the vulnerability. ## Why it works Certificate services are trusted implicitly by the systems that rely on them, because a valid certificate signed by an internal certificate authority is, by design, treated as strong proof of identity. The control assumption that fails is that every template a certificate authority will issue against was reviewed with the same rigor as the domain's core security policy. In practice, templates accumulate over years, get copied from defaults, and inherit permissions nobody re-examines once the initial use case is gone. A template that grants broad enrollment rights or that lets a requester influence a field the domain later trusts for identity mapping turns the certificate authority into an identity-issuance path that bypasses password policy, MFA, and Kerberos pre-authentication entirely, because it never touches any of them. ## How to detect it - Certificate issuance events where the requesting account's privilege level is inconsistent with the enhanced key usage or subject name granted, which requires correlating certificate authority logs against Active Directory group membership at issuance time. - Authentication events using a certificate-based credential from an account that has no history of certificate-based authentication. - Template permission changes, particularly grants of enrollment rights to broad groups such as Domain Users or Authenticated Users, which is the change auditors and defenders should treat as a standing risk regardless of whether it has been exploited. Be honest about the limits: certificate authority logging is frequently disabled or retained for a shorter window than other AD security logs, and many organizations discover during an assessment that they cannot reconstruct issuance history for a template that has existed for years. Detection here depends on logging being enabled before the fact; there is often nothing to review after. ## How to stop it - **Audit every certificate template's enrollment permissions** and remove enrollment rights from broad groups that do not need them, treating this as a standing configuration review rather than a one-time cleanup. - **Apply the strong certificate mapping guidance** (Microsoft KB5014754) so that certificate-to-account mapping cannot be influenced by an attacker-controllable field, closing the class of issue CVE-2022-26923 exploited. - **Patch promptly and review V1 template configurations** for the Application Policy precedence issue behind CVE-2024-49019, since finding it requires first identifying which templates are schema version 1 and allow requester-supplied subject details, a step organizations that only track CVE and patch level, not template configuration, tend to skip. - **Enable and retain certificate authority issuance logging**, since without it there is no way to reconstruct what a template issued or to whom after the fact. - **Treat AD CS as tier-0 infrastructure**, subject to the same change control and access review as domain controllers, since a compromised template can produce a credential as powerful as one. See [certificate lifecycle management](https://startwithidentity.com/glossary/certificate-lifecycle/) and [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/). ## Seen in the wild - [Certifried, AD CS certificate mapping privilege escalation](https://startwithidentity.com/cves/cve-2022-26923/) - [ESC15 / EKUwu, AD CS V1 template Application Policy precedence](https://startwithidentity.com/cves/cve-2024-49019/) ## Sources - [MITRE ATT&CK T1649: Steal or Forge Authentication Certificates](https://attack.mitre.org/techniques/T1649/) - [Microsoft KB5014754: Certificate-based authentication changes](https://support.microsoft.com/en-us/servicing/os/windows-server/2022/05/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers)