Active Directory Certificate Services (AD CS) is a powerful and versatile way for domain administrators to protect an enterprise’s domain network while securing information regarding communication, code signing, and user authentication of the domain resources. Microsoft’s PKI implementation allows the organization to use the network protocol 802.1x encompassed with PKI infrastructure with a set certificate enrollment policy to enroll authenticated users of the Active Directory according to the specified certificate template matching their role. They enable end users to authenticate their domain resources securely without a password because of the certificate based authentication provided by a certificate generated from the Certificate Authority(CA).
Upgrading to this level of security is universally acknowledged as a more secure form of network security versus traditional credential methods such as EAP-TTLS for enterprise environments. Unfortunately, using AD CS can have massive drawbacks as it is complex to configure, maintain, and keep up to date due to the Certificate validity periods and sensitive security settings. This can be very costly for the enterprise and time-consuming for administrators and end users. If using an on-premises Radius server, the domain can see outage issues that can lead to all domain users being unable to authenticate to their network and waiting for the Domain Administrators to get it back online.
With those drawbacks, domain admins must be aware of misconfigured certificate service instances. Despite the strong defense AD CS presents, hackers have found ways to overcome this and locate many vulnerabilities that can comprise the entire network and contain organizations’ information. One of these ways is through Domain Escalation.
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, and the recommended steps for mitigating this threat and strengthening the security of that network.
AD CS ESC1
Domain escalation is a method of attack that can stem from many different paths. These paths could include vulnerable certificate authorities’ permission, vulnerable template ACLs (Access Control List), misconfigured certificate templates, and more.
The misconfiguration of templates is the scenario that causes ESC1( Domain Escalation Scenario 1). Misconfigured certificate template instances allow attackers to exploit vulnerabilities and elevate their level of access. Domain escalation can result in malicious control over the public key infrastructure, potentially compromising the overall security of the entire network by exploiting these weak points within the certificate templates.
To review Active Directory Certificate Services, Certificate Authority, and the process of a certificate request. Certificates contain information that links an identity, also known as the subject, with public and private keys. Applications can then utilize this pair as evidence of the user’s identity during domain authentication. The responsibility of issuing certificates lies with Certificate Authorities (CAs).
This process begins when the domain clients generate a pair of private and public keys. The client’s public key is incorporated into a certificate signing request (CSR) along with details such as the certificate subject and template name. Subsequently, clients send the CSR to the Enterprise CA server.
The CA server verifies if the client can perform a certificate request. If allowed, it examines the certificate template’s AD object specified in the CSR to determine whether or not to issue a certificate. The CA also checks if the permissions associated with the certificate template AD object permit granting a certificate to the authenticating account.
If so, the Certification Authority (CA) creates a certificate based on the predefined certificate settings outlined in the certificate template. These settings include Extended Key Usage (EKUs), cryptography configurations, and any specified issuance requirements. The CA then uses its key to sign the certificate before sending it to the client.
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 vulnerable certificate template published 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.
The 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 have listed the following configuration that allows 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 low-privileged user enrollment requests for most users and groups. 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.
The Attack: Requesting Misconfigured Template
A misconfigured certificate template allows the attacker to request a certificate using an arbitrary SAN (Subject Alternative Name/ subjectAltName). It will allow the malicious hacker to authenticate as any principal with low user privileges using SChannel or Kerberos.
This can occur because the Certificate Template allows requesters to specify a SAN in the CSR (Certificate Signing Request) and define which EKUs will enable authentication. This includes EKUs such as Smart Card logon, Client Authentication, PKINIT Client Authentication, and any purpose or no Extended Key Usage/Sub CA.
Active Directory will use the identity specified by Certificates SAN during authentication, which allows the hacker to identify the SAN in the CSR. Knowing this, the attacker will then be able to request certificates as any user under the Active Directory environment, which includes the domain administrator, making this the most significant weak point.
Conclusion
There are many ways for domain escalation, and hackers can exploit them for their attacks. Attacks will look for opportunistic weak points, vulnerable certificate templates, vulnerable web enrollment Endpoint through http based enrollment methods, arbitrary certificate values, and much more to access the organization’s network. Domain administrators must take proper action to find vulnerable certificate templates and enumerate certificate templates, monitor who is accessing their networking, stay up to date with the most current news and software updates to avoid missing a critical security patch, and examine their certificate settings to make sure they’re providing the proper access while maintaining a solid certificate mapping.
This can be very challenging as it requires significant time, money, and maintenance to consistently maintain AD CS while avoiding outages, which only a few people within the enterprise can do. It is highly recommended that enterprises look towards a third party specializing in Network Security and PKI to segment security responsibilities and perform efficiently without the risk of exploitation. We at SecureW2, a Microsoft Partner, specialize in simplifying PKI management and entirely securing the network with our CLOUD Radius and PKI Infrastructure products.
With seamless integrations taking less than a day to migrate, administrators can integrate their Identity Provider and view all devices that are accepted or rejected for network connectivity and certificate enrollment, experience an automated hands-off certificate lifecycle for BYOD or MDM device onboarding for all your existing platforms, detailed reporting and event logs that can be sent to your SIEM/Syslogs and much more! Contact us today to answer any more questions regarding our solutions, pricing, and demonstration schedule.
