Petit Potam & ADCS


Recently published ADCS and PetitPotam exploits can be abused to compromise a domain from non-domain joined Windows 10 host without any domain credentials.

Recently Will Schroeder and Lee Christensen released a blog post and white paper detailing several potential attack paths within Active Directory Certificate Services. Unfortunately, it seems attention was diverted (and honestly rightfully so) to the PrightNightmare CVE, patches, and follow up CVEs. Then there was SeriousSam – Oh, and then PetitPotam.

It’s been a rough month for Microsoft.

In Will and Lee’s blog post, the ESC8 attack path stuck out the most since it can relay coerced NTLM authentication attempts and the web based certificate enrollment services are vulnerable to relay attacks in its default configuration.

This attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled machine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine account to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Dementor.

Ex Android Dev built on Will and Lee’s research releasing a proof of concept to perform the certificate request on behalf of the relayed account utlizing the print spooler “bug”. Their updated version of ntlmrelay can forward coerced authentication and submit a CSR and acquire the certificate for the relayed user. In the POC’s case, the Domain Controller. They’re then able to request a ticket granting ticket as the relayed Domain Controller machine account, inject the ticket into their sessions, then perform a dcsync and own the domain.

Petit Potam & ADCS

Now the great thing about PetitPotam is it can coerce authentication from a Domain Controller without needing credentials and utilizes MS-EFSRPC rather than MS-RPRN like you’d find with similar Print Spooler attacks.

So, I wanted to modify ExAndroidDev’s attack and just swap out the tools to see what it would look like from a bit of a blackbox approach as an attacker with 0 privileges in a domain – no credentials and no remote access

Attack Scenario

ADCS Discovery

I set up ADCS in my sandbox domain with the default configuration without modifying any ACLs or setting up any services – just setup the CA from the server manager deployment and started testing.

From a basic nmap service discovery scan, you can see the default self-signed certificate for the CA in the format of “hostname-CA”. In my case, I needed to redeploy certificate services a few times so you’ll notice it’s “hostname-CA-2”. I didn’t want to modify anything for the sake of testing and left it as is.

1. NTLM Relay to ADCA

Knowing where the CA is, setup the coercion and relay to request a certificate on behalf of the domain controller.

python3 -t --adcs --template domaincontroller

2. TGT Request

From a non-domain joined Windows 10 host without any domain credentials, point DNS to the domain controller and use the captured Base64 certificate blob to request a TGT.

Setup the TGT request with Rubeus and inject the ticket into our current session.

Rubeus.exe asktgt /user:DC01$ /certificate:MIIRZQIBAzCCES8GCSqGSIb3DQEHAaCCESAEghE---snip--- /ptt /domain:corp.local /dc:dc01.corp.local


Then perform a DCSYNC with mimikatz and collect the loot.

lsadump::dcsync /domain:corp.local /user:administrator