Active Directory Certificate Services (AD CS) is an essential tool for domain administrators to enhance network security, ensuring secure communication, code signing, and user authentication. Organizations can leverage the 802.1x network protocol and a certificate enrollment policy. Authenticated users can enroll based on specified certificate templates, providing secure, password-free authentication through certificates issued by a Certificate Authority (CA).
Despite its robust defense capabilities, AD CS is not without vulnerabilities. Hackers can exploit misconfigured certificate services to perform domain escalation attacks, compromising the entire network. One critical vulnerability was identified by SpecterOps, a cybersecurity defense organization.
In this article, we’ll cover the most significant vulnerability discovered by SpecterOps, a Cyber Security Defense organization dedicated to finding and spreading awareness of potential cyber threats against individuals and organizations. We’ll also discuss the recommended steps for mitigating this threat and strengthening the security of that network.
AD CS ESC1: Domain Escalation Attack Scenario
Domain escalation attacks exploit Active Directory Certificate Services (AD CS) infrastructure vulnerabilities. These attacks can originate from several paths, such as insecure permissions on Certificate Authorities, vulnerable Access Control Lists (ACLs) on certificate templates, and misconfigured certificate templates. Among these, the misconfiguration of certificate templates, which we refer to as Domain Escalation Scenario 1 (ESC1), stands out as a particularly dangerous vulnerability.
ESC1: The Role of Misconfigured Certificate Templates
In ESC1, attackers leverage improperly configured certificate templates to elevate their access privileges within a domain. Misconfigurations in these templates can allow malicious actors to gain unauthorized control over the public key infrastructure (PKI), potentially compromising the entire network’s security.
Certificate Authority and Certificate Requests
To comprehend how ESC1 operates, it’s essential to understand the roles of Certificate Authorities (CAs) and the process of certificate issuance in AD CS. Certificates are cryptographic artifacts that bind an entity (referred to as the subject) to a public and private key pair. These keys serve as proof of identity during domain authentication. The CA is responsible for issuing these certificates. Here’s how this process typically works:
- Key Pair Generation: The domain client generates a pair of private and public keys.
- Certificate Signing Request (CSR): The generated public key is embedded in a Certificate Signing Request (CSR) along with pertinent information such as the certificate subject and the template name. This CSR is then forwarded to the Enterprise CA server.
- Verification by CA Server: The CA server verifies whether the client is authorized to submit the certificate request. It examines the specified certificate template’s AD object in the CSR to determine the legitimacy of issuing a certificate. This involves checking the permissions associated with the template to see if they allow the client’s account to receive a certificate.
- Issuance of Certificate: If the CA validates the request, it creates a certificate based on the predefined settings in the certificate template. These settings may include Extended Key Usage (EKUs), cryptographic configurations, and any other issuance requirements. The CA then signs the certificate with its key and returns it to the client.
Execution of the ESC1 Attack
To execute ESC1 scenarios, several improper configurations must be in place for the hackers to perform a certificate request as any user within the enterprise environments’ domain. When executing this attack, the hacker will scan the enterprise environment’s public key infrastructure to locate a published vulnerable certificate template that will permit them to request a certificate. After gaining access and establishing account persistence, adversaries will either attempt to elevate their domain privileges to the domain administrator account level or have already received an issued certificate with the domain admin status.
Misconfigured Certificate Templates Configurations
As previously stated, to perform domain escalation, the attacker will need to scan the network for a vulnerable certificate template that will allow for privilege escalation to occur to gain access to the domain admin account. To do this, the attacker will look for four components that will cause this scenario and comprise the entire AD CS system.
Enterprise CA provides Enrollment Rights to Low-Privileged Users
Domain administrators should have enrollment rights set to a specific set of accounts to limit being overly permissive. Otherwise, a group of users, such as domain users, being given enrollment rights can lead to significant issues. This certificate template setting allows the low-privileged user to request certificates from the Enterprise CA. An attacker impersonating a low-privileged user can exploit this insecure setting by requesting the Certificate Authority if they have the proper enrollment rights to carry out this exploitation.
The Manager Approval Setting is Not Enabled
Approval for certificate requests is essential for the security of issuing certificates to the proper parties that are on the domain. When this setting is not enabled, the request does not require a domain manager to approve the certificate, allowing a compromised machine or user account to receive the certificate without having that crucial layer of verification.
Not Requiring the Use of Authorized Signatures for CSR
Having the Certificate Signing Request (CSR) is crucial to verify the legitimacy of the issued certificates after a certificate authority has signed them. Not having this allows attackers the capability to request these certificates without the need to be legitimized and provides the opportunity to request malicious certificate templates full of more vulnerable configurations.
A Security Descriptor that is too permissive gives certificate enrollment privileges to Low-Level end users
Certificate templates can grant certificate enrollment rights to low-privileged users if configured too permissive. It results in the hacker abusing the certificate request agent OID (Object Identifier). This is another vulnerable template configuration because the certificate template AD object’s security descriptor grants enrollment rights, allowing hackers to see this and take advantage of multiple opportunities that can lead to network access.
Within the Discretionary Access Control List (DACL), the Access Control Entry (ACE) configurations will list the following configurations that allow certificate enrollment. Under the Security tab of the certificate template, you can see the group or user names under the domain and view the permissions for the domain users for Full Control, Read, Write, Enroll, and Autoenroll. Administrators should set this setting to Deny to limit users’ and groups’ low-privileged user enrollment requests. If only Enroll is selected, it can lead to an exploitation of the certificate template.
After the attacker locates which domain group their target is at, they’ll next locate the security descriptor EKU. The certificate template defines EKUs that enable authentication. Suppose the certificate templates are found to be weak. In that case, the lack of hardened security within the descriptor can lead an attacker to request a certificate that identifies the Certificate Request Agent EKU. These EKU include Client Authentication, PKINIT Client Authentication, Smart Card Logon, and Any purpose or no EKU, also known as SubCA.
Exploiting Misconfigured Certificate Templates
A misconfigured certificate template permits attackers to request a certificate using an arbitrary SAN (Subject Alternative Name). This enables the attacker to authenticate as any principal, even with low user privileges, by exploiting authentication protocols like SChannel or Kerberos. The attack process involves:
- Arbitrary SAN Specification: The misconfigured template allows attackers to specify a SAN in their Certificate Signing Request (CSR).
2. EKUs for Authentication: Attackers can define EKUs (Extended Key Usages) that facilitate authentication, including:
- Smart Card Logon
- Client Authentication
- PKINIT Client Authentication
- Any Purpose or no EKU/Sub CA
3. Identity Exploitation: Active Directory uses the identity specified by the certificate’s SAN during authentication. This allows the attacker to request certificates impersonating any user, including high-privilege accounts like domain administrators.
The implications of this attack include:
- Unauthorized Access: Attackers can gain unauthorized access to domain resources by submitting a CSR with a forged SAN.
- Privilege Escalation: Once access is gained, attackers can escalate their privileges within the domain, potentially compromising the entire network.
Enhance Your Security with SecureW2’s Simplified PKI Management
In light of the vulnerabilities and complexities associated with managing Active Directory Certificate Services (AD CS), leveraging advanced solutions like SecureW2 can offer significant benefits. SecureW2 simplifies the often intricate tasks of Public Key Infrastructure (PKI) management and fortifies network security using Cloud RADIUS and user-friendly PKI management tools.
SecureW2’s PKI management toolset is designed to streamline the entire certificate lifecycle. This includes certificate enrollment, renewal, and revocation, all managed through a centralized, cloud-based interface. We can integrate with all major MDMs, including an enhanced integration with Intune, that automates certificate issuance and revocation, reducing the chances of human error. Learn more about how we integrate with Microsoft environments, or reach out to us today to see how it all works.
