Skip to main content

PKI Compromise by Default

Certificate Authorities. They’re an invisible elephant in the room. They’re the colourless passport stampers that complement your inscrutable active directory certificate processes. The whole thing sounds very grey and bureaucratic, but threat actors and security wizards are looking at the certificate process very closely, and for good reason. Those passports can do quite a lot. In this article we’ll cover a few basic concepts and then look at a new crop of vulnerabilities discovered by the piratical and quite naughty SpectreOps. The aim of this post is not to make you an authority on certificate services, it’s to show you that there are distinct risks in deploying certificate services and provide you with a tool to audit for some of these.

In case you are unaware, SpectreOps are the vendors that produced several cutting-edge open-source tools for Active Directory enumeration. They are also shaking up the way the security industry views vulnerability management by introducing their own unique philosophy which has a core focus on attack pathway management, a philosophy which J2 had adopted in their insider threat assessment where we simulate human-operated ransomware attacks in our client environment as part of our red-teaming activity.

On June 17th, SpectreOps released a whitepaper and blog post titled, “Certified Pre-Owned” in which they laid out the details of a range of serious vulnerabilities in misconfigured Active Directory Certificate Services. The post was a pre-release for their upcoming talk at Black Hat USA 2021 in which they would present the exploitation tools to the public to achieve domain compromise via PKI.  The white paper is available here.

Will Schroeder and Lee Christen focused on key aspects of windows Certificate Services such as the capability to use certificates for user authentication, encrypting file systems and digital signatures. These features are widely deployed in both SME’s and enterprise level networks. They examined the attack surface area and showed how certain weaknesses could be exploited.

In a nutshell

There are books written on certificate services that could be used as stepladder, but I’ll try to minimize the pain.  Certificate services involves the issuing of a certificates that can be used for message signing, encryption, and authentication. You could make an analogy with the tickets assigned by Active Directory Kerberos. Certificates operate as a proof of identity, and they are issued by the certificate authority (CA.)

To receive a certificate a client must request a certificate from the CA using a certificate signing request (CSR). The CA looks at the content of the certificate and matches it to what is known as a certificate template. The CA checks the templates corresponding active directory objects permissions allow for the requesting account to obtain a certificate. If it does, it generates the certificate using the template settings. The CA signs the certificate using its own private key and returns it to the client.

SpectreOps has highlighted 4 of many results of PKI abuse:

  1. Threat actors (TA) can steal existing user certificates that could be used for domain authentication. As SpectreOps has highlighted these certificates are valid even if you change the password on the account.
  2. Theft of system certificates capable of authentication to the domain. These would survive computer account password changes.
  3. Misconfigured certificate templates which would allow you to piggyback your own account on the certificate by writing an entry and several other possible attacks.
  4. Stealing the certificate authority’s private key which would allow you to forge any type of certificate. SpectreOps dubs this a ‘golden’ certificate attack.

You should keep these concepts in mind:

  • PKI (Public Key Infrastructure) — a system to manage certificates/public key encryption
  • AD CS (Active Directory Certificate Services) — Microsoft’s PKI implementation
  • CA (Certificate Authority) — PKI server that issues certificates
  • Enterprise CA — CA integrated with AD (as opposed to a standalone CA), offers certificate templates
  • Certificate Template — a collection of settings and policies that defines the contents of a certificate issued by an enterprise CA
  • CSR (Certificate Signing Request) — a message sent to a CA to request a signed certificate
  • EKU (Extended/Enhanced Key Usage) — one or more object identifiers (OIDs) that define how a certificate can be used

This blog will principally cover Domain Privilege Escalation and Domain Persistence Pathways.

  • Domain Privilege Escalation Pathways

Misconfigured Certificate Templates - ESC1

The Attack Pathway

If an attacker can specify the subject alternative name (SAN) in a certificate service request (CSR), the requester can request a certificate as anyone (e.g., a domain admin user).

The following permissive CA settings allow abuse of this escalation pathway type:

  1. The Enterprise CA grants low-privileged users enrolment rights. (Bad idea, but typical)
  2. Manager approval of requested certificates is disabled (bad idea, but common)
  3. No authorized signatures required
  4. An overly permissive certificate template grants low-privileged users enrolment rights
  5. The certificate template defines EKUs that enable authentication
  6. The certificate template allows requesters to specify a different subject alternative name (subjectaltname)

Misconfigured Certificate Templates - ESC2

The Attack Pathway

An attacker can use a certificate with the Any Purpose EKU feature for any purpose including client and server authentication. An attacker can use a certificate with no EKUs for any purpose too, but also to sign new certificates.

As such, using a subordinate CA certificate, an attacker could specify arbitrary EKUs or fields in the new certificates.

The following permissive CA settings allow abuse of this escalation pathway type:

  1. The Enterprise CA grants low-privileged users enrolment rights. (Bad idea, but typical)
  2. Manager approval of requested certificates is disabled (bad idea, but common)
  3. No authorized signatures required
  4. An overly permissive certificate template grants low-privileged users enrolment rights
  5. The certificate template defines any purpose EKUS or no EKU
  6. The certificate template allows requesters to specify a different subject alternative name (subjectaltname)

Enrollment Agent Templates — ESC3

The Certificate Request Agent EKU allows a principal to enrol for a certificate on behalf of another user. For anyone who enrols in such a template, the resulting certificate can be used to co-sign requests on behalf of any user.

The following permissive CA settings allow abuse of this escalation pathway type:

  1. The Enterprise CA grants low-privileged users enrolment rights. (Bad idea, but typical)
  2. Manager approval of requested certificates is disabled (bad idea, but common)
  3. No authorized signatures required
  4. An overly permissive certificate template grants low-privileged users enrolment rights
  5. The certificate template defines the certificate request agent EKU
  6. Enrolment agent restrictions are not implemented on the CA

Vulnerable Certificate Template Access Control — ESC4

Certificate templates are securable objects in active directory, which means within their ‘security descriptor’ they specify which active directory principals have specific rights over the template. The template would be considered misconfigured at the access control level if it allows for unintended or unprivileged principals to edit the security settings. An attacker could push a misconfiguration to a template that allows them to compromise elements of the active directory domain.

Chris Falta discussed a method to use this misconfiguration to impersonate a domain user, modify a template to allow for virtual smartcard enrollment, get the certificate and then reset the template.

The blog can be accessed here.

EDITF_ATTRIBUTESUBJECTALTNAME2 — ESC6

This title should have flames around it.

Essentially there is a flag set on the certificate authority known as the subject alternative name. If this is enabled, then any certificate template configured for authentication on the domain can be exploited to allow domain admin authentication. People generally choose this setting because it makes a lot of things work.

It’s sort of like using a single enterprise administrator account for every service and application on your network or dropping your firewall because you can’t be bothered to find out which ports your application uses. Both Russia and China thanks you for this. You will receive a courtesy termination notice during the next breach.

Vulnerable Certificate Authority Access Control — ESC7

A certificate authority also has permissions accessed through the certsrv.msc command. There are two that are important:

  1. ManageCA (CA Administrator
  2. ManageCertificates (Manager Approval) permissions. These permissions should be audited.

The ManageCA permission allows a principal to perform several administrative actions including modification of the configuration data. The ManageCertificates permission allows the user to approve pending certificates.

NTLM Relay to AD CS HTTP Endpoints — ESC8 (petit-potam)

For some reason (primarily Benjamin Delpy) the French have latched onto this vulnerability and named it “the little hippo.”

At its most basic level, you can force a domain controller to make a request back to your device. If you execute certain software on your device, you can grab the credential hash. You can relay the hash taken from the domain controller against certain versions of certificate services, you can grab the certificate of the domain admin. If you get a certificate, you can pretty much do anything.

It uses the NT Lan Manager authentication protocol. NTLM in general and version 1 are particularly bad egg. Microsoft knows it’s bad but continues to enable it by default on new installations. Microsoft initial recommendation with this CVE, is to disable NTLM. You can read their latest review at https://msrc.microsoft.com/update-guide/vulnerability/ADV210003.

It’s our understanding the initial communication exploits the exposed print spooler service on the domain controller (Seen here as lsarpc.) Disable the print spooler service on your domain controllers. It also relies on the presence of an HTTP based certificate web enrollment platform. You should remove it from your certificate authority. Http is non encrypted and it’s bad.

 a Connect to domain controller
 Fig a Connect to domain controller, force connection back to attacker box to steal credential hash

 

 b Receive hash and relay to certificate server
 Fig b Receive hash and relay to certificate server

 

 Gain certificate to give full privilege
 Fig c Gain certificate to give full privilege
  1. Domain Persistence

Let’s say for interest’s sake your environment has been breached before and the threat actor achieved domain administrator rights. If they could steal the Enterprise CA root certificate private key that is used to sign new certificates, they would be able to forge their own certificates to authenticated to active directory.

SpectreOps notes this has already been possible with the offensive tool Mimikatz created by Benjamin Delpy. As Benjamin points out, these certificates can’t be revoked because they were never actually issued. You can set your own expiry date.

Testing for Misconfigurations

Testing for Misconfigurations

The good news, you don’t have to fiddle around in your Certificate Authority.

SpectreOps has kindly released an auditing utility which can be downloaded at:

https://github.com/GhostPack/PSPKIAudit.git

Mitigation suggestions will be included in the auditing tool upon discovery. Be cautious with implementing mitigations if you don’t fully understand the fix. Be cautious should be surrounded with flames.

Install Procedure

  1. Get-WindowsCapability -Online -Name "Rsat.*" | where Name -match "CertificateServices|ActiveDIrectory" | Add-WindowsCapability -Online
  2. cd PSPKIAudit
  3. Get-ChildItem -Recurse | Unblock-File
  4. Import-Module .\PSPKIAudit.psm1
  5. Invoke-PKIAudit

Mitigation

The audit tool will search for misconfigurations and generate mitigation suggestions. Some of these are simple. In the case of ESC8, simply disable http web enrollment and your domain controller print spooler services. Shouldn’t be using HTTP anyway. Others, such as in the case of ESC6 involve disabling a certain CA flag and restarting the server.

Your other best solution is stop using Active Directory and move your environment to Azure in its entirety.

Most of the changes involve removing weak configuration settings and hoping it does not break part of your infrastructure.

Detection

Abusing PKI infrastructure can be tricky to log. J2 currently offers detection of the ESC8 via detection of access to the print spooler service, and more particularly the file create event for C:\Windows\System32\spool\drivers\x64\3\New\FXSRES.DLL. We are studying the vulnerabilities and working on additional correlation rules.

Conclusion

Your certificate authority should be considered in your data flow diagrams, and your vendor should be including it within your assessments. Limited offensive tooling has been released for these vulnerabilities, and further tooling will be released next week after SpectreOps present their findings at the Blackhat conference. We have no doubt that ransomware operators are looking at these vulnerabilities with the intention of incorporating them into their attacks. It may not be the most interesting topic in the world, well, it may not be the second or third most interesting topic in the world, but its part of your attack surface area and at its worst it gives complete access, bypassing standard credentials. If you look closely at that grey, colourless little certificate authority you’ll see a golden key in his back pocket. That’s the key to your kingdom.

GM
J2 CSC

  • Hits: 1003