Insights

Active Directory Certificate Services – Misconfigurations & Recommendations

Author:

Dan Dinculeana

Active Directory Certificate Services (AD CS) is Microsoft’s implementation of a Public Key Infrastructure (PKI) integrated with Active Directory. This technology enables the use of public key cryptography across the Active Directory forest, facilitating digital signatures, code signing, and the issuance of certificates, among other features.

An AD CS Certificate is an X.509 certificate that is issued and managed by Microsoft’s AD CS, which is a role within Windows Server used to create and manage PKI within an organisation. These certificates are employed for various purposes, including authentication, encryption, digital signatures, and secure communication within an Active Directory environment.

Key Fields in an AD CS Certificate

Version – Specifies the X.509 version (typically v3 for enhanced security features).
Serial Number – A unique identifier assigned by the AD CS Certificate Authority (CA).
Issuer – The AD CS CA that issued the certificate.
Subject – The entity to whom the certificate is issued (e.g., user, device, service).
Public Key – The public key used for encryption and signature verification.
Validity Period – Defines the certificate’s start and expiration dates.
Signature Algorithm – The cryptographic algorithm used to sign the certificate (e.g., SHA-256).
Certificate Templates – AD CS certificates are based on predefined templates that define certificate policies and settings.
Certificate Extensions (X.509 v3) – Includes specific attributes like Key Usage (e.g., encryption, digital signature), Enhanced Key Usage (e.g., Smart Card Logon, Server Authentication), and Subject Alternative Name (SAN).
Signature – The digital signature from the AD CS CA that verifies the certificate’s authenticity.

To request certificates, users go through a process known as enrolment. This involves clients identifying an Enterprise CA, generating a private and public key pair, and inserting the public key along with any relevant information into a Certificate Signing Request (CSR). The CSR is then signed with the user’s private key and sent to the Enterprise CA.

After receiving the CSR, the CA conducts checks based on the provided information, such as verifying the user’s permissions to request a specific certificate template and confirming if the user is authorised to enrol. If these checks are completed successfully, the CA uses the user-supplied information to fill in the certificate template, signs the certificate with its private key, and then sends the completed certificate back to the user.

Misconfigurations

Active Directory Certificate Services misconfigurations refer to improper settings, weak access controls, or insecure certificate policies that can be exploited by attackers to gain unauthorised access, escalate privileges, or impersonate users and devices within an Active Directory (AD) environment. These misconfigurations often arise due to mismanagement, lack of security best practices, or legacy configurations that expose the organisation to threats.

Common AD CS Misconfigurations and Their Causes

Overly Permissive Certificate Templates: Misconfigured certificate templates allow low privileged users to request certificates with elevated privileges (e.g., certificates with Client Authentication and Smart Card Logon). Attackers could obtain certificates that allow unauthorized authentication as privileged users.
Weak Enrolment Policies: Any authenticated user can enrol in sensitive certificate templates without proper access control restrictions. Attackers could request certificates that enable privilege escalation or persistence.
Misconfigured Certificate Authority (CA) Permissions: Poorly configured CA ACLs (Access Control Lists) allow unauthorised users to manage certificates, modify templates, or issue new certificates. Attackers could create fraudulent certificates or manipulate existing ones.
Unrestricted Enrolment Agent Templates: Enrolment Agents are allowed to request certificates on behalf of other users, but if unrestricted, any user can abuse this role. Attackers could generate certificates for privileged accounts, leading to full domain compromise.
Vulnerable NTLM and Kerberos Certificate Mappings: Weak mappings could allow attackers to use certificates for authentication without verifying identity properly. Enables pass-the-certificate attacks, where an attacker can authenticate as a high-privileged user.
Allowing Certificates with Weak or Deprecated Cryptography: Use of outdated cryptographic algorithms (e.g., MD5, SHA-1) or weak key sizes. Increases the risk of cryptographic attacks that compromise certificate integrity.
Lack of Certificate Revocation Checking: Improper configuration of CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol). Expired or compromised certificates remain valid, allowing continued misuse.

How These Misconfigurations Occur

Default or Legacy Configurations left unchanged after AD CS deployment.
Lack of Awareness among administrators regarding certificate-based attack vectors.
Over-permissive policies granting unnecessary certificate enrolment rights.
Failure to implement least privilege and restrict sensitive templates.
Poor auditing and monitoring of issued certificates and CA activities.

While there are a number of vulnerabilities in the ESC, THEFT or PERSIST categories [1], that can affect AD CS, the focus of the article will be on privilege escalation, more specifically, ESC1, ESC2, ESC3, ESC4 & ESC6 misconfigurations.

Lab Setup

In order to demonstrate some of these misconfigurations and how these impact security of an Active Directory forest, an environment was deployed. This was based on the Game of Active Directory (GoAD v3) project [2].

The environment consists of three domain controllers (DC01, DC02, DC03) and two servers (SRV02, SRV03). We’ll be investigating D03 (192.168.56.12) and specifically SRV03 (ESSOS-CA / 192.168.56.23) to see if any misconfigurations exist.

Additionally, a previously compromised user account (khal.drogo@essos.local) will serve as an entry point and will be used to perform enumeration in the following section.

ESC1

For the certificate template to be vulnerable to ESC1, the following properties must exist in the template:

The Enterprise CA grants low-privileged users enrolment rights.
Manager approval is disabled.
No authorised signatures are required.
An overly permissive certificate template security descriptor grants certificate enrolment rights to low-privileged users.
The certificate template defines Extended Key Usages (EKUs) that enable authentication.
The certificate template allows requesters to specify a subjectAltName (SAN) in the CSR.

So, first aspect is to enumerate certificate templates and review their parameters. The Certipy tool [3] can be used to find vulnerable certificate templates, by supplying valid domain user credentials or running the tool from a domain-attached computer.

certipy find -u khal.drogo@essos.local -p horse -vulnerable -dc-ip 192.168.56.12 -stdout

One of the templates returned (also called ESC1), shows that the template assigns low privileged domain users enrolment rights (6), allows users to specify a Subject Alternate Name (2), does not require manager approval (4), does not require an authorised signature (5), and can be used for client authentication (1, 3).

A Subject Alternative Name (SAN) is an X.509v3 extension. When inserted into a certificate, it allows additional identities to be bound to a certificate beyond just the subject of the certificate.

From an administrator’s perspective, opening the Certificate Service Template it was seen that the Subject Name property of the ESC1 template was set to “Supply in the request”:

If a requester can specify the SAN in a Certificate Signing Request, they can request a certificate impersonating anyone in the domain (for example, a domain admin).

Before we can request a certificate, we need to identify a domain admin. So, in that sense, we can use the same credentials of our compromised user to enumerate users and groups using the rpcclient tool:

Now, let’s identify which user is part of the “Domain Admins” group using NetExec:

nxc ldap 192.168.56.12 -u khal.drogo -p horse -M group-mem -o GROUP="Domain Admins"

In the next step we’ll request a certificate and supply the chosen admin’s UPN:

certipy req -u khal.drogo@essos.local -p horse -target braavos.essos.local -template ESC1 -ca ESSOS-CA -upn daenerys.targaryen@essos.local

This command was successful and retrieved a certificate for the domain admin “daenerys.targaryen@essos.local”, which can be used for authentication in the next step.

certipy auth -pfx daenerys.targaryen.pfx -dc-ip 192.168.56.12

The command will acquire a Kerberos ticket and return the NT hash of the admin user. The previously obtained Kerberos ticket saved in “daenerys.targaryen.ccache” could be further used to retrieve all secrets (SAM hashes, LSA, DPAPI, domain credentials and Kerberos keys) from DC03 using the secretsdump script:

As a consideration, let’s test what would happen if “Manager Approval” was enabled. This is shown below by opening the properties of the ESC1 template as an administrator:

This would prevent the CA from issuing a certificate before it has been approved by an administrator. In theory, this would prevent the certificate from being issued and may even serve as an indication of compromise that could be investigated. However, in practice, depending on the number of users in a group assigned enrolment rights, this may not be feasible to have an administrator approve large number of certificate requests.

Just as an example, let’s run through the same exploit again:

This action will appear as a pending request and would now be visible to an administrator accessing the “certsrv” MMC snap-in:

Additionally, changing the “Subject Name” property to “Build from this Active Directory information” constructed with the UPN option selected, would not allow the enrolled users to request certificates with a different UPN other than their own.

ESC2 & ESC3

ESC2 and ESC3 are similar issues, the templates can be used for Any Purpose (as this setting is Enabled). ESC3 also contains “Certificate Request Agent” Extended Key Usage set.

The following properties need to be set in order for the templates to be vulnerable:

ESC2

The Enterprise CA grants low-privileged users enrolment rights. Details are the same as in ESC1.
Manager approval is disabled. Details are the same as in ESC1.
No authorized signatures are required. Details are the same as in ESC1.
An overly permissive certificate template security descriptor grants certificate enrolment rights to low-privileged users. Details are the same as in ESC1.
The certificate template defines Any Purpose EKUs or no EKU.

ESC3

The Enterprise CA grants low-privileged users enrolment rights. Details are the same as in ESC1.
Manager approval is disabled. Details are the same as in ESC1.
No authorized signatures are required. Details are the same as in ESC1.
An overly permissive certificate template security descriptor grants certificate enrolment rights to low-privileged users. Details are the same as in ESC1.
The certificate template defines the Certificate Request Agent EKU. The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf of other principals.
Enrolment agent restrictions are not implemented on the CA.

Both issues can be exploited by first issuing a request without a UPN on a vulnerable template, to obtain a certificate for the compromised user first:

Then we can request a certificate against the User template with the khal.drogo.pfx certificate, on behalf of essos\daenerys.targaryen:

Once this is obtained, further exploitation is possible following the same steps as seen in ESC1.

ESC4

Certificate templates have a security descriptor that dictates which principals have permissions over the template. Therefore, if a template has weak access control this could allow an attacker with a low privileged account to modify template settings and escalate their privileges.

The Certipy output previously obtained showed that khal.drogo has “Full Control” over the ESC4 object:

Additionally, with the Bloodhound [4] graph information exported with Certipy at a previous step, we can inspect if there are any principals with permissions over the ESC4 template.

With the ESC4 object selected, the shortest path option was chosen in Bloodhound. This revealed that khal.drogo@essos.local has GenericAll permissions over ESC4.

These permissions can be used to update the template and make it vulnerable to ESC1:

Now, with the template updated we can use the same commands seen in ESC1 for obtaining a certificate and then the Kerberos ticket for further exploitation:

ESC6

If a CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag set, it could allow a low privileged user to request a certificate on any templates which allow client authentication and supply an arbitrary SAN in the CSR request. This can occur even if the templates are configured to not allow a user-supplied SAN!

First, let’s identify if a CA exists with this setting configured:

As shown above, ESSOS-CA has “User Specified SAN” and “Request Disposition” settings enabled.

If we run certutil on the CA, the information related to policy, and this flag in particular, can be retrieved:

Having this setting enabled allows SAN information to be included as a “Request Attribute”.

For this example, the User template will be chosen. By opening the properties of this template as an administrator, it can be seen that the User template does not allow a user-supplied Subject Name:

In a similar manner to exploiting ESC1, we can issue a request with our own supplied UPN, however requesting this on the User template instead:

Once the Kerberos ticket is obtained further attacks could be performed, such as a DCsync and extracting user hashes, as shown in ESC1.

Note that on a fully patched server, ESC6 will no longer work on its own. However, this can still be abused if present in conjunction with the ESC10 misconfiguration (Weak Certificate Mappings) [5].

Conclusion

The article presented a number of misconfigurations affecting AD CS that could lead to full domain compromise and attempted to show the impact of what these could cause if an attacker would have even limited internal domain access. It is important to note that CAs should be considered as important as domain controllers and should be secured appropriately [1].

While there are many other misconfiguration or vulnerabilities that can affects AD CS, the Certified Pre-Owned whitepaper [1] provides a more in-depth analysis of these and how a system administrator can better implement detections in their environment.

Recommendations

Harden certificate template settings so that users cannot supply a custom SAN with their certificate request. Consider enforcing strict certificate mapping on a domain controller. This can be achieved by setting a DWORD key “UseSubjectAltName” set to 0 in the following registry:

HKLM\SYSTEM\CurrentControlSet\Services\Kdc

Review access control on templates and ensure overly permissive rights for each user group are removed. Additionally, all templates that do not have a specific reason for being published should be removed.
Harden CA settings, specifically ensure that “EDITF_ATTRIBUTESUBJECTALTNAME2” flag is not set. This can be done using certutil on the CA:

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

The next aspect is to restart the “certsvc” service.

Additionally, ensure that permissions on the CAs are reviewed and that no unprivileged user groups or accounts are assigned “Manage CA” and “Manage Certificates” permissions.

Consider enabling “Manager Approval” on certificate templates as this will ensure that all certificate requests need to be approved before the CA will send back a certificate to the requesting entity.
If enrolment agents are required within the environment, restrict which principals can act as enrolment agents and which users and certificate templates agents are allowed to enrol on behalf of.
The only way to ensure your Active Directory Certificate Service security measures are robust is to put them to the test, and that’s exactly what our infrastructure testing is designed to do. So, if you’re worried about the security of your Active Directory Certificate Services, why not get in touch and see how our testing can be utilised to provide you, and your organisation, with the security assurances you need.