Active Directory Certificate Services (AD CS) is a Windows Server role for issuing and managing Public Key Infrastructure (PKI) certificates used in secure communication and authentication protocols.

In the last few years, a number of possible AD CS misconfigurations, leading to privilege escalation and persistence in an Active Directory environment, have been published by security researchers and exploited by threat actors.

Active Directory objects linked to AD CS

A number of Active Directory objects, stored in the Configuration naming context, are related to Active Directory Certificate Services (and potentially third-party Certification Authority). As any objects stored in the Configuration naming context, the objects are replicated on all the Domain Controllers forest-wide.

Name Path Description
NTAuthCertificates CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,<DOMAIN> The NTAuthCertificates store, also known as the Enterprise NTAuth store store, hold the certificate of the trusted Certificate Authorities (in the cACertificate attribute).
Enrollment Services CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,<DOMAIN>  
Certificate Authority CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,<DOMAIN>  
Certificate Templates CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,<DOMAIN> Container holding the certificate templates defined in the domain, whether they are enabled in a Certificate Authority or not.
CDP CN=<CA_NAME>,CN=<ADCS_SERVER>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,<DOMAIN> Container storing the Certificate Revocation Lists (CRL), with one separate container per CA and each CA thus having its own CRL.

Certificate templates overview

Certificate templates are domain objects of type pKICertificateTemplate, stored under the CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<TLD> container, that govern the certificates that can be requested to and delivered by the Active Directory Certificate Services (AD CS).

A certificate template notably defines a number of parameters for the certificates issued through the template:

  • The way the Subject Name and Subject Alternative Name (Subject Alternative Name) of the certificates will be constructed. The subject information can be either build:

    • automatically based on Active Directory information of the principal making the request (User Principal Name (UPN), Service Principal Name (SPN), DNS name, etc.).

    • using user-supplied data provided in the certificate request. In such case, the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x1) in the msPKI-Certificate-Name-Flag attribute is set (and the attribute thus has an odd value).

  • The issued certificates validity period.

  • The cryptographic parameters of the certificates (the Cryptographic Services Provider (CSP) and the minimum key size used for instance).

  • The X509v3 extensions added to the certificates, including the Extended / Enhanced Key Usage (EKU) extension (introduced in more details below). The extensions define the purpose of the certificates.

  • Eventual issuance requirements:
    • Approval of a certificate manager to validate (or deny) the certificate request. This setting will set the CT_FLAG_PEND_ALL_REQUESTS (0x02) flag in the certificate template msPKI-Enrollment-Flag attribute. Certificate requests will be keep in a pending state, awaiting for action of the certificate manager.

Additionally, certificate templates are securable objects, and the access control rights defined in a certificate template’s Access Control List (ACL) govern the operations that can be conducted on the template itself and the principals that can enroll to the template. Refer to the [Active Directory] ACL exploiting - Active Directory Certificate Services note for more information on the certificate templates ACL.

Extended / Enhanced Key Usage extension

The Extended / Enhanced Key Usage (EKU) extension is a certificate extension (i.e an additional attribute) that defines the purposes of the certificate, effectively restricting what the certificate can be used for in an Active Directory environment. This extension is implemented by the pKIExtendedKeyUsage attribute on Active Directory certificate template object.

The EKU extension is composed of 0 or more Object Identifier (OID), each OID corresponding to a specific purpose. The following notable OIDs are supported in Active Directory:

OID Name / Description Usage Allow AD authentication
2.5.29.37.0 anyExtendedKeyUsage Certificate that can be used for any usage. Yes.
1.3.6.1.5.5.7.3.2 clientAuth Certificate used for client authentication (be it SSL / TLS authentication for web client or to remote servers in Active Directory). Yes.
1.3.6.1.5.5.7.3.3 codeSigning Code signing certificate used to digitally sign executables (such as PE binaries or PowerShell scripts). No.
1.3.6.1.5.5.7.3.4 emailProtection Certificate used to encrypt or digitally sign emails through the S/MIME standard. No.
1.3.6.1.5.5.7.3.5
1.3.6.1.5.5.7.3.6
1.3.6.1.5.5.7.3.7		 ipsecEndSystem
ipsecTunnel
ipsecUser		 Certificates used in an Internet Protocol SECurity (IPSEC) infrastructure. No.
1.3.6.1.5.2.3.4 keyPurposeClientAuth Certificate used in Active Directory for PKINIT client authentication (not present by default and requires to be manually added in the certificate template). Yes.
1.3.6.1.4.1.311.10.3.4 msEFS Certificate used to encrypt / decrypt Encrypting File System (EFS) NTFS filesystems on Windows. No.
1.3.6.1.5.5.7.3.1 serverAuth Certificate used for server authentication (for instance using the SSL / TLS protocol). No.
1.3.6.1.4.1.311.20.2.2 Smartcard logon Certificate used for smart card logon. Yes.

If no OID is specified in the EKU extension, the certificate will by default be valid for all usages in Windows, including client authentication. Applications may however rely on the Constrained EKU validation mode, as implemented by Microsoft, which determine the valid usage of the certificate using only the explicitly specified purposes (in all the certificate of the chain).

Arbitrary / user-controlled Subject Alternative Name (ESC1)

As specified in the certificate processing logic in the Microsoft documentation, if an User Principal Name (UPN) is specified in a certificate’s subjectAltName field, the UPN is used to map the certificate to an user account in Active Directory and conduct the PKINIT authentication as that user. Having control on the Subject Alternative Name for which the certificate will be emitted can thus be leveraged for privilege escalation, notably if the certificate template supports client authentication (and can be requested under the current privileges). For example, in such circumstances, an unprivileged user could request a certificate specifying a more privileged principal, such as the domain Administrator account or a member of the Domain Admins group, and later use the certificate to authenticate under the impersonated principal.

The Subject Alternative Name for which the certificate will be emitted is user-controlled if either:

  • The specific certificate template is configured to use user-supplied data provided in the certificate request to define the subjectAltName (i.e, as noted above, the template msPKI-Certificate-Name-Flag attribute’s CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x1) flag is set).

  • A Certificate Authority server has, in its HKEY_LOCAL_MACHINE registry hive, the EDITF_ATTRIBUTESUBJECTALTNAME2 (0x00040000) flag set. As stated in the Microsoft documentation, if this flag is set, user-supplied alternative names are allowed for any certificate template published by the given Certificate Authority server.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags

Enrollment rights

To enroll for a certificate template, the following conditions must be meet:

  • The certificate template must be published by at least one Certificate Authority. The certificate templates published by a given CA are defined in the certificateTemplates attribute of the CA’s Enrollment Service (pKIEnrollmentService) object.

  • The given principal must be able to enroll to a CA publishing the certificate template (Certificate-Enrollment or Certificate-AutoEnrollment extended rights).

  • The given principal must have enrollment rights for the certificate template. The enrollment rights are defined on the certificate template object’s ACL (notably the Certificate-Enrollment or Certificate-AutoEnrollment rights).

Certificate templates enumeration

Multiple tools and utilities can be used to enumerate the certificate templates:

Additionally, FarsightAD can be used to enumerate certificate templates and retrieve timestamps of last modification for critical attributes (msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag, nTSecurityDescriptor).

# Requires PowerShell 7+.

. .\FarsightAD.ps1

Export-ADHuntingADCSCertificateTemplates [-Server <DC_IP | DC_HOSTNAME>] [-Credential <PS_CREDENTIAL>] [-ADDriveName <AD_DRIVE_NAME>] [-OutputFolder <OUTPUT_FOLDER>] [-ExportType <CSV | JSON>]

References

Tags: windows_active_directory

View on GitHub