NTLM relay attacks explained, and why PetitPotam is the most dangerous

Microsoft Active Directory (AD), which handles identity management, reportedly holds 90% to 95% market share among fortune 500 companies. Given such broad adoption, it is no surprise that it is so heavily targeted by malicious actors and researchers alike. Among the most cited types of attacks against AD are legacy protocols. One such protocol that receives a lot of focus from attackers is NT LAN Manager (NTLM).

NTLM has been around for over 20 years. It is used for authentication in early Windows systems, leading up to Windows 2000. It uses a challenge-response mechanism to authenticate clients. While many organizations have shifted to Kerberos, many legacy systems and applications still support or use NTLM. It is also used in scenarios where you need to join a workgroup, local logon authentication on non-domain controllers or in some cases for non-Microsoft applications.

NTLM relay attack definition

An NTLM relay attack exploits the NTLM challenge-response mechanism. An attacker intercepts legitimate authentication requests and then forwards them to the server. The client who originally sent the request receives the appropriate challenges, but the attacker intercepts the responses and forwards them to the server, which then authenticates the attacker rather than the person or device that made request.

While NTLM relay attacks are far from new, researchers and malicious actors continue to find novel ways to exploit this authentication protocol. The recent PetitPotam attack is a good example.

Why PetitPotam is different 

PetitPotam was disclosed by security researcher Gilles Lionel, who released a proof-of-concept (PoC) of the exploit on GitHub. What makes PetitPotam particularly concerning is that it allows Windows servers, including domain controllers, to be coerced into authenticating with a malicious destination, which lets adversaries potentially take over an entire Windows domain.

Previous NTLM relay attacks were centered around abusing the function of the MS-RPRN printing API that is part of Microsoft environments. As those variations of the attack gained notoriety, organizations began disabling MS-RPRN to block the attack vector. PetitPotam took a new approach, using the EfsRpcOpenFileRaw function of the Microsoft Encrypting File System Remote Protocol (MS-EFSRPC) API.

Security research and vendor organizations such as Rapid7 vetted the PoC and stated that “this attack is too easy.” Allowing an unauthenticated attacker to potentially take over a Windows domain in AD could cripple some organizations, and this is why it is worth exploring how PetitPotam works and how to mitigate it.

How PetitPotem works

As mentioned in Microsoft’s documentation, EfsRpcOpenFileRaw performs maintenance and management operations on encrypted data that is stored remotely and accessed over a network. While previous attempts at NTLM relay attacks targeted the MS-RPRN API, abusing EfsRpcOpenFileRaw is novel in its approach.

Both the MS-RPRN and MS-EFSRPC APIs are enabled by default, likely leaving vulnerable many organizations that aren’t hardening against these attacks. In the PetitPotam example, the victim’s environment authenticates against a remote NTLM that is controlled by an adversary using the previously mentioned MS-EFSRPF and shares its authentication information. This authentication information includes hashed passwords via NTLM.

While exposing hashed passwords is bad enough, an attacker uses those hash passwords to escalate their level of control. Attackers can take the retrieved credentials and pass them to an Active Directory Certificate Services (AD CS) Web Enrollment page to enroll a domain controller (DC) certificate. This allows the attackers to have an authentication certificate that they can use to access domain services as a DC. This puts the entire Windows domain at risk. When you have large enterprise environments using Microsoft AD and having their user base organized into domains, this is a massive risk with a potentially devastating impact. 

NTLM relay attack mitigation 

Given PetitPotam’s widespread reach and impact, organizations have provided mitigation advice for those who may be impacted. This includes Microsoft as well as others such as the US Cybersecurity and Infrastructure Security Agency (CISA), which helped spread the guidance for mitigating PetitPotam’s NTLM relay attack. Microsoft’s advice for preventing NTLM Relay Attacks includes using protections such as Extended Protection for Authentication (EPA) and signing features such as SMB signing, which we will discuss below. Furthermore, Microsoft recommends customers disable NTLM authentication on the domain controller altogether.

Microsoft’s guidance was issued in the form of KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS). Microsoft mentions that those who are using Certificate Authority Web Enrollment and Certificate Enrollment Web Services are particularly vulnerable to PetitPotam.

Among the key recommendations for those who must use NTLM is enabling EPA. This enables kernel-mode authentication, which Microsoft states may improve authentication performance and prevent authentication problems, or in this case, vulnerabilities. Microsoft also recommends enabling extendedProtectionPolicy once you’ve enabled EPA and requiring SSL, which will enable only HTTPS-encrypted connections.

Additional mitigation advice provided from Microsoft is to disable NTLM authentication on your Windows domain controller, disabling NTLM on any AD CS servers in your domain via Group Policy, and disabling NTLM for Internet Information Services (IIS) on any AD CS Servers in your domain. These changes help force the authentication to Negotiate:Kerberos.

NTLM relay attacks, especially those that can take over domains, can have devastating impact across Windows enterprise environments using Active Directory. This is even more true in modern architecture environments that view identity as the new perimeter.

While migrating from NTLM to Kerberos remains the top advice, it is not always practical depending on the environment and existing applications and architecture. In the cases where it isn’t possible, heeding advice from leading security researchers, experts and Microsoft is highly recommended to avoid falling victim.