ad-certificates.md (15570B)
1 --- 2 title: "AD Certificates" 3 section: "Windows" 4 sectionSlug: "windows-hardening" 5 sourcePath: "src/windows-hardening/active-directory-methodology/ad-certificates.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/windows-hardening/active-directory-methodology/ad-certificates.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # AD Certificates 14 15 ## Introduction 16 17 ### Components of a Certificate 18 19 - The **Subject** of the certificate denotes its owner. 20 - A **Public Key** is paired with a privately held key to link the certificate to its rightful owner. 21 - The **Validity Period**, defined by **NotBefore** and **NotAfter** dates, marks the certificate's effective duration. 22 - A unique **Serial Number**, provided by the Certificate Authority (CA), identifies each certificate. 23 - The **Issuer** refers to the CA that has issued the certificate. 24 - **SubjectAlternativeName** allows for additional names for the subject, enhancing identification flexibility. 25 - **Basic Constraints** identify if the certificate is for a CA or an end entity and define usage restrictions. 26 - **Extended Key Usages (EKUs)** delineate the certificate's specific purposes, like code signing or email encryption, through Object Identifiers (OIDs). 27 - The **Signature Algorithm** specifies the method for signing the certificate. 28 - The **Signature**, created with the issuer's private key, guarantees the certificate's authenticity.<sup>[[4]](#references)</sup> 29 30 ### Special Considerations 31 32 - **Subject Alternative Names (SANs)** expand a certificate's applicability to multiple identities, crucial for servers with multiple domains. Secure issuance processes are vital to avoid impersonation risks by attackers manipulating the SAN specification.<sup>[[4]](#references)</sup> 33 34 ### Certificate Authorities (CAs) in Active Directory (AD) 35 36 AD CS acknowledges CA certificates in an AD forest through designated containers, each serving unique roles:<sup>[[4]](#references)</sup> 37 38 - **Certification Authorities** container holds trusted root CA certificates. 39 - **Enrolment Services** container details Enterprise CAs and their certificate templates. 40 - **NTAuthCertificates** object includes CA certificates authorized for AD authentication. 41 - **AIA (Authority Information Access)** container facilitates certificate chain validation with intermediate and cross CA certificates. 42 43 ### Certificate Acquisition: Client Certificate Request Flow 44 45 1. The request process begins with clients finding an Enterprise CA. 46 2. A CSR is created, containing a public key and other details, after generating a public-private key pair. 47 3. The CA assesses the CSR against available certificate templates, issuing the certificate based on the template's permissions. 48 4. Upon approval, the CA signs the certificate with its private key and returns it to the client.<sup>[[4]](#references)</sup> 49 50 ### Certificate Templates 51 52 Defined within AD, these templates outline the settings and permissions for issuing certificates, including permitted EKUs and enrollment or modification rights, critical for managing access to certificate services.<sup>[[4]](#references)</sup> 53 54 **Template schema version matters.** Legacy **v1** templates (for example, the built-in **WebServer** template) lack several modern enforcement knobs. The **ESC15/EKUwu** research showed that on **v1 templates**, a requester can embed **Application Policies/EKUs** in the CSR that are **preferred over** the template's configured EKUs, enabling client-auth, enrollment agent, or code-signing certificates with only enrollment rights. Prefer **v2/v3 templates**, remove or supersede v1 defaults, and tightly scope EKUs to the intended purpose.<sup>[[1]](#references)</sup> 55 56 ## Certificate Enrollment 57 58 The enrollment process for certificates is initiated by an administrator who **creates a certificate template**, which is then **published** by an Enterprise Certificate Authority (CA). This makes the template available for client enrollment, a step achieved by adding the template's name to the `certificatetemplates` field of an Active Directory object.<sup>[[4]](#references)</sup> 59 60 For a client to request a certificate, **enrollment rights** must be granted. These rights are defined by security descriptors on the certificate template and the Enterprise CA itself. Permissions must be granted in both locations for a request to be successful. 61 62 ### Template Enrollment Rights 63 64 These rights are specified through Access Control Entries (ACEs), detailing permissions like: 65 66 - **Certificate-Enrollment** and **Certificate-AutoEnrollment** rights, each associated with specific GUIDs. 67 - **ExtendedRights**, allowing all extended permissions. 68 - **FullControl/GenericAll**, providing complete control over the template. 69 70 ### Enterprise CA Enrollment Rights 71 72 The CA's rights are outlined in its security descriptor, accessible via the Certificate Authority management console. Some settings even allow low-privileged users remote access, which could be a security concern. 73 74 ### Additional Issuance Controls 75 76 Certain controls may apply, such as: 77 78 - **Manager Approval**: Places requests in a pending state until approved by a certificate manager. 79 - **Enrolment Agents and Authorized Signatures**: Specify the number of required signatures on a CSR and the necessary Application Policy OIDs. 80 81 ### Methods to Request Certificates 82 83 Certificates can be requested through: 84 85 1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), using DCOM interfaces. 86 2. **ICertPassage Remote Protocol** (MS-ICPR), through named pipes or TCP/IP. 87 3. The **certificate enrollment web interface**, with the Certificate Authority Web Enrollment role installed. 88 4. The **Certificate Enrollment Service** (CES), in conjunction with the Certificate Enrollment Policy (CEP) service. 89 5. The **Network Device Enrollment Service** (NDES) for network devices, using the Simple Certificate Enrollment Protocol (SCEP). 90 91 Windows users can also request certificates via the GUI (`certmgr.msc` or `certlm.msc`) or command-line tools (`certreq.exe` or PowerShell's `Get-Certificate` command). 92 93 ```bash 94 # Example of requesting a certificate using PowerShell 95 Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" 96 ``` 97 98 ## Certificate Authentication 99 100 Active Directory (AD) supports certificate authentication, primarily utilizing **Kerberos** and **Secure Channel (Schannel)** protocols. 101 102 ### Kerberos Authentication Process 103 104 In the Kerberos authentication process, a user's request for a Ticket Granting Ticket (TGT) is signed using the **private key** of the user's certificate. This request undergoes several validations by the domain controller, including the certificate's **validity**, **path**, and **revocation status**. Validations also include verifying that the certificate comes from a trusted source and confirming the issuer's presence in the **NTAUTH certificate store**. Successful validations result in the issuance of a TGT. The **`NTAuthCertificates`** object in AD, found at: 105 106 ```bash 107 CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com> 108 ``` 109 110 is central to establishing trust for certificate authentication.<sup>[[4]](#references)</sup> 111 112 Since the **KB5014754** rollout, modern Kerberos certificate auth is mostly about **mapping strength**, not just EKUs.<sup>[[2]](#references)</sup> In hardened forests: 113 114 - A certificate that only carries a **UPN/DNS SAN** may no longer be enough for logon. 115 - The KDC prefers a **strong binding**, typically the **SID security extension** (`1.3.6.1.4.1.311.25.2`) or a strong explicit mapping in `altSecurityIdentities`. 116 - If the cert lacks a strong mapping, DCs log **Kdcsvc Event ID 39/41** in compatibility mode and deny auth in enforcement mode. 117 - In mixed attack paths, **ESC9/ESC16** matter because they strip the SID extension from issued certs; operators then rely on explicit mappings or SAN URL SID formats where the attack path supports them. 118 119 ### Secure Channel (Schannel) Authentication 120 121 Schannel facilitates secure TLS/SSL connections, where during a handshake, the client presents a certificate that, if successfully validated, authorizes access. The mapping of a certificate to an AD account may involve Kerberos’s **S4U2Self** function or the certificate’s **Subject Alternative Name (SAN)**, among other methods.<sup>[[4]](#references)</sup> 122 123 Schannel is also the practical fallback when **PKINIT** is unavailable. For example, if a domain controller does not have a suitable **Smart Card Logon** certificate, `certipy auth`/PKINIT tooling may fail to get a TGT, but the same certificate can still be usable against **LDAPS** or **LDAP StartTLS** for authentication and LDAP operations. 124 125 ### AD Certificate Services Enumeration 126 127 AD's certificate services can be enumerated through LDAP queries, revealing information about **Enterprise Certificate Authorities (CAs)** and their configurations. This is accessible by any domain-authenticated user without special privileges. Tools like **[Certify](https://github.com/GhostPack/Certify)** and **[Certipy](https://github.com/ly4k/Certipy)** are used for enumeration and vulnerability assessment in AD CS environments. 128 129 Commands for using these tools include: 130 131 ```bash 132 # Enumerate trusted root CA certificates, Enterprise CAs, and web endpoints 133 Certify.exe cas 134 135 # Identify vulnerable templates and dump relevant permissions 136 Certify.exe find /vulnerable 137 Certify.exe find /showAllPermissions 138 Certify.exe pkiobjects /showAdmins 139 140 # Certipy 5.x enumeration focused on enabled/vulnerable templates 141 certipy find -enabled -vulnerable -hide-admins -u john@corp.local -p Passw0rd -dc-ip 10.10.10.10 142 143 # Save JSON/CSV output for offline review or BloodHound correlation 144 certipy find -json -output corp_adcs -u john@corp.local -p Passw0rd -dc-ip 10.10.10.10 145 146 # Request a certificate over the Web Enrollment endpoint or DCOM/RPC 147 certipy req -web -ca corp-CA -target ca.corp.local -template WebServer -upn john@corp.local -dns www.corp.local 148 certipy req -ca corp-CA -target ca.corp.local -template User -upn administrator@corp.local -sid S-1-5-21-...-500 149 150 # Use the issued certificate either for PKINIT or directly for LDAP Schannel auth 151 certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10 152 certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10 -ldap-shell 153 154 # Enumerate Enterprise CAs and certificate templates with certutil 155 certutil.exe -TCAInfo 156 certutil -v -dstemplate 157 ``` 158 159 [Domain Escalation](/hacktricks/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation) 160 161 --- 162 163 ## Recent Vulnerabilities & Security Updates (2022-2025) 164 165 | Year | ID / Name | Impact | Key Take-aways | 166 |------|-----------|--------|----------------| 167 | 2022 | **CVE-2022-26923** – “Certifried” / ESC6 | *Privilege escalation* by spoofing machine account certificates during PKINIT. | Patch is included in the **May 10 2022** security updates. Auditing & strong-mapping controls were introduced via **KB5014754**; environments should now be in *Full Enforcement* mode. | 168 | 2023 | **CVE-2023-35350 / 35351** | *Remote code-execution* in the AD CS Web Enrollment (certsrv) and CES roles. | Public PoCs are limited, but the vulnerable IIS components are often exposed internally. Patch as of **July 2023** Patch Tuesday. | 169 | 2024 | **CVE-2024-49019** – “EKUwu” / ESC15 | On **v1 templates**, a requester with enrollment rights can embed **Application Policies/EKUs** in the CSR that are preferred over the template EKUs, producing client-auth, enrollment agent, or code-signing certificates. | Patched as of **November 12, 2024**. Replace or supersede v1 templates (e.g., default WebServer), restrict EKUs to intent, and limit enrollment rights. | 170 171 ### Microsoft hardening timeline (KB5014754) 172 173 Microsoft introduced a three-phase rollout (Compatibility → Audit → Enforcement) to move Kerberos certificate authentication away from weak implicit mappings. As of **February 11, 2025**, domain controllers automatically switch to **Full Enforcement** if the `StrongCertificateBindingEnforcement` registry value is not set. Microsoft later updated the timeline so fallback to compatibility mode remains possible until the **September 9, 2025** security update.<sup>[[2]](#references)</sup> Administrators should: 174 175 1. Patch all DCs & AD CS servers (May 2022 or later). 176 2. Monitor Event ID 39/41 for weak mappings during the *Audit* phase. 177 3. Re-issue client-auth certificates with the new **SID extension** or configure strong manual mappings before enforcement blocks weak mappings. 178 179 ### Operator notes for hardened forests 180 181 - **ESC1/ESC6 alone is no longer the whole story** in 2025+ environments. If you request a cert for another principal, you usually also need a strong mapping artifact such as the SID extension or an explicit mapping. 182 - **ESC15 (EKUwu)** is mostly valuable in unpatched environments because it turns harmless **v1** templates such as **WebServer** into authentication- or enrollment-agent-capable certs by injecting **Application Policies**. Kerberos PKINIT still evaluates EKUs, but **LDAP Schannel** also honors Application Policies, which keeps LDAP-based abuse relevant.<sup>[[1]](#references)</sup> 183 - **ESC16** is a CA-wide knob: if the CA disables the SID security extension globally, every issued certificate falls back toward weaker mapping behavior unless the attack chain injects a SID by another supported format. 184 185 --- 186 187 ## Detection & Hardening Enhancements 188 189 * **Defender for Identity AD CS sensor (2023-2024)** now surfaces posture assessments for ESC1-ESC8/ESC11 and generates real-time alerts such as *“Domain-controller certificate issuance for a non-DC”* (ESC8) and *“Prevent Certificate Enrollment with arbitrary Application Policies”* (ESC15). Ensure sensors are deployed to all AD CS servers to benefit from these detections.<sup>[[3]](#references)</sup> 190 * Disable or tightly scope the **“Supply in the request”** option on all templates; prefer explicitly defined SAN/EKU values. 191 * Remove **Any Purpose** or **No EKU** from templates unless absolutely required (addresses ESC2 scenarios). 192 * Require **manager approval** or dedicated Enrollment Agent workflows for sensitive templates (e.g., WebServer / CodeSigning). 193 * Restrict web enrollment (`certsrv`) and CES/NDES endpoints to trusted networks or behind client-certificate authentication. 194 * Enforce RPC enrollment encryption (`certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST`) to mitigate ESC11 (RPC relay). The flag is **on by default**, but is often disabled for legacy clients, which re-opens relay risk. 195 * Secure **IIS-based enrollment endpoints** (CES/Certsrv): disable NTLM where possible or require HTTPS + Extended Protection to block ESC8 relays. 196 197 --- 198 199 ## References 200 201 - [1] [EKUwu: Not just another AD CS ESC](https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc) 202 - [2] [KB5014754: Certificate-based authentication changes on Windows domain controllers](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) 203 - [3] [Certificates security posture assessments - Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/certificates) 204 - [4] [Certified Pre-Owned: Abusing Active Directory Certificate Services](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)