Active DirectoryAD CSMay 8, 2024Abusing AD CS Certificate Template – ESC1, ESC2, ESC3

Understanding Active Directory Certificate Services (AD CS)

AD CS is a server role integral to Microsoft’s public key infrastructure (PKI) implementation. It tightly integrates with Active Directory and facilitates the issuance of X.509-formatted digitally signed electronic documents, known as certificates. In this blog, we’ll delve into the key functionalities of AD CS, explore its role in establishing a secure PKI infrastructure, discuss certificate management best practices, and examine practical use cases for leveraging AD CS within Microsoft environments.

Functionality of Certificates
Certificates serve various purposes such as encryption, message signing, and authentication. Certificates provide identification of individuals through public/private key pairs that applications can use as proof of their identities.  

Role of Certificate Authorities (CAs)

Certificate Authorities (CAs) are responsible for issuing certificates. They play a crucial role in verifying the authenticity of the entities requesting the certificates.

Certificate Issuance Process

At a high level, the certificate issuance process involves the following steps:

• Clients generate a public-private key pair.
• Certificate Signing Request (CSR) contains the public key along with other details related to the subject and template name for a certificate. 
• CSRs are then submitted to an Enterprise CA server. Once attained, this server verifies both client eligibility for certificates as well as permissions of certificate templates specified within CSRs. 
• If the client meets all eligibility requirements and the template’s permissions allow, the CA will generate a certificate based on settings defined by its certificate template. Once signed with its private key, this certificate will then be distributed back to them client. 

This process ensures secure and controlled certificate issuance within the network, enhancing system security and integrity.

Refer to the below diagram for better understanding:

Certificate Templates and AD CS Enterprise CAs

AD CS Enterprise CAs issue certificates based on settings defined in AD objects known as certificate templates, which contain enrolment policies and predefined settings containing vital information needed to issue certificates such as: 

• Validity period of the certificate

• Intended usage of the certificate

• Specification of the subject

• Authorized entities for requesting a certificate

• Various other settings

EKU Object Identifiers and Certificate-Based Authentication

pKIExtendedKeyUsage on an AD certificate template object contains an array of object identifiers (OIDs). These Extended Key Usage object identifiers define which uses can be made of this certificate. Notably, certain EKU OIDs enable certificate-based authentication, including:

• Client Authentication OID (1.3.6.1.5.5.7.3.2)

• PKINIT Client Authentication OID (1.3.6.1.5.2.3.4), which is not present in AD CS deployments by default and requires manual addition, but does work for client authentication

Additional Settings and Issuance Requirements

In addition to EKU OIDs, templates encompass various other settings, which are further explored in detail in the Certified Pre-Owned whitepaper. The paper also delves into template “Issuance Requirements” that serve as preventive controls, a topic that will be briefly touched upon in this whitepaper.

Exploring ADCS Misconfigurations

The exploration of ADCS misconfigurations began with the release of SpecterOps’ influential White Paper titled “Certified Pre-Owned – Abusing Active Directory Certificate Services.” This paper delved into misconfigurations ranging from ESC1 to ESC8.

The Potential Risks and Attack Vectors

Certificate Abuse: A Gateway for Attackers

Active Directory’s Certificate Services (AD CS) offers attackers an avenue to gain unauthorized entry and escalate privileges within an Active Directory environment. By exploiting misconfigurations or vulnerabilities within AD CS, attackers could leverage certificates to fraudulently authenticate as any user or machine within an environment, giving them extensive privileges that compromise all domains within it. 

Common Misconfigurations in AD CS

AD CS can be vulnerable to various misconfigurations that could lead to privilege escalation and compromise, including giving low-privileged users enrolment rights, disabling manager approval, not requiring authorized signatures, and overly permissive certificate template security descriptors. Furthermore, errors related to certificate templates, subject alternative names, enrolment agent templates can enable attackers to request certificates without authorization from AD CS servers. 

Domain Escalation: A Serious Security Concern

One of the most significant risks associated with AD CS is domain escalation. Through various misconfigurations and vulnerabilities in AD CS, attackers can escalate their privileges within the domain and gain unauthorized access to sensitive resources. This can have severe consequences for the security and integrity of an organization’s infrastructure. 

Practical: Domain Escalation using ESC1

Understanding ESC1 Domain Escalation Scenario

The ESC1 (Escalation 1) scenario is the initial domain escalation scenario and is part of a collection of escalation scenarios that exploit misconfigured AD CS certificate templates.

Misconfiguration in ESC1

The primary misconfiguration in this domain escalation scenario involves “Client Authentication” EKU and the ability to specify an alternate user in the certificate request. If a certificate template permits the inclusion of a subjectAltName (SAN) different from the user initiating the certificate request (CSR), it opens the possibility to request a certificate as any user within the domain.

Exploiting ESC1 for Unauthorized Access and Privilege Escalation

Suppose we compromise the domain account Sara; we can utilize it to enumerate the CA’s certificate templates to identify those that allow the inclusion of alternate names (SAN) and specified “Client Authentication” EKU. If such templates are found, we can request a certificate using the compromised Sara account’s credentials, including the desired alternate account (e.g., Administrator) in the SAN field. Upon successful issuance of the certificate, the ADCS server sends the certificate back, enabling us to use it to authenticate as the specified account in the SAN. This could potentially lead to unauthorized access and privilege escalation by authenticating as a higher-privileged user using the acquired certificate as credentials.

ESC1 Abuse Requirements

The following conditions should be met to abuse ESC1:

1. The Enterprise CA’s configuration should permit low-privileged users to request certificates.
2. Manager approval should be disabled.
3. No authorized signatures should be required.
4. An overly permissive certificate template security descriptor should grant certificate enrolment rights to low-privileged users.
5. The certificate template defines EKU that enable authentication.
6. The certificate template should allows requesters to specify a subjectAltName in the CSR.

ESC1 Enumeration

This section will cover how to enumerate ADCS to find vulnerable components like, misconfigured certificate templates.

Using Certipy tool and its vast options we can find vulnerable templates and use the same tool to abuse it to compromise the domain. refer to the Certipy github for its command and usage.

Finding Vulnerable Template ESC1

The following command will show information about certificate authorities and vulnerable certificate templates.

 certipy find -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Vulnerable certificate template “ESC-1” found, which have “Client Authentication” EKU, manager approval is set to “False”, and Enrollment Rights set to “Domain Users” means any user can enroll for this certificate template using any user’s UPN.

Abusing Vulnerable Template ESC1

To abuse ESC-1 vulnerable template, we can use Certipy tool to request for the new certificate by specifying UPN of Administrator user, by doing this, it will request for ESC-1 certificate using Administrator UPN, later we can use this certificate to authenticate as Administrator.

 certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -template ESC-1 -upn administrator@badcs.fox

Using the saved certificate administrator.pfx, we can authenticate to domain as administrator user or using certipy tool, we can retrieve the NT hash of the administrator user.

The following certipy command try to authenticate using the administrator.pfx certificate and try to retrieve the NT hash of the administrator user.

certipy auth -pfx administrator.pfx

Using the retrieve NT hash of Administrator user, we can authenticate to “Domain Controller” using PassTheHash method, The following tools can be utilized for this: smbexec.py, wmiexecpy, psexec.py and Rubeus.exe

Practical: Domain Escalation using ESC2

Understanding ESC2 Domain Escalation Scenario

The ESC2 (Escalation 2) scenario is the initial domain escalation scenario and is part of a collection of escalation scenarios that exploit misconfigured AD CS certificate templates.

Misconfiguration in ESC2

The primary misconfiguration in this domain escalation scenario involves “Any Purpose” EKU and the ability to specify an alternate user in the certificate request. If a certificate template permits the inclusion of a subjectAltName (SAN) different from the user initiating the certificate request (CSR), it opens the possibility to request a certificate as any user within the domain.

Exploiting ESC2 for Unauthorized Access and Privilege Escalation

Suppose we compromise the domain account Sara; we can utilize it to enumerate the CA’s certificate templates to identify those that allow the inclusion of alternate names (SAN) and specified “Any Purpose” EKU. If such templates are found, we can request a certificate using the compromised Sara account’s credentials, including the desired alternate account (e.g., Administrator) in the SAN field. Upon successful issuance of the certificate, the ADCS server sends the certificate back, enabling us to use it to authenticate as the specified account in the SAN. This could potentially lead to unauthorized access and privilege escalation by authenticating as a higher-privileged user using the acquired certificate as credentials.

ESC2 Abuse Requirements

The following conditions should be met to abuse ESC2:

1. The Enterprise CA’s configuration should permit low-privileged users to request certificates.
2. Manager approval should be disabled.
3. No authorized signatures should be required.
4. An overly permissive certificate template security descriptor should grant certificate enrolment rights to low-privileged users.
5. The certificate template defines Any Purpose EKU or no EKU.
6. The certificate template should allows requesters to specify a subjectAltName in the CSR.

ESC2 Enumeration

This section will cover how to enumerate ADCS to find vulnerable components like, misconfigured certificate templates.

Using certipy tool and its vast options we can find vulnerable templates and use the same tool to abuse it to compromise the domain. refer to the Certipy github for its command and usage.

Finding Vulnerable Template ESC2

The following command will show information about certificate authorities and vulnerable certificate templates.

 certipy find -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Vulnerable certificate template “ESC-2” found, which have “Any Purpose” EKU, manager approval is set to “False”, and Enrollment Rights set to “Domain Users” means any user can enroll for this certificate template using any user’s UPN

Abusing Vulnerable Template ESC2

To abuse ESC-2 vulnerable template, we can use certipy tool to request for the new certificate by specifying UPN of Administrator user, by doing this, it will request for ESC-2 certificate using Administrator UPN, later we can use this certificate to authenticate as Administrator.

 certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -template ESC-2 -upn administrator@badcs.fox

Using the saved certificate administrator.pfx, we can authenticate to domain as administrator user or using certipy tool, later, we can retrieve the NT hash of the administrator user.

The following certipy command try to authenticate using the administrator.pfx certificate and try to retrieve the NT hash of the administrator user.

certipy auth -pfx administrator.pfx

Using the retrieve NT hash of Administrator user, we can authenticate to “Domain Controller” using PassTheHash method, The following tools can be utilized for this: smbexec.py, wmiexecpy, psexec.py and Rubeus.exe

Practical: Domain Escalation using ESC3

Understanding ESC3 Domain Escalation Scenario

The ESC3 (Escalation 3) scenario is similar to ESC1 and ESC2, but it involves the exploitation of a different EKU and necessitates an extra step for the abuse to occur.

Misconfiguration in ESC3

The EKU Certificate Request Agent, identified by the Object Identifier (OID) 1.3.6.1.4.1.311.20.2.1, commonly known as the Enrollment Agent, enables a principal to request a certificate on behalf of another user. Imagine a scenario where a user with a smart card meets an IT administrator in person for identity verification, and the administrator needs to submit a certificate request on behalf of that user.

AD CS accomplishes this by utilizing a certificate template that includes the Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) within its Extended Key Usages. The enrollment agent enrols in this template and utilizes the resulting certificate to jointly sign a Certificate Signing Request (CSR) on behalf of the other user. Afterwards, the enrollment agent submits the co-signed CSR to the Certification Authority while enrolling in a template that grants permission to enroll on behalf of others. In response, the CA issues a certificate for the designated user.

To abuse this for privilege escalation, a CA required at least two templates matching conditions below.

Condition 1:

The following conditions should be met for the primary template to abuse ESC3:

1. The Enterprise CA’s configuration should permit low-privileged users to request certificates.
2. Manager approval should be disabled.
3. No authorized signatures should be required.
4. An overly permissive certificate template security descriptor should grant certificate enrolment rights to low-privileged users.
5. The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) allows for requesting other certificate templates on behalf on other principals.

Condition 2:

The following condition should be met for secondary template to abuse ESC3.

1. The Enterprise CA’s configuration should permit low-privileged users to request certificates.
2. Manager approval should be disabled.
3. The template schema version 1 or greater than 2 mandates an Application Policy Issuance Requirement, necessitating the Certificate Request Agent EKU.
4. The certificate template defines EKU that enable authentication.
5. Enrollment agent restrictions should not be implemented on the CA.

ESC3 Enumeration

This section will cover how to enumerate ADCS to find vulnerable components like, misconfigured certificate templates.

Using certipy tool and its vast options we can find vulnerable templates and use the same tool to abuse it to compromise the domain. refer to the Certipy github for its command and usage.

Finding Vulnerable Template ESC3

The following command will show information about certificate authorities and vulnerable certificate templates.

 certipy find -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -stdout -enabled -vulnerable

Vulnerable certificate template “ESC-3” found, which have “Any Purpose” EKU, manager approval is set to “False”, and Enrollment Rights set to “Domain Users” means any user can enroll for this certificate template using any user’s UPN

Abusing Vulnerable Template ESC3

To abuse ESC-3 vulnerable template, we can use certipy tool to request for the new certificate for ESC-3 template as Sara user.

certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -template ESC-3

Afterwards, we can request a certificate on behalf of any user from any other template by including the above exported certificate sara.pfx. It is crucial to request a certificate from a template that allows Client Authentication EKU. The built-in “User” template can be utilized for this (Condition 2).The following certipy command request a certificate on behalf of the Administrator user using the saved sara.pfx certificate.

 certipy req -u Sara -p ‘s@ra@123’ -dc-Ip 10.0.2.4 -ca badcs-BADCS-CA-2 -templet User -on-behalf-of administrator -pfx sara.pfx

With the saved certificate administrator.pfx, authentication as the administrator user on the domain or retrieving the NT hash using certipy tool is possible.

certipy auth -pfx administrator.pfx

Using the retrieve NT hash of Administrator user, we can authenticate to “Domain Controller” using PassTheHash method, The following tools can be utilized for this: smbexec.py, wmiexecpy, psexec.py and Rubeus.exe

Mitigations

• Auditing Active Directory Certificate Services Architecture and Certificate Templates

Regular auditing of AD CS architecture and certificate templates is crucial for promptly identifying and addressing vulnerabilities. Organizations must conduct thorough audits of AD CS security settings, including enrolment rights, manager approval, authorized signatures, and access control for each managed certificate template. Additionally, it’s imperative to recognize CA servers, including subordinate CAs, as Tier 0 assets that require robust protection measures. 

• Treating CA Servers as Tier 0 Assets

Given their critical role in AD CS, organizations should treat CA servers like Domain Controllers – applying stringent access controls, regular patching and monitoring, restricting physical and logical access, etc. In doing so, organizations can increase overall AD CS security through such measures. 

TL;DR

Active Directory Certificate Services (AD CS) serves a vital function in safeguarding digital certificates within an enterprise setting. However, its security implications are frequently underestimated, potentially leaving organizations vulnerable to attacks or compromise. To bolster the security of their AD CS infrastructure and mitigate risks linked to certificate abuse and domain escalation, organizations must grasp potential threats, institute robust security measures, and adhere to industry best practices. 

Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.

“Join us on our journey of growth and development by signing up for our comprehensive courses.”