My name is Ron Arestia, and I am a Security Researcher with Microsoft’s Detection and Response Team (DART). We respond to customer cybersecurity incidents to assist with containment and recovery from threat actors. In this blog post, we work to enhance the security position of PKI by focusing on the most vital component first: your Certification Authorities (CAs). This is part 4 of a series on practical PKI implementation based on my experience with customer interactions working as a Microsoft engineer.

Feel free to catch up on previous blog posts or jump right into this one

Before you start down this path, review SpectreOps Exploitation of Certificate Services framework. This is the de facto standard against which you should secure your PKI. If you cannot protect against misconfigurations, threat actors are going to leverage them against you.

Please note: I will not be demonstrating any red team/hacking tools in this blog out of an abundance of caution. There are myriad guides on how to leverage these tools against an ADCS PKI. My goal with this series is to provide best practice guidance and learn to think like a defensive security professional specific to PKI.

Throughout this and future blog posts, I am going to reference the Exploitation of Certificate Services framework as ESC and reference specific ESC exploits. Take a moment to cross-reference what is written here with the finding to understand how misconfigurations can be abused.

Root CA Security

I would advise anyone jumping into this blog series at this point to go back and review previous posts about root CA security and best practices. So much has already been written about this, so I will be brief in this section to focus on downstream security concepts.

If a root CA is truly offline and protected by an HSM, the risk of compromise is exceptionally low albeit not zero. While I do not know of any specific anecdotal evidence of an offline root CA compromise, I am sure Hollywood could produce some Mission Impossible-level script. In reality, most threat actors are maneuvering around an enterprise via the identity plane, and the PKI infrastructure is the icing on a very scrumptious cake once they have achieved domain dominance. The idea of air-gapping your root CA does not mean your enterprise is insulated from a PKI attack, but the root of trust for your organization is sufficiently protected that rebuilding the subordinate infrastructure is much quicker than having to perform a greenfield deployment of your PKI.

Recall that your root CA, as with all root CAs, leverages a self-signed certificate. That certificate is not by itself very remarkable except that it signs all of the subordinate/issuing/registration authorities AND all of the certificate revocation lists (CRLs). If a threat actor cannot compromise the root CA, in the case of a cybersecurity incident involving the subordinate infrastructure, the impacted organization can simply revoke all of the subordinate infrastructure certificates which will then be added to the CRL. That will subsequently invalidate any and all certificates issued by those subordinate CAs, but securely rebuilding the subordinate infrastructure means that an organization only needs to hydrate their issuance/registration infrastructure while the root remains trusted by the entire organization. This reduces the recovery time significantly since the root infrastructure is still trusted across the enterprise.

If your root CA is NOT offline, it needs to be. There is no way to adequately mitigate risk against your PKI if the root CA is enterprise-joined. If your root CA is also your primary issuer, you should migrate to a two-tier PKI hierarchy after assessing need and impact. Threat actors are attracted to the highest branch in your organization’s technical hierarchy. If the root CA is online, they will find it, and chances are good that they will figure out how to exploit it.

Enterprise CA Security

One piece of advice throughout this entire process: take your time. There is no reason for you to rush this process or otherwise expedite your PKI into production. “Haste makes waste,” as goes the old proverb. While it is absolutely possible to stand up a servicing infrastructure in a brief period of time, you will miss critical security controls that will put your organization at risk. Take pains to document exhaustively your desired PKI configuration: CA names, supported encryption types, minimum key sizes, certificate and CRL validity periods, template types and purposes, and groups and users used across the PKI for management of the CA, templates, and issuance. Documentation of your PKI should be the overwhelming majority of the time spent building it. Every other component falls into place with a proper framework established in advance.

Your issuers are going to be front and center to most of your PKI operations. Do not co-locate services on your issuing CAs. Your issuing CAs have a single purpose: as an enterprise issuing certificate authority. The only service installed on these systems should be the ADCS Certification Authority role. Do not install the CA role on a domain controller. (I cannot stress this enough!) Do not install any other Windows role or feature, even those under the ADCS role. Every additional role you install on your issuing CA increases its risk footprint and your administrative burden. Keep third party tools, agents, services, APIs, etc. to the bare minimum. If this is installed in Tier 0 of a properly tiered security environment, the risk should be much lower. PKI is a Tier 0 system! It should be treated with the same level of security as your domain controllers.

For both (Offline) Root and Issuing CAs, the theft of a private key is considered a domain persistence technique, and the CA should be considered compromised even if there is no evidence of exfiltration.

Proper CA Rights Management

Before you get started with your PKI implementation, you should create a handful of new security groups in Active Directory to directly manage your CAs, templates, and issuance. By default, ADCS assumes Domain Admins and Enterprise Admins are administering your PKI. Do not leave this configuration in place. This does not comply with any least privilege guidance, and it leaves your PKI in a position where it can be compromised either directly or indirectly through lateral account movement once either of those groups is compromised by a threat actor.

To manage your issuing CA, create a security group named “CA Admins” or something similar that meets your organizational naming standards or needs. CA Admins have the sole responsibility of managing the CAs themselves. These are the admins who will open the Certification Authority management console (MMC), modify the CA configuration, when necessary, perform signing operations (e.g., manual CRL issuance), revoke certificates, perform backups, and maintain the overall health of the PKI. (Figure 1)

Figure 1

To manage certificate issuance for your enterprise, create a security group named “Certificate Managers” or something similar. Certificate Managers have the responsibility of scrutinizing certificates pending issuance. This should be a small group of trusted admins who are trained to review certificate requests and perform issuance based on security and risk standards established for your enterprise. (Figure 2)

Figure 2

Each of these groups will be configured in the ADCS certification authority MMC with their respective rights. Each one of these groups is single-purpose. None of them should have the ability to request certificates, and ideally, the membership of these groups should never overlap. The purpose here is to provide role separation. No one should be able to request a certificate and approve their own request, for example.

To manage certificate templates for your enterprise, create a security group named “Certificate Template Managers” or something similar. Certificate Template Managers are responsible for creation, management, and maintenance of all certificate templates in the enterprise. These individuals should have a comprehensive understanding of certificate template creation, purposeful provisioning of new templates, and management of access control lists (ACLs) on templates. These individuals are your first line of defense against misconfiguration of certificate templates that lead to compromise through many of the Exploitation of Certificate Services (ESC) methods. Note: this requires manipulation of a container in the Active Directory Configuration partition and may not be explicitly necessary if Certificate Managers is properly constrained. (Figure 3)

Figure 3

These configurations made during inception of the PKI should cover you against exploitation of ESC7 specifically and require a very narrowly-scoped attack path for a threat actor to leverage it. I want to caution that this is not foolproof and does not account for exploitation of the administrative accounts themselves. If a threat actor gains control of one of the administrative accounts, they will have exploitation capability of whatever administrative function(s) is/are in scope for that user. This is why role separation is such an important concept for PKI management. In a true cybersecurity incident, the threat actor would have to gain access to multiple accounts to take full advantage of the enterprise PKI.

Configure Role Separation at the CA

In addition to proper assignment of roles, you can enforce strict role separation by implementing the role separation registry setting for ADCS (Figure 4):

Certutil -setreg CA\RoleSeparationEnabled 1

Figure 4

Before you do this, one caution: this will force ADCS to only allow one role per account. If, for example, you have a user who is both a CA Admin and a Certificate Manager, with role separation enabled, they will not be able to perform either action. ADCS role separation role sets and only permits them to hold one. While this configuration is exceptionally strong at preventing misuse of the PKI, it can lock out your admins from administering the PKI at all! As such, you should have high confidence that your roles are properly assigned prior to changing this configuration setting. This setting is global meaning that it applies to any and all roles assigned to the PKI, not just the privileged roles.

Good news, however, is that if this happens during your testing, you can log into the CA directly and remove the role separation registry configuration. This will allow you to go back to proper configuration to resolve the overlapping identities or avoid this setting going forward but be aware of service interruption as a result.

It is possible to manage a secure PKI without this setting, however. It is one of many tools at your disposal.

Disable Request Attribute SAN (EDITF_ATTRIBUTESUBJECTALTNAME2)

Microsoft introduced strong certificate mapping limitations as part of KB5014754 in response to a number of CVEs that surfaced back in 2022 (CVE-2022-34691,CVE-2022-26931 and CVE-2022-26923). This protection makes exploitation of ESC6 difficult but not impossible. In concert with ESC9 or ESC16, this could still be exploited even with properly-patched domain controllers.

This misconfiguration (Figure 5) allows a requester to submit any subject alternative name (SAN) they want against a certificate template, even if the template does not allow it. To harden your CAs against this attack, you can make a registry change to disallow this behavior:

Certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Figure 5

It is important to note that if any other CA administrative escalation vulnerabilities exist, a threat actor can remove this attribute without difficulty. It does require a restart of the service, so monitoring your ADCS service health can help to identify unwanted changes.

Protect the ICertPassage RPC Interface

ESC11 is a more recent exploitation that allows relaying of NTLM authentication to RPC on a vulnerable CA. This could allow an attacker to request certificates on behalf of other domain principals. (Figure 6)

To harden your CAs against this attack, you can make a registry change to disallow this behavior:

Certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST

Figure 6

Note that this will force the CA to accept only RPC connections that are both signed and encrypted.

Check the CA Policy Module for Disabled Extensions

ESC16 covers another CA misconfiguration where a specific OID (1.3.6.1.4.1.311.25.2) is disabled in the CA Policy Module. This extension (szOID_NTDS_CA_SECURITY_EXT) will force the CA to omit a SID security extension in issued certificates which allows for exploitation of ESC6 and/or ESC7. This is functionally similar to ESC9, but this is a global setting whereas ESC9 is template-specific. (Figure 7)

To harden your CAs against this attack, review the disabled extension list on your CA:

Certutil -getreg policy\DisableExtensionList

Figure 7

If this specific OID (1.3.6.1.4.1.311.25.2) is in the disabled extension list (Figure 8), remove it:

Certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2

Figure 8

Figure 9

Wrapping Up

As I said at the beginning of this post, take your time setting up your CAs. If you configure them with proper protections from the word “go,” you will harden your PKI sufficiently to confound even the most determined adversaries.

Of the sixteen published ESC vulnerabilities, five of them are directly attributed to CA security misconfigurations (ESC 6, 7, 8, 11, & 16). In this blog post, we provided guidance for all of these except ESC8 which deals with Certification Authority Web Enrollment (CAWE), Certificate Enrollment Service (CES), Certificate Enrollment Policy (CEP), and Network Device Enrollment Service (NDES). In my introduction, I reinforced that your Certification Authority should be single-purpose. Do NOT install other ADCS roles on your CA. You introduce risks to which the CA itself should not be exposed. If you follow this guidance, ESC8 will not present a problem, but we will cover it in more detail in a future blog post.

In Part 5, we will dive deep into the configuration of your certificate templates to address a multitude of vulnerabilities that are present from oftentimes simple misconfigurations that can lead to big headaches.

M	T	W	T	F	S	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

Securing Your Certification Authorities (Practical PKI Part 4)