Microsoft 365 Security

Active Directory Certificate Services (ADSCS) is Microsoft’s Public Key Infrastructure (PKI) for typical Windows environments. There has been lots of blog posts on how to compromise an entire ADCS infrastructure, so I don’t want to repeat the same stuff over and over again. However, since ADCS is now a clear target with all the POCs that are available, and so on. It is required for Incident Responder to develop a solid understanding about such kind of attacks and how to respond to it.

The most common example from what I’ve read is a Certificate Template that has been misconfigured which allows an attacker to enroll to a (misconfigured) Certificate Template and impersonate any user within AD. This attack has been described as ESC1 by SpecterOps. During this blog post, we will be covering how we can investigate such attack and how to mitigate it.

Misconfigured Certificate Template – ESC1

In order to exploit this attack, the following pre-requisite is required:

Pre-Requisite:

• Manager approval is disabled –> mspki-enrollment-flag attribute needs to be set to 0x00000000
• No authorized signature is required –> msPKI-RA-Signature attribute needs to be set to 0x00000000
• Certificate Template allows a requestor to specify a SAN in the Certificate Signing Request –> msPKI-Certificate-Name-Flag attribute needs to be set to 0x00000001. This flag instructs the client to supply subject information in the certificate request.
• Certificate Template defines Extended Key Usage (EKU) that enables Client Authentication –> mspki-certificate-application-policy attribute needs to contain at least one of the following: Client Authentication (1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0) or no EKU (SubCA).
• Certificate Template needs to be published in Active Directory
• Non-Privileged user can enroll to the Certificate Template

To visualize how this Certificate Template looks like in PowerShell. We can run the following command:

$ADSI=[ADSI]"LDAP://CN=ESC1,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=cont
oso,DC=com" | Select name, msPKI-Certificate-Name-Flag, mspki-certificate-application-policy, msPKI-RA-Signature, mspki-
enrollment-flag

$ADSI

msPKI-Certificate-Name-Flag is set to 1, which means that SAN is allowed. mspki-certificate-application-policy contains Client Authentication (1.3.6.1.5.5.7.3.2) which means that there is a Client Authentication EKU. msPK-RA-Signature is set to 0 indicating that no authorized signature is required, and last but not least. mspki-enrollment-flag is set to 0 which means that managed approval is disabled.

This is how the vulnerable Certificate Template looks like in the GUI:

We can all enumerate all Certificate Templates that are exploitable for ESC1. This can be done by running the following command:

Get-ADObject -LDAPFilter '(&(objectclass=pkicertificatetemplate)(!(mspki-enrollment-flag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-ra-signature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2) (pkiextendedkeyusage=1.3.6.1.5.2.3.4))(mspki-certificate-name-flag:1.2.840.113556.1.4.804:=1))' -SearchBase 'CN=Configuration,DC=contoso,DC=com'

Exploiting Misconfigured Certificate Template

First, we will use Certify.exe to enumerate vulnerable Certificate Templates that can be exploited. This can be achieved by running the following command:

Certify.exe find /vulnerable

As we can see in this example. We can see the vulnerable Certificate Template that allows Authenticated Users to enroll to it.

At the second phase, we are going to request a certificate on behalf of the user ‘Testing‘ who is a Domain Admin account.

Certify.exe request /ca:ADCS.contoso.com\contoso-ADCS-CA /template:ESC1 /altname:Testing

The Certificate that we requested is a blob and in a PEM format. Copy the entire blob and save it as cert.pem

We will now have to convert the PEM format into a PFX format to allow us to request a Kerberos TGT of the account that we want to impersonate.

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

To finalize this, we will now request a TGT for the account ‘Testing‘

Rubeus.exe asktgt /user:Testing /certificate:cert.pfx /ptt

At the result, we can see that we have now impersonated this user account.

What is the impact?

The impact of this attack is that once an attacker can enroll to a vulnerable Certificate Template that allows ESC1. It can lead to a full AD Forest compromise. Certificate Templates are usually valid for at least a year, which means that an attacker can access resources on behalf of the impersonated user for a year.

Misconceptions

There is a lot of misconceptions around what to do when an attacker has enrolled to a Certificate Template that was exploitable for ESC1. I’d would like to address this issue for once and for all to avoid any unnecessary efforts that are taken when trying to remediate this.

• “What if we revoke all the Certificates that was requested by the attacker?”

At this example, we are revoking the certificate that the attacker was enrolled into.

To keep a long story short, but this would not prevent the attacker from requesting a Kerberos TGT of the user that was specified in the SAN.

• “What if we completely delete the Certificate Template?”

This won’t work either and the attacker can still request a TGT for the user that it was impersonating.

• “What if we decommission the compromised CA server?”

Let’s use the official guidance of Microsoft which can be found here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/decommission-enterprise-certification-authority-and-remove-objects

As we can see here, the ADCS server has been decommissioned.

All the associated AD objects that are in AD have been deleted as well.

When we are now using Certify to try and enumerate Certificate Templates. However, as we can see in this screenshot. There are no more ADCS servers anymore.

Even if have completely decommissioned this server. It won’t stop the attacker from requesting a Kerberos TGT of the user that was specified in the SAN.

How to investigate this?

Default logging in ADCS is very poor, which makes it hard to rely on traditional Windows event logs. However, every Certificate that has been issued will get logged. We can export all of this in a text file for further analysis.

This is how the text file will look like:

To find out the source of the machine that requested a Certificate. We can click on ‘View Attributions/Extensions‘ at Issued Certificates which will show us this:

A Certificate request was made from DC.contoso.com in this example.

How to stop the bleeding?

The only way to stop this would be to do a proper IR and figure out which accounts the attacker impersonated. Rebuilding ADCS servers or deleting Certificate Templates without doing any investigation will result into a big failure As we demonstrated in this blog post. We have impersonated the user ‘Testing‘

Since we know that the user account ‘Testing‘ was impersonated, we can start disabling or perhaps even delete the account from AD. This will result into the following:

Conclusion

Start treating ADCS as Tier-0 resources. When you have the feeling that ADCS has been compromised. The most important thing is to perform an IR investigation before rebuilding.