After our last blog articles dealt with more general infrastructure topics (user installation, server deployment), this time we would like to focus more on a security topic. In almost every IT infrastructure there is a certification authority that issues certificates, e.g. for SSL, code signing or smart card logins. Many of our customers use a Microsoft-based Certification Authority (CA) or Public Key Infrastructure (PKI). CA services are quick to install, and in just a few steps you have configured the CA so that it can already issue certificates. But – hand on heart – who really fully understands a PKI hierarchy and the entire configurations and would call themselves an expert? Our experience is rather that PKI structures exist almost everywhere, but are treated very stepmotherly and often contain outdated or faulty configurations.

In this article, we would like to describe potential attack paths, starting from CA services, and, above all, how to identify and eliminate these vulnerabilities.

The basis is provided by the outstanding whitepaper from SpecterOps, which is linked and described here: https://posts.specterops.io/certified-pre-owned-d95910965cd2

Background

In June 2021, Will Schroeder published a post called Certified Pre-Owned, in which he describes having dived deep into the world of PKIs over the past few months and finding some vulnerabilities. Essentially, three components are important to us:

• Blog for a first overview
  – „Certified Pre-Owned“
• Whitepaper for those who want to deal with the topic more intensively on 150 pages
  — „Certified Pre-Owned: Abusing Active Directory Certificate Services”
• Defensive Toolkit, which we will discuss in more detail later.
  — „PSPKIAudit (based on PSPKI)“

At this point, we would only like to briefly discuss the vulnerabilities we found. If we were to document them in detail, we could probably write a separate blog article for each vulnerability. In addition, as mentioned above, there is already detailed information available in Will Schroeder’s blog and the whitepaper, which really go into great depth. Still, it is important to understand how a potential attack works.

First, let’s start with the threat landscape. With the vulnerabilities found, it is possible to impersonate any user or system in an Active Directory domain! So that includes highly privileged accounts like Domain Admins or the like. So, similar to pass-the-hash or pass-the-ticket attacks, we are dealing with a very serious threat situation here. In short, an attacker can issue an arbitrary certificate and impersonate a domain admin, for example. If we have been used to changing our password in case of suspicion, for example, this attack makes no difference whatsoever to the user’s password. We only need a valid certificate and regardless of whether the user has already changed his password, we can authenticate ourselves using a certificate.

However, in order for an attack to be carried out, some requirements must be met. However, one is surprised how often one finds customer environments where the prerequisites are met.

Not every certificate template is suitable for our purposes. It must contain one of the following uses:

• • Client Authentication
  • PKINIT Client Authentication
  • Smart Card Logon
  • Any Purpose
  • SubCA

For some attack paths, a Subject Alternative Name is also required. Whether this is allowed is also set in the certificate template. However, this setting can also be configured “centrally” and thus be specified for all templates. More about this later.

Finally, my user or system also needs enrollment permissions on the corresponding template. This reads as a high hurdle, but in many environments it is quite common to roll out email or smart card certificates to almost every user. Or think of the application owner who may need a web server certificate for his application.

In addition to an attack via certificate templates, SpecterOps also describes attack paths in which parts or the entire CA can be taken over. If I can manage the CA, I could also generate a corresponding template and carry out an attack.

As mentioned earlier, however, we don’t want to dive too deeply into the individual attacks. If you are interested, you can read the whitepaper in detail. We would rather focus on preventing these attack paths and only list the individual paths with a short description here. By the way, the designations ESC<number> are from the SpecterOps blog or whitepaper. So you can search for them if you need more information.

From our point of view, the threat can be summarized as an attacker gaining control over templates or CA settings via misconfigurations and thus issuing certificates that can be used for further attacks. Considering that certificates retain their validity even if an account changes its password, this is an exciting and effective way for an attacker to spread throughout an organization and continually expand its privileges.

With the description so far, we want to ensure a basic understanding of the different attack possibilities. Should you not understand every attack, that is not a big deal in our opinion. If you want, you can read the much-cited whitepaper and get knee-deep into the subject matter. More importantly, we acknowledge that there is a to-do here and that your own PKI structure should be reviewed urgently.

The good news is, there are already tools available to help you simplify the analysis. We will discuss these in more detail in the next section.

How can I verify my PKI?

So we will now check the CA and go into the results. But with which tool do you actually do that?

Specter Ops published a toolkit along with the whitepaper that can be used to audit all the described attack paths (ESC1-8). The toolkit is based on the PSPKI project and is called PSPKIAudit. The tool is explained quite quickly, there are two modules that are interesting for us.

1. 1. 1. Invoke-PKIAudit – Audits the current Forest’s AD CS settings, primarily analyzing the CA server and published templates for potential privilege escalation opportunities.
      2. Get-CertRequest – Examines a CA’s issued certificates by querying the CA’s database. Primary intention is to discover certificate requests that may have abused a certificate template privilege escalation vulnerability. In addition, if a user or computer is compromised, incident responders can use it to find certificates the CA server had issued to the compromised user/computer (which should then be revoked).

Invoke-PKIAudit can therefore be used to check the current CA configuration and the existing certificate templates for the ESC1-8 attack paths. Get-CertRequest in turn checks all certificates issued by the CA. Here, however, some effort has to be planned for the analysis, but more on that in a moment.

Let’s first take a look at what Invoke-PKIAudit displays for Findings. The screenshots are from a test environment. In reality, the output can be much larger. It depends on the number of certificate templates in the environment.

First, the CA configuration is checked and in our example we see that our CA configuration is open for the attack paths ESC6 and ESC8.

ESC6 describes an attack via the CA flag “EDITF_ATTRIBUTESUBJECTALTNAME2”. As explained briefly above, this flag allows an attacker to specify a Subject Alternate Name for any certificate request. Whether this is allowed in the template or not is irrelevant here, as the CA configuration already allows this. As always, it is extremely dependent on the local conditions how this circumstance is handled. One thing is for sure, it should not stay this way. In our customer deployments, we have many discussions with our customers and first try to get an overview of the overall situation before making a final decision and sorting out the problem. We don’t see any major reason to configure this flag on a CA. If I absolutely need SANs for certain certificates, I can also configure that in the certificate template in question. Alternatively, or even complementarily, this also helps with actually all attacks the Manager Approval configuration. This means that certificates are only issued when a CA manager has viewed and explicitly approved the request. Depending on how many certificates such a CA issues, this is a certain effort, but certainly one of the best levers we have at our disposal.

By the way, in the screenshot below we also see that a template that does not allow a SAN is still vulnerable:

Misconfiguration is empty in this case, but at the very top of the screen the flag is pointed out and a potential vulnerability.

In addition to ESC6, however, we also see ESC8 as a possible attack path in the screenshot. ESC8 describes an NTLM relay attack on the http endpoints of a CA. If you don’t know exactly what an NTLM Relay attack is, you can read up on it here. Endpoints of a CA can be the rollout interface certsrv, the CES/CEP service needed for cross-forest certificates or the NDES interface. In our opinion, there are only two ways to protect against ESC8. Either you can disable the service completely, or you switch from http to https. Now this is not easily possible. At least there are a few scenarios where https would not be possible, for example. From our experience it makes sense to check again exactly which certificates are needed where and whether the current procedure for certificate distribution cannot be fundamentally adapted.

In our test, more templates were categorized as vulnerable. To be honest, this is where it gets a bit tricky and it is difficult to make a blanket judgment here. We would like to make it clear that it makes sense to intensively discuss the exact procedure. Below we see a template that is vulnerable to ESC1 according to the PSPKIAudit.

Four main themes come together here.

1. 1. 1. Low-priv users have access to this template. In this case, the domain users. If necessary, this group could be made smaller, but presumably that’s the purpose of us wanting to distribute the template widely.
      2. The template is set to “Supply in the request”, which means that the requestor can configure any subject. Here we could automatically assemble the information from the AD if necessary. This probably seems best to us for a certificate like this.
      3. Client Auth and Smart Card Logon are EKUs here, which can be used for Domain Authentication. Just as with Low Priv Users, we would therefore assume that this is exactly the purpose – to roll out SmartCard certificates. So removing the EKUs is probably not an option. If necessary, point 2 can help even more.
      4. In addition, there is no manager approval – this would be another security measure, since a manager first checks whether unwanted information (e.g. a high priv user as subject) is contained in the request. However, since the user group with domain users is very large, this would require a lot of effort.

The ESC1 example illustrates why it is so difficult to react appropriately here. The regular verification of already issued certificates can also help here, more about this below.

In the next screenshot we would like to briefly discuss ESC4. You might not believe it, but we have seen exactly this error quite often in real environments.

ESC4 means that a faulty ACL could allow unauthorized users to modify the template and, for example, allow SANs. Here, the “FullControl” permission for the Authenticated User group bothers us. This misconfiguration mostly occurs in “historically grown” environments where nobody really dares to question and adjust existing settings. Authenticated users definitely do not need a full control right on a certificate template. This permission simply has to be removed. The same applies to the Write right.

We hope that these explanations have simplified an initial introduction to the topic. If you would like us to assist you with a CA analysis, just get in touch with us – we’ll be happy to help 😊.

Finally, we would like to address the question of whether suspicious certificates have already been issued in the past.

Are suspicious certificates already present?

With the Get-Certrequest command, every certificate issued by the corresponding CA is output and must be analyzed. There is no automatism here, but you have to check the certificates yourself. For this reason, it is a good idea to save the results in a CSV. This may simplify subsequent analysis by means of appropriate scripts. The following is an example output from our test environment.

If the first and second certificates are still inconspicuous, we find that a SAN is defined for the third. Among other things, the SAN administrator@test-teal.internal is defined. However, the requestor name was cea.t0.CertUser. This discrepancy should at least cause us to question exactly why this configuration is needed. Presumably, however, this would be a more than suspicious certificate that should be revoked immediately. Basically, we recommend paying attention to whether the requestor and subject/SAN match. If not, it must be explainable, otherwise the certificate should be revoked. Depending on how many certificates the CA has issued, the check is correspondingly time-consuming, but should still be performed.

Our conclusion

Our conclusion after the publication of the vulnerabilities last year is that a PKI audit is definitely worthwhile. In addition to the vulnerabilities described above, we always find optimization opportunities that we implement together with our customers. The good thing is that with PSPKIAudit there is already a tool that administrators can use. Admittedly, you still have to deal with the topic of PKI, but that’s what this blog article is for, for example 😊.