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.
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.
Certificate Authorities (CAs) are responsible for issuing certificates. They play a crucial role in verifying the authenticity of the entities requesting the certificates.
At a high level, the certificate issuance process involves the following steps:
This process ensures secure and controlled certificate issuance within the network, enhancing system security and integrity.
Refer to the below diagram for better understanding:
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:
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:
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.
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.
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.
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:
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.
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
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:
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
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
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:
Condition 2:
The following condition should be met for secondary template to abuse ESC3.
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
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
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.
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.
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.”
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
