AD CS – What Can Be Misconfigured?

AD CS – What Can Be Misconfigured?

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 ubiquitousESC8‘ 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?

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✔️(*)
1 – Requires write permissions, 2 – Requires either ‘Any Purpose’ or no OID, 3 – Requires ‘Certificate Request Agent’ OID, * – Not relevant if ESC6 or ESC7 is possible

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)

By default, the Authenticated Users group is able to request certificates

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 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.

The standard User certificate template

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.

The Enroll and AutoEnroll permissions

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.

A template which does not require CA Certificate Manager approval

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 UsageOID Value
Client Authentication1.3.6.1.5.5.7.3.2
PKINIT Client Authentication1.3.6.1.5.2.3.4
Smart Card Logon1.3.6.1.4.1.311.20.2.2
Any Purpose2.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.

Example plaintext EKU OIDs for an example template

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
Getting the OIDs for a template with PowerView

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.

A vulnerable certificate template

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.