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.
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
- 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 above.
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.”
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:
<extendedProtectionPolicy policyEnforcement="Always" />
<message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false" />
<readerQuotas maxStringContentLength="131072" />
I hope you found this blog post helpful. If you have any questions, please let me know in the comment section.
Thanks for sharing!
Not my topic at all, but a good resource to get informed!
Wow, very detailed description. Thank you.
I am sure this will be of interest for my security colleagues.
Its kind of unfortunate for us, that Veeam Enterprise Manager still uses NTLM Authentication by default to talk to the Veeam Backup Server. Even if we use it as an all-in-one setup on one single machine.
NTLM has major flaws and should not be used anymore, wich Veeams Enterprise Manager prevents.
Maybe exploits like this will help bump up this topic on Veeams development side, since support told me its on their feature request list.
In case anyone is interested:
Case # 04936306
Very interesting article. Will be sure to pass on to our Security team to look in to.