TL;DR - Using built-in default version 1 certificate templates, an attacker can craft a CSR to include application policies that are preferred over the configured Extended Key Usage attributes specified in the template. The only requirement is enrollment rights, and it can be used to generate client authentication, certificate request agent, and codesigning certificates using the WebServer template.

In 2021, researchers Will Schroeder and Lee Christensen from SpecterOps released a whitepaper detailing eight (8) escalation techniques against Active Directory Certificate Services (AD CS), which they dubbed ESC1 - ESC8. If you have not read that whitepaper, please go do that first; it will make the rest of this easier to follow. Their original research led to additional research in AD CS and, over the next couple years, additional escalation techniques were identified (ESC9 - ESC14).

Story Time

It's 4:30AM and the testing window ends at 6:00AM. We've got a foothold, but only administrative access to one (1) system. I remote into the server using RDP and start poking around in the MMC. Since I have administrative access to the system, I can also see the system certificates. I decided to check to see if there were any templates that maybe I missed with the automated scanning for ESC1.

Then I noticed something. This kind of looks like ESC1 because it allows you to supply the subject. I'm pretty sure that the WebServer certificate template wouldn’t have the Client Authentication EKU configured, which is a requirement for ESC1, but I decided to click on More information is required to enroll this certificate. Click here to configure settings.

I filled out the subject and UPN fields to match the Administrator account just like the ESC1 attack.

I went to double check that the Key Usage was configured as Server Authentication, like it should have been set by the template, and I realized that the GUI wasn’t greyed out. I thought that was weird, and so I tried to remove the Server Authentication, added Client Authentication to the EKUs, and requested the certificate.

I thought to myself, "Surely that didn’t work." I looked at the certificate and it still said Server Authentication under the EKU field, but there was something strange. There was a new field labeled Application Policy. The Client Authentication that I had specified in the request was present in the certificate but under a different field.

I decided to try and authenticate to AD with it. With Dirk-jan's PKINIT tool, I used the certificate to request a Kerberos TGT but got an error.

But then I remembered a blog that showed a technique dubbed PassTheCert to use the certificate to authenticate via schannel against LDAP. Miraculously, it worked. I was authenticated to LDAP as the administrator. Later, I also confirmed the method was possible with Certipy with the -ldap-shell feature.

Once I realized the issue was novel, I opened a case with Microsoft Security Response Center (MSRC). While waiting for Microsoft, we kept digging.

AD CS Template Version History Lesson

During its introduction in Windows Server 2000, AD CS included several default templates for commonly used tasks, including the WebServer template among others. The built-in templates were examples for commonly used certificate purposes, including Server Authentication. Later in Windows Server 2003, version 2 templates were introduced, which gave the certificate templates more features, including autoenrollment.

"An administrator can configure version 2 templates to control the way certificates are requested, issued, and used." - Microsoft

Version 1 templates are very basic templates and cannot be customized. The only configuration changes that are allowed are enrollment rights. If you need to customize a version 1 template, you must clone the template. This creates a copy of the template, but it also automatically converts the resulting template to version 2 (this is important for later). 

EKU and Application Policies

I've heard of an EKU before, but what is an Application Policy? Even Microsoft's documentation confuses the two, but as I discovered, they are very different attributes. EKU stands for Extended Key Usage as defined in IETF RFC5280. However, Microsoft uses the terms Extended Key Usage and Enhanced Key Usage interchangeably in documentation. Within this category, Microsoft has a proprietary extension called Application Policies under the OID 1.3.6.1.4.1.311. Similar to the x509 EKU, it defines the purpose of the certificate and even uses the same OID numbers as x509 EKUs, e.g., Client Authentication (1.3.6.1.5.5.7.3.2). It turns out that if there is a conflict between an Application Policy and an EKU, then Microsoft prefers the proprietary Application Policy.

"Application policy is Microsoft specific and is treated much like Extended Key Usage. If a certificate has an extension containing an application policy and also has an EKU extension, the EKU extension is ignored." - Microsoft

Initially, we thought the issue was limited to schannel, but discussing with @_dru1d in private conversations, we realized the issue wasn’t limited to schannel, and he discovered that other more dangerous OIDs could be added, including Certificate Request Agent (1.3.6.1.4.1.311.20.2.1).

Instead of being just like ESC1, ESC15 was actually more like ESC2, which is much more dangerous. Not only can you change the subject of the certificate, you can change the purpose of the certificate.

The difference between ESC2 and ESC15 was that ESC15 was hidden in plain sight. All of the ESC attacks are "misconfigurations of the templates" that allow abuse. But this isn’t a misconfiguration; this is a bug that allows us to add the Application Policies. This is why we decided to give it a vulnerability name, EKUwu.

By default, all of the version 1 templates are vulnerable; however, in order to exploit the vulnerability, the attacker must have enrollment rights. When the MSRC case was originally submitted, we thought the vulnerability was within LDAP/schannel and was only a privilege escalation attack. We updated MSRC with our findings in real time as we discovered them.

After four (4) weeks of waiting for an update from Microsoft, TrustedSec had already confirmed the issue in an additional 10 out of 15 clients tested. I received an email from MSRC that indicated the default configuration was not vulnerable because I modified the permissions for enrollment . From the percentage of our clients affected, we disagreed with the assessment.

With the help of TrustedSec's Senior Consultant Lou Scicchitano (@LouScicchitano), Principal Consultant Scot Berner (@slobtresix0), and Research Practice Lead Christopher Paschen (@freefirex2), we discovered additional use cases weaponizing ESC15, including code signing. Additionally, Beacon Object Files (BOFs) were updated to facilitate the attack over extendable C2 frameworks by updating adcs_request and adding adcs_request_on_behalf.

What Can be Done?

Microsoft is still working on their official response, but what TrustedSec has determined is that only version 1 templates that allow the requestor to supply the subject appear to be vulnerable to ESC15. If a version 1 template is cloned, it is automatically upgraded to version 2, and the template is no longer vulnerable. A PowerShell script has been created to automate the disabling of the known vulnerable templates. Before disabling any certificates templates, verify that no certificates are being issued from those templates.

Special Thanks

Special thanks to TrustedSec's Director of Security Intelligence, Carlos Perez @carlos_Perez, for providing the PowerShell script to automate the mitigations.

Special thanks to @freefirex2 for the creation of a new BOF to enable the ESC15 attack and to implement the Certificate Request Agent attack.

Special thanks to @_dru1d from CDW who created the first Certipy fork and subsequent pull request.

Additional Resources

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-crtd/44012f2d-5ef3-440d-a61b-b30d3d978130

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj129696(v=ws.11)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754305(v=ws.10)

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731792(v=ws.10)?redirectedfrom=MSDN