Recently, Lionel Gilles, a French-based Offensive Computer Security researcher based in Paris, France published a PoC tool on NTLM Relay Attack known as PetitPotam that exploits the MS-EFSRPC (Encrypting File Services Remote Protocol). PetitPotam is a classic NTLM Relay Attack, and such attacks have been previously documented by Microsoft along with numerous mitigation options to protect users. Here is an example of such documents: NT LAN Manager: How to prevent NTLM credentials from being sent to remote servers. Below are some related guides: Active Directory Authentication methods: How do Kerberos and NTLM work? how does cached domain logon work?, and What is Pass the Hash Attack and how to mitigate the attack.
PetitPotam takes advantage of servers where the Active Directory Certificate Services (AD CS) is not configured with protections for NTLM Relay Attacks. The mitigations below outline to customers how to protect their AD CS servers from such attacks and help in mitigating the Windows Domain Controllers (environement) Compromise. Here are some guides on how to install and configure Active Directory Certificate Services and how to create a certificate template for BitLocker Network Unlock.
Devices running Active Directory Certificate Services (AD CS) with the following roles (services) enabled “Certificate Authority Web Enrollment”, and “Certificate Enrollment Web Service” are susceptible to this attack when NTLM is utilized. You can run the command below in a PowerShell console to determine if the feature is installed on your hosts. As you see in the image below, the following role is not installed on this specific server.
But if you have the role installed, it will look like this in the image below.
How does this work? Threat actors can target a DCs to send its credentials by using the MS-EFSRPC protocol and then relaying the Domain Controller NTLM credentials to the Active Directory Certificate Services AD CS Web Enrollment pages to enroll a DC certificate. This will effectively give the attacker an authentication certificate that can be used to access domain services and compromise the entire domain. You are potentially vulnerable to this attack if NTLM authentication is enabled in your domain and you are using Active Directory Certificate Services (AD CS) with any of the following services:
- Certificate Authority Web Enrollment,
- Certificate Enrollment Web Service
To prevent NTLM Relay Attacks on networks with NTLM enabled, domain administrators must ensure that services that permit NTLM authentication make use of protections such as Extended Protection for Authentication (EPA) or signing features such as SMB signing. PetitPotam takes advantage of servers where the Active Directory Certificate Services (AD CS) is not configured with protections for NTLM Relay Attacks.
Microsoft has released ADV210003 and KB5005413 in response to the published PoC and recommends that you disable NTLM authentication on your Windows domain controller as the simplest mitigation. This
hyperlink “Network Security: Restrict NTLM: NTLM authentication in this domain” is Microsoft preferred mitigation steps.
– Launch Gpedit.msc as shown below
This will open the Group Policy console. Navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and select the Network Security: Restrict NTLM: NTLM authentication in this domain and ensure it is disabled.
As you can see below, the NTLM authentication in this domain is being disabled as shown below.
Potential impact: If you configure this policy setting, numerous NTLM authentication requests could fail within the domain, which could degrade productivity. Before implementing this change through this policy setting, set Network security: Restrict NTLM: Audit NTLM authentication in this domain to the same option so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting by using Network security: Restrict NTLM: Add server exceptions in this domain.
Other Mitigations: If you are unable to disable NTLM on your domain for compatibility reasons, you can do one of the following. They are listed in order of more secure to less secure.
Method 1: Disable NTLM on any AD CS Servers in your domain using the group policy
Network security: Restrict NTLM: Incoming NTLM traffic. To configure this GPO, open Group Policy and go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options and set “Network security: Restrict NTLM: Incoming NTLM traffic” to “Deny All Accounts” or “Deny All domain accounts”.
– If needed you can add exceptions as necessary using the setting “Network security: Restrict NTLM: Add server exceptions in this domain.”
You will be required to confirm the Setting Change by click on Yes as shown below.
As you can see, the incomming NTLM traffic has been disabled for all Domain accounts.
– Note: The domain controller will deny all NTLM authentication logon attempts using accounts from this domain to all servers in the domain. The NTLM authentication attempts will be blocked and will return an NTLM blocked error unless the server name is on the exception list
Method 2: Disable NTLM for Internet Information Services (IIS) on AD CS Servers in your domain running the “Certificate Authority Web Enrollment” or “Certificate Enrollment Web Service” services. To do so open Server Manager, click on Tools and luanch the Internet Information Services (IIS) Manager as shown below.
This will open the IIS Manager UI (snap-in).
Disable/remove the NTLM provider: You will have to set the Windows authentication to “Negotiate:Kerberos” and click on Add as shown below.
Remove the available Providers as shown below and Click on Ok.
However, if you can’t disable NTLM outright then we recommend enabling Extended Protection for Authentication (EPA) on AD CS services (Certificate Authority Web Enrollment).
After enabling EPA in the UI, the Web.config file created by CES role at ”
%windir%>\systemdata\CES\<CA Name>_CES_Kerberos\web.config” .
The web.config should also be updated by adding <extendedProtectionPolicy> element with either “WhenSupported | Always” value based on the Extended Protection option selected in above IIS UI. The settings most likely to be used are as follows:
<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>
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.