Securing Your Certification Authorities (Practical PKI Part 4)

Hello, I’m Ron Arestia, a Security Researcher with Microsoft’s Detection and Response Team (DART). We are here to help customers handle cybersecurity incidents, focusing on containment and recovery from potential threats. In today’s blog post, we aim to improve the security stance of Public Key Infrastructure (PKI) by prioritising a crucial element: your Certification Authorities (CAs). This is the fourth part of a series on practical PKI implementation, drawing on my experiences interacting with customers in my role at Microsoft.

If you’d like to refresh your memory, feel free to check out the earlier posts, or dive straight into this one.

Secure Configuration and Hardening of Active Directory Certificate Services

For those about to embark on this journey, I recommend reviewing the SpecterOps Exploitation of Certificate Services framework. This framework acts as the industry standard for securing your PKI. If you fail to guard against misconfigurations, malicious actors may exploit them against you.

Please note: I will not be showcasing any red team or hacking tools in this blog post out of precaution. Countless resources explain how to use these tools against an ADCS PKI. My aim is to share best practices and help you think like a defensive security professional focused on PKI.

Throughout this and future posts, I will reference the Exploitation of Certificate Services framework as ESC and highlight specific ESC vulnerabilities. I encourage you to cross-check this information with your own findings to grasp how misconfigurations can be exploited.

If you’ve just joined this blog series, I recommend revisiting previous posts concerning root CA security and best practices. There’s a wealth of information out there, so I’ll keep this section brief and concentrate on downstream security concepts.

When a root CA is genuinely offline and secured with a Hardware Security Module (HSM), the risk of compromise is quite low, though not entirely absent. I’m not aware of any specific anecdotal cases involving the compromise of an offline root CA, but I’m sure a Hollywood script could spin quite a tale. In reality, most hackers typically navigate through an enterprise using identity pathways, with the PKI infrastructure becoming a tempting target once they gain domain dominance. While air-gapping your root CA doesn’t render your enterprise immune to PKI attacks, it does ensure that your core trust anchor is well protected, enabling a swift reconstruction of subordinate infrastructures compared to a complete PKI overhaul.

Remember, your root CA, like all root CAs, uses a self-signed certificate. Though this certificate itself may seem unremarkable, it plays a crucial role in signing all subordinate, issuing, and registration authorities, alongside all certificate revocation lists (CRLs). If a threat actor cannot breach the root CA, during a cybersecurity incident affecting the subordinate infrastructure, the affected organization can promptly revoke all certificates from subordinate authorities, adding them to the CRL. This action will then invalidate all certificates issued by those subordinate CAs. Rebuilding the subordinate infrastructure securely means your organization only needs to restore the issuance and registration capability while maintaining the trust of the root within the whole organization. This significantly shortens the recovery time since the root infrastructure remains trusted across the company.

If your root CA is not offline, it absolutely should be. You cannot sufficiently mitigate risks related to your PKI if the root CA is joined to the enterprise. If your root CA is also your primary issuer, consider migrating to a two-tier PKI hierarchy after evaluating your requirements and impacts. Threat actors are drawn to the highest levels in your organization’s technical hierarchy. If the root CA is online, they will locate it and likely find a way to exploit it.

One important tip during this process: take your time. There’s no need to rush your PKI implementation. As the saying goes, “Haste makes waste.” While it’s certainly possible to establish a servicing infrastructure quickly, you risk overlooking critical security controls, putting your organization at risk. Carefully document 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 for managing the CA, templates, and issuance. Documentation should comprise most of your PKI development time. A solid framework facilitates the rest.

Your issuing CAs will be central to your PKI operations. Do not install additional services on your issuing CAs. Their sole function is to serve as enterprise issuing certificate authorities. The only service that should be installed on these systems is the ADCS Certification Authority role. Do not install the CA role on a domain controller. (This cannot be emphasised enough!) Avoid installing any other Windows roles or features, even if they are part of the ADCS role. Every added role on the issuing CA increases both the risk it faces and your administrative load. Keep third-party tools, agents, services, APIs, etc., to an absolute minimum. If this is set up in a Tier 0 environment with proper segmentation, the associated risk should be significantly diminished. PKI is a Tier 0 system! Treat it with the same security measures as your domain controllers.

For both offline root and issuing CAs, if a private key is stolen, it constitutes a persistent threat to your domain, and the CA should be regarded as breached, even without any evidence of data theft.

Before kicking off your PKI implementation, set up a few new security groups in Active Directory to manage your CAs, templates, and issuance successfully. By default, ADCS assumes that Domain Admins and Enterprise Admins will oversee your PKI. Do not leave this configuration unchanged. This approach doesn’t adhere to any least privilege guidelines and leaves your PKI vulnerable to direct or indirect compromise through account lateral movement if either of these groups is breached.

To oversee your issuing CA, create a security group called “CA Admins,” or something similar that fits your naming conventions. The CA Admins will handle the management of the CAs themselves. They will be responsible for opening the Certification Authority management console (MMC), adjusting CA configurations as needed, executing signing operations (e.g., manual CRL issuance), revoking certificates, performing backups, and overseeing the overall health of the PKI. (See Figure 1)

Figure 1

Next, to manage certificate issuance in your enterprise, create another group called “Certificate Managers,” or a name that suits your organisation. Certificate Managers will oversee pending certificate issuances. This should be a small, trusted group of admins trained to assess certificate requests and issue them according to your established security and risk standards. (Refer to Figure 2)

Figure 2

Each of these groups will be configured in the ADCS certification authority MMC with their respective rights. These are single-purpose groups. None should possess the authority to request certificates, and ideally, their memberships shouldn’t overlap. The principle here is to ensure role separation; for instance, nobody should be able to both request and approve their own certificate.

To handle certificate templates within your organisation, establish a group named “Certificate Template Managers,” or a name that suits your needs. These managers will be responsible for creating, and managing all certificate templates. Members should be proficient in certificate template creation, careful provisioning of new templates, and managing access control lists (ACLs) on those templates. They are your first line of defence against misconfigured templates that could lead to security breaches via various Exploitation of Certificate Services (ESC) methods. Note: manipulating a container within the Active Directory Configuration partition may be required, and may not be necessary if Certificate Managers are sufficiently constrained. (See Figure 3)

Figure 3

The configurations set during the establishment of the PKI should shield you from exploitation related to ESC7 specifically and create a narrow attack vector for any malicious actors. However, remember that this isn’t a foolproof solution and doesn’t account for administrative account exploitation. If a malicious actor gets hold of an administrative account, they can access all permissions linked to that account. This highlights why role separation is crucial for effective PKI management. In a significant cybersecurity incident, a threat actor would need to breach several accounts to exploit the entire enterprise PKI.

In addition to correctly assigning roles, you can enforce strict role separation by applying the role separation registry setting for ADCS (See Figure 4):

Certutil -setreg CA\RoleSeparationEnabled 1

Figure 4

However, be cautious: enabling this feature will restrict ADCS to one role per account. If a user is both a CA Admin and a Certificate Manager, with role separation enabled, they won’t be able to perform any task. As useful as this configuration is for preventing PKI misuse, there is a risk of accidentally locking out administrators. Thus, ensure your role assignments are accurate before changing this setting. This global setting impacts all roles assigned to the PKI, not just the privileged ones.

The good news is, if you encounter this issue during testing, you can access the CA directly to remove the role separation registry change. This allows you to revert to the proper configuration to resolve any conflicts, but be aware that service interruptions may occur as a result.

You can indeed manage a secure PKI without this setting, although it’s just one of the multiple tools available for safeguarding your infrastructure.

Microsoft implemented robust certificate mapping restrictions as part of KB5014754 in response to various CVEs identified in 2022 (CVE-2022-34691, CVE-2022-26931, and CVE-2022-26923). These safeguards render the exploitation of ESC6 challenging but not impossible. Alongside ESC9 or ESC16, vulnerabilities could still be exploited, even with fully patched domain controllers.

This misconfiguration (See Figure 5) permits requesters to submit any subject alternative name (SAN) against certificate templates, irrespective of whether the template allows this. To secure your CAs against such attacks, implement a registry change to prevent this behaviour:

Certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

Figure 5

It’s essential to recognise that if other vulnerabilities for CA administrative escalation are present, a malicious actor could easily remove this attribute. Since this change requires a service restart, consistently monitoring your ADCS service health can help identify any undesirable modifications.

ESC11 describes a newer exploitation technique that allows NTLM authentication to be relayed to RPC on a vulnerable CA. This could enable an attacker to request certificates for other domain principals (See Figure 6).

To bolster your CAs against this risk, implement a registry change that disallows this behaviour:

Certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST

Figure 6

Be aware that this will enforce the CA to accept only RPC connections that are both signed and encrypted.

ESC16 highlights another CA misconfiguration in which a specific OID (1.3.6.1.4.1.311.25.2) is disabled within the CA Policy Module. This extension (szOID_NTDS_CA_SECURITY_EXT) causes the CA to omit the SID security extension in issued certificates, making it susceptible to exploitation through ESC6 and/or ESC7. This issue is similar to ESC9 but acts globally as opposed to template-specific (See Figure 7).

To secure your CAs against this issue, first, check 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) appears in your disabled extension list (See Figure 8), remove it as follows:

Certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2

Figure 8

Figure 9

As I mentioned at the start, take your time in configuring your CAs. A thorough setup with the right protections from the outset will harden your PKI sufficiently to deter even the most determined adversaries.

Out of the sixteen known ESC vulnerabilities, five are directly linked to CA security misconfigurations (ESC6, 7, 8, 11, & 16). In this post, we’ve tackled 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). I want to emphasise the importance of keeping your Certification Authority single-purpose. Avoid installing other ADCS roles on your CA as it could expose it to unnecessary risks. By adhering to this advice, you’ll sidestep issues related to ESC8, which we will discuss in more detail in a future blog entry.

In Part 5, we’ll explore the configuration of your certificate templates in depth, highlighting numerous vulnerabilities that often stem from simple misconfigurations, which can lead to significant issues.