Protect Your Windows Network from the PetitPotam Exploit

PetitPotam is a recently discovered exploit that allows an attacker to relay NTLM credentials without authentication from a domain controller (DC) to an Active Directory Certificate Services (AD CS) Web Enrollment service to request a DC authentication certificate along with the private keys. Once this certificate and private keys are obtained, the attacker can request a ticket-granting ticket (TGT) for the DC that had its NTLM credentials relayed and can easily gain control of the entire domain.

The most important points to note are:

An attacker only needs network access to the AD CS Web Enrollment service web portal and a DC through commonly available ports.
An attacker does not need a domain account, domain-joined computer, or any additional credentials.

Microsoft’s Updates and Recommendations

Microsoft has published KB5005413 to provide acknowledgement and remediation strategies for the PetitPotam exploit. Microsoft also released a security update on August 10, 2021, to help mitigate PetitPotam. The remediation steps in KB5005413 and in this article should be used in conjunction with Microsoft’s security update. For more information, see Microsoft’s CVE-2021-36942 Security Update Guide.

How the PetitPotam Exploit Works in Six Steps

Figure 1 and the following text detail the steps in an NTLM Relay attack utilizing the PetitPotam exploit.

Figure 1 – Steps in an NTLM Relay attack utilizing PetitPotam

Step 1: Set Up NTLM Relay

An attacker sets up NTLM Relay using software such as ntlmrelayx on a Kali Linux installation to request a DC certificate template from the PW-01 AD CS Web Enrollment server, as Figure 2 shows. The relay will wait for a DC NTLM authentication request and eventually forward it later in the attack. The relay can request certificates from critical certificate templates, including the Domain Controller Authentication template and the Kerberos Authentication template.

Figure 2 – The attacker sets up the NTLM relay; note that the target is the .asp site presented by the CertSrv web service and the request is for a certificate from the DomainController template

Step 2: Attack is Executed

The attacker uses Mimikatz/PetitPotam as Figure 3 shows to execute an attack against DC-01, triggering NTLM authentication to the Kali installation. The attacker can do this by abusing the Encrypting File System Remote Protocol (MS-EFSRPC), which causes the DC to attempt NTLM authentication over what should be an authenticated connection.

Figure 3 – The attacker uses Mimikatz to trigger NTLM authentication from a DC to the NTLM relay

Step 3: NTLM Authentication

DC-01 sends the NTLM authentication request to the attacker’s Kali installation.

Step 4: DC Certificate Requested

The attacker’s Kali installation receives the NTLM credentials and sends a request for a DC certificate to PW-01 using the DC-01 NTLM credentials, as Figure 4 shows.

Figure 4 – The Kali Linux installation authenticates against the AD CS Web Enrollment services and begins generating a certificate request

Step 5: Fraudulent DC Certificate Issued

PW-01 receives the fraudulent DC certificate request and forwards it to the internal issuing Certification Authority (CA), CA-01. Believing it to come from a valid DC, CA-01 issues a certificate for DC-01, as Figure 5 shows.

Figure 5 – The attacker receives a valid DC certificate template back from the issuing CA

Step 6: NTLM Relay Exploit Completed and Attacker’s Next Steps

Once the attacker’s fraudulent certificate request is completed and returned, the attacker has a certificate issued to DC-01 from the Domain Controller Authentication template with its own private key generated during the attack. The attacker can then simply copy and paste the returned certificate and impersonate the attacked DC. For example, the attacker can use a tool such as Kekeo to request a TGT and follow up with a pass-the-hash attack using Mimikatz to gain domain administrator credentials. At this point the domain being attacked is now completely compromised.

Identify If You Have Been Impacted By The PetitPotam Exploit

It is important to note where the AD CS Web Enrollment services are installed. Some organizations have these services installed directly on their issuing CAs, whereas some have independent servers. These servers need to be audited and have their IIS settings reviewed.

By default, two websites are created where the AD CS Web Enrollment features are installed: the CertSrv and CES_Kerberos sites, as Figure 6 shows.

Figure 6 – AD CS Web Enrollment IIS configuration

Each site should be checked for authentication providersby clicking the site name, double-clicking Authentication, selecting Windows Authentication, and clicking Providers.

If CertSrv or CES_Kerberosare configured to allow plain Negotiate or NTLM authentication, as Figure 7 shows, you may be vulnerable to PetitPotam.

Figure 7 – The Windows Authentication provider is set to NTLM and thus potentially vulnerable to PetitPotam

Recommended PetitPotam Exploit Mitigation Strategy

NTLM Relay attacks such as PetitPotam aren’t new. In an ideal situation, NTLM authentication would simply not be used in favor of other more secure authentication methods such as Kerberos. Disabling NTLM authentication in your domain would mitigate the Relay attack vulnerability, but such a strategy would likely impact other services and cause unexpected consequences.

There are still a few steps you can take to ensure your AD CS Web Enrollment services aren’t vulnerable to PetitPotam. Note that these mitigation steps will be useful only in protecting your AD CS Web Enrollment infrastructure. If you are still using NTLM authentication, your organization’s services may be vulnerable to other similar NTLM Relay attacks that haven’t yet been demonstrated publicly. Consider these remediation steps as part of a larger strategy of deprecating NTLM authentication in your environment.

The primary mitigation strategy involves the following tasks:

Require Extended Protection for Authentication (EPA) on both the CertSrv and CES_Kerberos website, as Figure 8 shows.

Require HTTPS/SSL connections for CertSrv, as Figure 9 shows.(Note that this is enabled by default for the CES_Kerberos website.)

Figure 9 – Require SSL for the CertSrv website

Update the CES_Kerberos web.config file to enforce the extended Protection Policy settings, as the following code shows.

Example: Default CES_Kerberos web.config Settings

<binding name="TransportWithHeaderClientAuth">
	<security mode="Transport">
		<transport clientCredentialType="Windows"/>
		<message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
	</security>
	<readerQuotas maxStringContentLength="131072" />
</binding>
Code language: HTML, XML (xml)

Example: Default CES_Kerberos web.config Settings

<binding name="TransportWithHeaderClientAuth">
	<security mode="Transport">
		<transport clientCredentialType="Windows">
         		<extendedProtectionPolicy policyEnforcement="Always" />
         		</transport>
         		<message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
     	</security>
     	<readerQuotas maxStringContentLength="131072" />
</binding>

Code language: HTML, XML (xml)

Although just configuring EPA and forcing SSL for your CertSrv sites should prevent the PetitPotam exploit, it is also a good idea to disable NTLM authentication and move to Kerberos. This may require some additional configuration, including:

Ensuring a secure service account or Group Managed Service Account (gMSA) is running the AD CS Web Enrollment services application pools, as Figure 10 shows.

Figure 10 – DefaultAppPool and WSEnrollmentServer application pools configured to use the Identity ces.svc.01

Ensuring security delegation for the service account or gMSA is set to Use Kerberos only authentication to the CA-specific services, as Figure 11 shows.

Figure 11 – Delegation of services to the issuing CA used by Web Enrollment

Ensuring the Service Principal Names (SPNs) for Web Enrollment have been properly set on the service account or gMSA, as Figure 12 shows.

Figure 12 – Checking the SPNs for the Web Enrollment service account

Ensuring the CertSrv and CES_Kerberos websites have been updated to use only Negotiate:Kerberos authentication, as Figure 13 shows.

Figure 13 – Setting the CertSrv and CES_Kerberos sites to only use the Negotiate:Kerberos provider

Being sure to restart IIS by using the command IISReset from an administrator CMD prompt on the Web Enrollment server for changes to take effect.

Final Considerations

The PetitPotam exploit can be used to completely own an environment, with very few prerequisites—but mitigation is within reach. This exploit is yet another reason to consider moving away from NTLM authentication. AD CS Web Enrollment is a very old technology, and all things considered it may be worth looking into retiring it for your environment. There are many other certificate deployment strategies that do not rely on Web Enrollment, such as certificate autoenrollment through Group Policy Objects (GPOs) and modern certificate deployment strategies through modern managed platforms such as the Certificate Connector for Microsoft Intune . If custom or unique certificates that cannot be issued through automated means are required for your environment, you may even consider manual certificate signing request (CSR) submission to your issuing CAs by a certificate administrator.

Do you need help protecting your Windows network? Contact Ravenswood Technology Group today!

Tony LaGrassa

Tony LaGrassa rigorously analyzes each organization’s technology environment and objectives to achieve a best-fit, comprehensive solution the first time around. He is well-versed in Microsoft products such as Active Directory and Azure. His broad knowledge base includes PKI, AD-related tech, certificate lifecycle management, hardware security modules, scripting, and automation.

View All Posts