Introduction
The aim of this post is to go into more detail on the attacks described within the excellent ‘Certified Pre-Owned’ blog post & whitepaper produced by SpecterOps. This post will show how to configure a test environment which is vulnerable to the attacks they describe. If you are unfamiliar with AD CS, I have a separate post which covers the basics.
In summary, the attacks which are possible within a default installation of AD CS are terrifying. The now ubiquitous ‘ESC8‘ attack can lead to DC compromise from a low-priv user, and the other attacks are impressive in their own right. To learn more about how to perform the attacks, I have another post covering that.
- Introduction
- What Can Be Vulnerable In AD CS?
- VULN1 – “The Enterprise CA Grants Low-Priv Users Enrollment Rights”
- VULN2 – “An Overly Permissive Certificate Template Security Descriptor Grants Certificate Enrollment Rights To Low-Privileged Users.”
- VULN3 – “Manager Approval Is Disabled”
- VULN4 – No Authorized Signatures Are Required
- VULN5 – “The Certificate Template Defines EKUs That Enable Authentication.”
- VULN6 – The Certificate Template Allows Requesters To Specify A SubjectAltName (SAN) in the CSR
- VULN7 – EDITF_ATTRIBUTESUBJECTALTNAME2
- Conclusion
What Can Be Vulnerable In AD CS?
This section will cover some of the misconfigurations covered within the whitepaper, showing how we can create a vulnerable AD CS environment. The ‘VULN’ numbers used below are something I used whilst researching into these attacks and made the configuration a little easier for myself.
In summary, the vulnerabilities can be shown in the table below:
| ESC1 (p.56) | ESC2 (p.63) | ESC3.1 (p.64) | ESC3.2 (p.64) | ESC4 (p.68) | ESC5 (p.70) | ESC6 (p.71) | ESC7 (p.74) | |
VULN1 – Enterprise CA ACE | ✔️ | ✔️ | ✔️ | ✔️ | – | – | – | ✔️(*) |
VULN2 – Template ACE | ✔️ | ✔️ | ✔️ | ✔️ | ✔️(1) | – | – | – |
VULN3 – Manager Approval Disabled | ✔️ | ✔️ | ✔️ | ✔️ | – | – | – | – |
VULN4 – No signature required | ✔️ | ✔️ | ✔️ | – | – | – | – | – |
VULN5 – Vulnerable EKU OID | ✔️ | ✔️(2) | ✔️(3) | ✔️ | – | – | – | – |
VULN6 – SAN in CSR | ✔️ | – | – | – | – | – | – | – |
VULN7 – EDITF_* attribute | – | – | – | – | – | – | ✔️(*) | – |
For example, to perform ESC6, we need VULN7 to be present in the estate. Likewise, if VULN4 is present on a given certificate, then ESC1, 2 or 3 could be possible should the other conditions be met.
One key point for this table, is that if ESC6 or ESC7 is possible, then ESC1-4 can be performed against any principal!
VULN1 – “The Enterprise CA Grants Low-Priv Users Enrollment Rights”
The Enterprise CA must be configured to allow our target user to request a certificate. This setting can be found via certsrv by right clicking on the CA object, then Properties then Security. A vulnerable server will have an ACE containing the target user (Such as Domain Users) allowing that user to request certificates. (Figure 8, Page 23)
This setting is enabled by default, as we can see above. This allows any authenticated user to request certificates from the AD CS server. In order to obtain a certificate, we will also need a certificate template to be (mis)configured to allow us to enrol on it. This is covered in VULN2 below.
These ACEs are also involved in VULN7, where we have the ‘Manage CA‘ or ‘Issue and Manage Certificates‘ ACE enabled for our user.
VULN2 – “An Overly Permissive Certificate Template Security Descriptor Grants Certificate Enrollment Rights To Low-Privileged Users.”
Despite the mouthful of a title, this is another ACE misconfiguration, which allows our standard user account to enroll on a certificate template. As we can see below, the default User template allows the Domain Users group to enroll on it.
There are several permissions which can be abused here, for example the Enroll and AutoEnroll permissions are specific to certificate template objects.
We also have the more ‘traditional’ permissions such as Full Control and Write, which should be familiar from BloodHound. Either of these permissions would allow us as an attacker to edit the template, granting our user the Enroll or AutoEnroll permissions to enroll on it.
VULN3 – “Manager Approval Is Disabled”
Following the same steps as VULN2, we can view details on the certificate templates. On the ‘Issuance Requirements‘ tab, we can see the authorisations required before a certificate is issued. If CA Certificate manager approval is not required, then we can request a cert and it will be automatically created for us.(Assuming we meet the other criteria such as those in VULN1 and VULN2.)
This is understandably quite risky, as there is no peer reviewing of these certificates, so an Administrator would not be aware of their issuance.
VULN4 – No Authorized Signatures Are Required
In a very similar method to VULN3, we can check if any authorized signatures are required. This is another pre-requisite which can make the process of issuing certificates better protected.
VULN5 – “The Certificate Template Defines EKUs That Enable Authentication.”
Using the method detailed in VULN3, we then go to the ‘Extensions‘ tab to view the EKUs which are set on the template.
The EKU OIDs which have been found to allow client authentication are on Page 19 of the whitepaper:
| EKU Usage | OID Value |
| Client Authentication | 1.3.6.1.5.5.7.3.2 |
| PKINIT Client Authentication | 1.3.6.1.5.2.3.4 |
| Smart Card Logon | 1.3.6.1.4.1.311.20.2.2 |
| Any Purpose | 2.5.29.37.0 |
| “SubCA” | No EKUs |
We can view this by selecting the ‘Application Policies‘ extension. By clicking on ‘Edit’ and then ‘Edit’ we can view the EKU value. As we can see below, the ‘Client Authentication‘ OID is included in the template below.
We can also view this using PowerView with the following query:
Get-DomainObject -SearchBase "CN=<TEMPLATE_NAME>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=forest,DC=com" | Select-Object -ExpandProperty PKIExtendedKeyUsage
VULN6 – The Certificate Template Allows Requesters To Specify A SubjectAltName (SAN) in the CSR
As a reminder here, a CSR is the request we send to an AD CS server to obtain a certificate. A SAN is an option we can set to obtain a certificate to authenticate as another user.
This misconfiguration allows for an attacker to request a certificate for any(!) target user for a given, vulnerable certificate template. Typically certificates can only be requested for the requestor, so this misconfiguration is very powerful.
With this setting enabled, we can request a certificate as any valid user on the domain. There is more detail on this on page 58.
This value is set via the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag, which is a bitmask. We can find its value on the MSPKI-Certificate-Name-Flag value on the template. This can be requested with the following PowerView query:
Get-DomainObject -SearchBase "CN=<TEMPLATE_NAME>,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=forest,DC=com"Or we can view it in the GUI if we have access to the AD CS server by going on the Properties of the certificate template, then onto the Subject Name tab.
VULN7 – EDITF_ATTRIBUTESUBJECTALTNAME2
According to Microsoft:
If this flag is set on the CA, any request (including when the subject is built from Active Directory) can have user defined values in the subject alternative name.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786426(v=ws.11)#controlling-user-added-subject-alternative-names
This is a slightly different request as the SAN must be passed as an attribute, instead of a certificate extension, as with VULN6. This is still a very easy attack, even with this small change. Page 70 of the whitepaper contains more information on this.
Conclusion
Now we have looked at the misconfigurations, this post will show more detail on how we can attack a vulnerable environment.