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.
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.
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.
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.
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.
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.
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.
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.)
- 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.
- 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.
- Ensuring the Service Principal Names (SPNs) for Web Enrollment have been properly set on the service account or gMSA, as Figure 12 shows.
- Ensuring the CertSrv and CES_Kerberos websites have been updated to use only Negotiate:Kerberos authentication, as Figure 13 shows.
- 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!
