This type of ADCS misconfiguration can lead to privilege escalatation, and thus, compromise of the entire domain in an AD environment
It arises when an existing certificate template in the CA is not propertly secured, allowing a low-privileged user to request a certificate and specify an arbitraty identity within the Certificate’s Subject Alternative Name ( SAN )
Therefore, it allows the attacker to impersonate any user account in the domain, including privileged accounts such as administrators
A template vulnerable to ESC1 typically has the following features →
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECTenabled
This option allows the person requesting the certificate to define the SAN as desired. So the client can specify another entity in the Certificate Signing Request ( CSR ) and dictates the certificate entity
Authentication EKU
Such as Client Authentication, Smart Card Logon or Any Purpose
Permissive Enrollment Rights
Generic domain groups such as Domain Users, Domain Computers or Authenticated Users can enroll in the given template
Automated Request Processing
It does not requires any administrator to accept incoming certificate requests related to the template in question
First, we must check if ADCS is present in the given AD environment, which can be gathered through LDAP
Then, we have to enumerate all the existing certificate templates in the CA looking for any security flaw or misconfiguration
Once we have identified one or several misconfigurations related to ESC1, which were discussed previously, and requirements below are met, we can takeover the entire domain
It’s as simple as submitting a CSR to the CA that has an arbitrary entity as its SAN, such as the domain administrator account or SID and applying to the misconfigured template
With the issued certificate, we can carry out several actions →
If the DC in question does not support PKINIT due to the absence of the Smart Card Logon Extended Key Usage ( EKU ) in its certificate, an operator could use the issued certificate to authenticate against LDAPs or LDAP with STARTTLS
Then, we could carry out specific actions depending on the privileges the principal in question has over the domain
For instance, if we leverage an ESC1 vector to obtain an arbitraty certificate whose SAN corresponds to the identity of a privileged domain user, such as the administrator account, we could grant ourselves FullControl over the latter