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.
- 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
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)|
For example, to perform
ESC6, we need
VULN7 to be present in the estate. Likewise, if
VULN4 is present on a given certificate, then
3 could be possible should the other conditions be met.
One key point for this table, is that if
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
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 enroll on it. This is covered in
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
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
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
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|
|PKINIT Client Authentication||184.108.40.206.220.127.116.11|
|Smart Card Logon||18.104.22.168.4.1.322.214.171.124|
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.
Now we have looked at the misconfigurations, this post will show more detail on how we can attack a vulnerable environment.