This wiki assumes you're familiar with fundamental Active Directory (AD) concepts. Before exploring attack techniques, it's essential to understand key components and terminology related to Active Directory Certificate Services (AD CS) and certificate-based authentication.

Public Key Infrastructure (PKI)

A Public Key Infrastructure (PKI) is a comprehensive system of hardware, software, policies, standards, and procedures used to create, manage, distribute, use, store, and revoke digital certificates. In enterprise environments, PKI is the foundation for establishing digital trust. It enables the secure association of public keys with verified user identities (or machine/service identities) through digital certificates, thereby facilitating encrypted communications, data integrity, and robust authentication mechanisms like smart card logon or certificate-based network authentication. AD CS is Microsoft's implementation of a PKI for Windows environments, providing the necessary components to issue and manage digital certificates.

Active Directory Certificate Services (AD CS)

Active Directory Certificate Services (AD CS) is Microsoft's server role for implementing a PKI within Windows environments. It integrates deeply with Active Directory Domain Services (AD DS) for identity information, certificate template storage, and publication of certificate-related information (like CA certificates and Certificate Revocation Lists). AD CS provides services for issuing and managing X.509 digital certificates used in various security protocols and applications. Key AD CS role services include the Certificate Authority (CA), Web Enrollment, Certificate Enrollment Policy Web Service (CEP), Certificate Enrollment Web Service (CES), and Online Certificate Status Protocol (OCSP) Responder. Misconfigurations within AD CS are a common source of security vulnerabilities.

Certificate Authority (CA)

A Certificate Authority (CA) is a trusted entity responsible for issuing and managing digital certificates. The CA server role in AD CS performs this function. It validates certificate requests against defined policies (often through certificate templates in an Enterprise CA context) and, if approved, signs the certificate with its own private key. The CA's corresponding public key is distributed to clients in the form of a CA certificate. This CA certificate needs to be trusted by relying parties for the certificates issued by that CA to be considered valid. CAs can be organized in a hierarchy, with a Root CA at the top and one or more Subordinate (or Issuing) CAs. The private key of a CA, especially a Root CA or an Enterprise Issuing CA, is a critical asset; its compromise can undermine the entire PKI's trust.

Enterprise CA

An Enterprise CA is a type of Certificate Authority in AD CS that is integrated with Active Directory. This integration allows it to:

• Utilize AD for storing and distributing certificate templates.
• Publish issued certificates and Certificate Revocation Lists (CRLs) to AD for easy discovery by domain members.
• Leverage AD user and group information for controlling enrollment permissions on templates and for automatically populating subject information in certificates.
• Support certificate auto-enrollment for domain users and computers.

Enterprise CAs are typically online and issue certificates directly to end entities. Most AD CS attacks target Enterprise CAs due to their tight coupling with domain identities and authentication. In contrast, a Standalone CA operates without AD integration, requiring manual request submission and typically used for specific, often offline, scenarios.

Certificate Template

A Certificate Template is a predefined set of rules and settings, stored as an object in Active Directory, that governs the characteristics of certificates an Enterprise CA can issue. Templates dictate parameters such as:

• Permitted Usages: Extended Key Usages (EKUs) and Application Policies specifying what the certificate can be used for (e.g., client authentication, server authentication, code signing).
• Enrollment Permissions: ACLs defining which users, groups, or computers can request certificates based on this template.
• Subject Name Construction: How the subject and Subject Alternative Name (SAN) are populated (e.g., built from AD, supplied by requester).
• Issuance Requirements: Conditions like manager approval, authorized signatures (enrollment agent), or specific security device requirements.
• Cryptography: Key length, private key exportability, cryptographic service provider (CSP).
• Validity Period & Renewal: How long the certificate is valid and when renewal can occur.

Misconfigurations in certificate templates (e.g., allowing enrollee-supplied subjects for authentication templates, overly permissive enrollment rights, or weak issuance requirements) are the root cause of many AD CS vulnerabilities, such as ESC1, ESC2, ESC3, ESC9, ESC13, and ESC15. Template objects themselves have ACLs, and if these are weak, it can lead to ESC4 (Template Hijacking).

Certificate Signing Request (CSR)

A Certificate Signing Request (CSR) is a formal message sent from an applicant to a Certificate Authority to request a digital certificate. The CSR contains information that the CA will use to build the certificate, including:

• The applicant's public key.
• Identifying information for the applicant (e.g., intended subject name).
• Requested certificate extensions (like Key Usage, EKUs, SANs).

The CSR is digitally signed by the applicant using their corresponding private key. This signature proves to the CA that the applicant possesses the private key associated with the public key in the CSR. Upon receiving and validating the CSR against its policies (often defined by a certificate template), the CA issues and signs the actual certificate. Tools like Certipy generate CSRs as part of the certificate request process (certipy req). Attackers may attempt to manipulate CSR content, for example, by injecting arbitrary SANs (if permitted by ESC1 or ESC6) or malicious Application Policies (in ESC15).

Certificate Extensions

Certificate extensions are fields within an X.509 certificate that provide additional information about the certificate, its subject, its issuer, or its permitted uses. They are critical for defining a certificate's capabilities, constraints, and how it should be processed by relying parties. In AD CS and for certificate-based authentication, key extensions include:

• Key Usage (KU): A bitmask extension that defines the permitted cryptographic operations for the public key contained in the certificate (e.g., digitalSignature for signing data, keyEncipherment for encrypting keys, nonRepudiation). For authentication certificates, digitalSignature is typically required.
• Extended Key Usage (EKU) / Enhanced Key Usage: This extension, also known as Enhanced Key Usage, consists of one or more Object Identifiers (OIDs) that specify the intended applications or purposes of the certificate beyond the basic operations in the Key Usage extension. EKUs are crucial for AD CS attacks as they determine if a certificate can be used for client authentication, smart card logon, server authentication, or to act as an enrollment agent. (See separate EKU entry).
• Subject Alternative Name (SAN): Allows additional identity information to be bound to the certificate, such as User Principal Names (UPNs), DNS names, email addresses, or IP addresses. UPNs and DNS names in the SAN are commonly used for mapping certificates to Active Directory accounts during authentication. (See separate SAN entry).
• Application Policies (szOID_APPLICATION_CERT_POLICIES): A Microsoft-specific extension (OID 1.3.6.1.4.1.311.21.10) that is similar in function to EKU but can have stricter processing semantics in some Microsoft contexts. It also uses OIDs to define allowed applications. Misuse of this is central to ESC15.
• SID Extension (szOID_NTDS_CA_SECURITY_EXT): A Microsoft-specific extension (OID 1.3.6.1.4.1.311.25.2) introduced to combat certificate impersonation attacks by embedding the requester's Active Directory Security Identifier (SID) directly into the certificate. This enables "strong certificate mapping" where the KDC or Schannel can use this SID for unambiguous account mapping. Its absence or misconfiguration is key to ESC9 and ESC16.

Extended/Enhanced Key Usage (EKU)

The Extended Key Usage (EKU) extension (OID 2.5.29.37) in an X.509 certificate refines its purpose by specifying one or more OIDs that indicate allowed applications for the public key. EKUs are critical in AD CS because they dictate whether a certificate can be used for sensitive operations like authentication or acting as an enrollment agent. Common EKUs and their OIDs relevant to AD CS attacks include:

• Client Authentication: 1.3.6.1.5.5.7.3.2 - Allows the certificate to be used to authenticate a client to a server (e.g., for Kerberos PKINIT or Schannel TLS client auth). This is a prerequisite for most certificate-based logon attacks.
• Server Authentication: 1.3.6.1.5.5.7.3.1 - Allows the certificate to be used to authenticate a server to a client (e.g., for HTTPS/TLS web servers, LDAPS).
• Smart Card Logon: 1.3.6.1.4.1.311.20.2.2 - Specifically indicates the certificate can be used for interactive smart card logon to Windows.
• Certificate Request Agent (Enrollment Agent): 1.3.6.1.4.1.311.20.2.1 - Allows the holder of this certificate to request certificates on behalf of other users. Abused in ESC3.
• Any Purpose: 2.5.29.37.0 (This is actually the OID for the EKU extension itself when it contains "Any Purpose") or if the EKU extension is present but has no OIDs, or sometimes if the EKU extension is entirely absent (especially in V1 templates). This allows the certificate to be used for any purpose, including implicitly all others like Client Authentication and Certificate Request Agent. Abused in ESC2.

The presence or absence of specific EKUs, or the overly permissive "Any Purpose" EKU, on an enrollable template are central to many ESCx vulnerabilities. In Windows environments, the Application Policies extension often serves a similar function and its OIDs can be processed by applications as if they were EKUs.

Subject Alternative Name (SAN)

The Subject Alternative Name (SAN) extension (OID 2.5.29.17) allows various additional identities to be bound to the subject of a certificate, supplementing or replacing the information in the certificate's Subject field. Common SAN entry types include DNS names (for servers), User Principal Names (UPNs) for users, RFC822 Names (email addresses), and IP addresses.

In Active Directory certificate-based authentication, the UPN value present in a certificate's SAN is a primary identifier used by the KDC (for Kerberos PKINIT) and Schannel to map the certificate to a user account in AD. If an attacker can control the SAN contents of a certificate request (e.g., due to an ESC1 or ESC6 misconfiguration) and inject the UPN of a privileged user, they can obtain a certificate that allows them to impersonate that user. More recently, a specific SAN URL format (URL=tag:microsoft.com,2022-09-14:sid:<VALUE>) can be used to embed a SID, which is relevant for ESC6+ESC9/ESC16 attacks.

Note:
Fully patched environments prioritize the SID Extension (szOID_NTDS_CA_SECURITY_EXT) for mapping if present. If the SID extension is absent, the KDC/Schannel may fall back to SAN UPNs or other methods, depending on configuration (see ESC9, ESC16, and DC strong mapping settings). For more information, refer to the Resources section.

altSecurityIdentities

The altSecurityIdentities attribute is a multi-valued attribute on Active Directory user or computer objects that allows administrators to manually create explicit mappings between X.509 certificates and an AD account. These mappings can override the default implicit mapping logic (which uses SAN UPNs or the SID extension). The attribute supports various string formats to specify certificate characteristics, such as X509:<I>IssuerDN<S>SubjectDN (full issuer and subject), X509:<SKI>SubjectKeyIdentifier, or X509:<RFC822>EmailAddress.

If these explicit mappings are configured weakly (e.g., relying only on a common Subject CN like X509:<S>CN=AdminUser), they can be susceptible to misuse (ESC14). Attackers who gain write access to this attribute on a target account can add their own certificate mappings, effectively creating a backdoor to impersonate that user with a certificate they control.

msDS-KeyCredentialLink

The msDS-KeyCredentialLink attribute is a multi-valued attribute on AD user or computer objects used to store public key material (or references to it) for passwordless authentication methods like Windows Hello for Business (WHfB) and FIDO2 security keys. When a user attempts to authenticate using such a credential, the system presents a cryptographic proof tied to the private key, and AD validates it against the public key material linked via this attribute.

Attackers with write access to an account's msDS-KeyCredentialLink attribute can add their own public key material, creating what's known as "shadow credentials." This allows the attacker to subsequently authenticate as that user without needing their password, by using the corresponding private key they control. Certipy's shadow auto command can be used to exploit this if the necessary permissions are available. While distinct from AD CS certificate abuse, it's another form of key-based authentication bypass/persistence.

NTAuth Store

The NTAuth Store (also known as the NTAuthCertificates object) is a specific object located in the Active Directory Configuration Naming Context (CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=...). It holds the certificates of CAs that are trusted by the domain for issuing certificates used in client authentication (like smart card logon or Kerberos PKINIT). Enterprise CA root certificates and sometimes issuing CA certificates are typically published here automatically. By default, for Kerberos PKINIT, only certificates chaining up to a CA present in the NTAuth Store are accepted for domain authentication. Attackers with write permissions to this AD object (an ESC5 vector) might attempt to add a rogue CA certificate to make their own CA trusted for issuing logon certificates, thus enabling widespread impersonation.

Note:
Certificates from Subordinate CAs are not automatically trusted for domain logon just by being subordinate to a Root CA in NTAuth. For a Subordinate CA's issued certificates to be valid for domain logon, often the Subordinate CA's own certificate (or a cross-certificate) must also be in the NTAuth Store. However, Schannel authentication in some configurations might have different trust validation paths and could potentially trust certificates from a Subordinate CA if the full chain including a trusted root (from the machine's or user's trust store) is presented, even if the SubCA isn't explicitly in NTAuth.

Enrollment

Enrollment is the overall process by which an end entity (user, computer, or service) requests and obtains a digital certificate from a Certificate Authority. In an AD CS Enterprise CA environment, this process is typically governed by certificate templates. The "Enroll" and "Autoenroll" permissions defined in a template's ACL determine which principals are allowed to request certificates based on that template. Auto-enrollment is a feature that leverages Group Policy to automate the certificate enrollment and renewal process for domain members, allowing users or computers to automatically request and install certificates for specific templates without manual intervention. Misconfigured enrollment permissions are a cornerstone of many AD CS attacks, as they allow unintended users to obtain potentially abusable certificates.

Key Distribution Center (KDC)

The Key Distribution Center (KDC) is a critical network service that runs on every Active Directory Domain Controller. It is responsible for handling Kerberos authentication requests within an AD domain. Its primary functions include authenticating principals (users, computers, services) and issuing Kerberos tickets, namely Ticket Granting Tickets (TGTs) and service tickets (TGS). In the context of certificate-based authentication, the KDC implements the server-side logic for PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). When a user presents a certificate for logon, the KDC validates the certificate, maps it to an AD account (using the SID extension, SAN UPN, or other methods), and, if successful, issues a TGT. Changes in KDC behavior, particularly through security patches (like KB5014754 which introduced strong certificate mapping) or registry configurations (StrongCertificateBindingEnforcement), can significantly impact the viability of many AD CS-based attacks.

Schannel

Schannel (Secure Channel) is a Security Support Provider (SSP) in Windows that implements the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It is used to provide encrypted communications and certificate-based authentication for various applications and services, such as HTTPS for IIS web servers, LDAPS for secure LDAP communication with Domain Controllers, and RDP-TLS. Schannel performs its own certificate validation and account mapping process when a client presents a certificate for TLS authentication. While in some modern, well-configured scenarios, Schannel may defer aspects of account mapping to Kerberos mechanisms (or behave consistently), it has its own distinct mapping logic that can be configured via the registry (e.g., the CertificateMappingMethods key). Misconfigurations in Schannel's certificate mapping (e.g., allowing UPN-based mapping without sufficient validation) can lead to vulnerabilities like ESC10, even if Kerberos PKINIT is more strictly configured.

ESC (Escalation) Abuse Cases

ESC is a nomenclature that refers to "Escalation" abuse cases within Active Directory Certificate Services. This system of categorizing distinct AD CS misconfiguration attack scenarios was notably introduced and popularized by researchers at SpecterOps. These scenarios are typically labeled ESC1 through ESC16 (as of early 2025), with each number representing a specific type of misconfiguration or vulnerability pattern that can be exploited for privilege escalation, information disclosure, or persistence within an Active Directory environment. Certipy is a tool designed to help identify and, in many cases, exploit these ESC vulnerabilities.