Microsoft Active Directory Public Key Infrastructure (PKI), better known as Active Directory Certificate Services (AD CS), is a Windows Server role for issuing and managing PKI certificates which are used in secure communication and authentication protocols. These certificates can be used to encrypt and sign documents and messages as well as for authentication of computer and/or user accounts. In this post we will take a closer look at the misconfigurations and how we can use it to attack Active Directory environments. The opportunities range from credential theft to machine persistence all the way up to domain escalation. The techniques are based on the Certified Pre-Owned Whitepaper by Will Schroeder and Lee Christensen.

The goal of this post is to provide a brief introduction to this complex, and frankly sometimes rather dry, but very important topic. We’ll cover some basic functionalities, what certificates look like and how they can be (ab)used.

Overview

AD CS can either be deployed as a standalone certificate authority (CA) or as a Enterprise CA. Standalone CAs do not have features like Certificate Templates and AutoEnrollment which makes them more likely to be used as Root and Policy CAs and they only issue certificates to other CAs. Enterprise CAs have features like certificate templates and autoenrollment which is, most of the time, crucial for enterprise environments. So, what are these features and how do they work?

• Certificate Templates can be seen as blueprints with predefined settings for certificates. The settings define things like What is the Certificate used for, Who can request a certificate, How long is the certificate valid and so on. Depending on the usage of a certificate the settings in these Blueprints can be adjusted.
• AutoEnrollment allows clients (Users and Computers) to automatically request and receive certificates in an Active Directory domain based on predefined certificate templates.

Certificates

As mentioned, a Certificate has various fields with information on how and what the certificate will be used for. Let’s take a closer look at some of those Fields and the expected Values:

• Serial Number Identifier for a Certificate assigned by the Certificate Authority
• Issuer Specifies who issued the certificate, normally a CA
• Valid from and Valid to Specifies the date from which the certificate is valid until the certificate expires.
• Subject Owner of the Certificate
• Enhanced Key Usages also known as Extended Key Usages (EKUs) – Object identifiers (OIDs) describe what the certificate can be used for.

The information which is included in the certificate binds an identity – the subject – to the key pair.

EKUs and OIDs relate to each other, basically an OID is a string of decimal numbers that uniquely identifies an object. For now, the EKUs that permit authentication to AD are interesting and we’re focusing on those:

More Information about OIDs in PKI can be found in this PKI Solutions Post.

Certificate Enrollment

After installing the AD CS role as an Enterprise CA, an administrator must first create and define certificate templates that are then published by Enterprise CA and made available to users and computers for enrollment. Without going into too much detail, a client can request a certificate only if it is allowed on the Enterprise CA as well as on the certificate template itself. More technical information about how these permissions are set can be found in the Whitepaper in the Chapter Certificate Enrollment.

If the permissions are granted and a client is allowed to request a certificate it can be done in different ways depending on the AD CS environment:

• With the Windows Client Certificate Enrollment Protocol (MS-WCCE).
• With the ICertPassage Remote Protocol (MS-ICPR).
• Via a web enrollment application, for this the AD CS Server needs to have the Certificate Authority Web Enrollment role installed.
• Via the Certificate enrollment service (CES), for this the AD CS Server needs to have the Certificate Enrollment Web Service role installed.
• Using the network device enrollment service, for this the AD CS Server needs to have the Network Device Enrollment Service role installed.

As an example: A User needs to manually request a new Certificate on his windows machine. The first step is to open the GUI, this can be done by typing certmgr.msc (certlm.msc for computer certificates) into the search pane in Windows. Open the Personal folder, right-click the Certificates folder and choose All Tasks, Request a new Certificate.

Now another wizard opens and all the published certificate templates, which the user is allowed to enroll in, are shown and can be enrolled. By default windows will then request the certificate using MS-WCCE.

Offensive Techniques

The offensive techniques are divided into four different categories, based on the different attack technique identifiers from the whitepaper, Theft, Persistence, Escalation and Domain Persistence. The following table helps understand the differences between the Categories:

To understand what kind of techniques these categories contain we will have a look at one of the Escalation possibilities if AD CS is misconfigured.

NTLM Relay to a vulnerable AD CS HTTP Endpoint (ESC8)

As mentioned in the Certificate Enrollment Chapter, several HTTP-based certificate enrollment interfaces are available, if they are installed. These HTTP interfaces are generally vulnerable against NTLM relay attacks. An attacker on a compromised machine could manipulate the Net-NTLMv2 authentication and impersonate any inbound-NTLM-authenticating AD Account, to gain access to certificate requests or perform other operations on behalf of the user. This could lead to security issues such as unauthorized access and the issuance of unauthorized certificates.

Let’s walk through a possible Attack where AD CS is vulnerable to ESC8:

1. An Attacker manages to compromise an End-User-Client and gets a foothold on said client.
2. After initial reconnaissance of the Active Directory, the ESC8 vulnerability was identified using the tool Certify in the Active Directory Certificate Service.
3. To start the attack against the AD CS Web interface it is required that a victim authenticates to the attacker-controlled client to set up the NTLM Relay. For the sake of this Walkthrough, we are going to assume that one of the following scenarios has occurred:
   1. The attacker has enough time and can wait for this to occur as part of the daily business on the network.
   2. The attacker manages to coerce an account to authenticate against the attacker-controlled machine. Preferred targets are Domain Controllers and/or High-Privileged Accounts.
4. After successfully coercing a domain controller, the Net-NTLMv2 Hash of the DC is sent to the attacker-controlled machine and can be relayed to the AD CS HTTP Endpoint.
5. Since the HTTP Endpoint doesn’t have relay protection, the attacker is able to request certificates in the name of the original sender, in this case the domain controller.
   1. Now a certificate, based on a certificate template with suitable Enhanced Key Usage values like Client Authentication or SmartCard Logon will be issued.
6. Since the victim machine was a domain controller, which can perform high privileged actions like domain replication, the attacker could use the certificate to compromise the domain. For example, some of the possibilities would be to try and run a DCSync Attack, get the NTHash or a Kerberos Ticket Granting Ticket (TGT) via PKINIT.

Defensive Techniques

Now, if the offensive Techniques are known it is a bit easier to protect against them. Will Schroeder and Lee Christensen already numbered and categorized these defensive techniques into preventative and detective measures. The Tool PSPKIAudit can be used to enumerate any misconfigured templates. After identifying any misconfigurations, it is highly recommended to dive deeper into the Defensive Techniques and follow the Defensive Guidance section to manage them accordingly. We won’t go into the different controls and how they are mapped to the offensive techniques, since thats well written in the whitepaper, but i quickly want to adress the preventative measure against the ESC8 vulnerability.

Harden AD CS HTTP Endpoints (PREVENT8)

The most effective method to prevent the ESC8 vulnerability is to not enable the AD CS HTTP Endpoints in the first place. To enumerate which Endpoints are enabled and remove them, connect to the server, which is running the AD CS Role, open the Server Manager app and use the Remove Roles and Features Wizard.

If the Endpoints are necessary and it is not possible to remove them, these defensive measures against ESC8 could be considered.

• Disable NTLM authentication, disabling NTLM can be done at the host or Webserver (Internet Information Services (IIS)) level.
• Enforce HTTPS on IIS level, enable Extended Protection for Authentication and set the Extended Protection Value to Required.

Conclusion

Active Directory Certificate Services can become complex very quickly, it is not the easiest to implement and secure in most environments. All the different possibilities for how it can be configured, extended, and adapted for different Use-Cases make it hard to lock it down from a security point of view. The different certificate abuse techniques allow attackers to go from Credential Theft to domain persistence up to Domain Escalation rather fast. The mentioned tools Certify (AD CS Enumeration) and PSPKIAudit (Auditing AD CS) are great to enumerate any weaknesses in the infrastructure which can then be addressed. If not already happening, it is recommended to continously audit the AD CS environment and the certificate templates. To summarize: Not only the domain controllers need to be protected but also the CA servers, treat them like a Tier 0 System

About the Author

Eric Maurer completed his IT training in the financial sector and then gained experience in the roles of administrator, engineer and consultant. He was involved in the development, setup and operation of an Enhanced Security Administrative Environment and the international rollout of Active Directory Services. In addition he is experienced in Azure Active Directory with a focus on security.

Links

• https://blog.quest.com/everything-you-need-to-know-about-dcsync-attacks/
• https://github.com/GhostPack/Certify
• https://github.com/GhostPack/PSPKIAudit
• https://learn.microsoft.com/en-us/archive/technet-wiki/9063.active-directory-certificate-services-ad-cs-network-device-enrollment-service-ndes
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-icpr/9b8ed605-6b00-41d1-9a2a-9897e40678fc)@
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wcce/446a0fca-7f27-4436-965d-191635518466
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wcce/446a0fca-7f27-4436-965d-191635518466)@
• https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-authority-web-enrollment#certification-authority-web-enrollment
• https://learn.microsoft.com/en-us/windows/win32/seccrypto/cryptoapi-system-architecture
• https://msrc.microsoft.com/blog/2009/12/extended-protection-for-authentication/
• https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107
• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://twitter.com/harmj0y
• https://twitter.com/tifkin_
• https://twitter.com/tifkin_..
• https://web.mit.edu/kerberos/krb5-1.12/doc/admin/pkinit.html#pkinit-configuration||
• https://www.pkisolutions.com/object-identifiers-oid-in-pki/
• https://www.tripwire.com/state-of-security/how-to-prevent-high-risk-authentication-coercion-vulnerabilities