Web directory

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


Microsoft Active Directory (AD), which handles identity management, is said to have a 90-95% market share among Fortune 500 companies. Given its adoption so broad, it’s no surprise that it is so heavily targeted by malicious actors and researchers. From most cited types of attacks against AD are legacy protocols. One such protocol that receives a lot of attention from attackers is NT LAN Manager (NTLM).

NTLM has been around for over 20 years. It is used for authentication in early Windows systems, up to Windows 2000. It uses a challenge-response mechanism to authenticate clients. While many organizations have moved 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.

Definition of NTLM relay attack

An NTLM relay attack exploits the NTLM challenge-response mechanism. An attacker intercepts legitimate authentication requests and then transmits them to the server. The client that 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 the request.

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

Why PetitPotam is different

PetitPotam was leaked by security researcher Gilles Lionel, who published a proof of concept (PoC) of the exploit on GitHub. What makes PetitPotam of particular concern is that it allows Windows servers, including domain controllers, to be coerced into authenticating to a malicious destination, allowing adversaries to potentially take control of it. ‘an entire Windows domain.

Previous NTLM relay attacks focused on abusing the functionality of the MS-RPRN print API that is part of Microsoft environments. As these variants of the attack gained notoriety, organizations began to disable 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 supplier organizations such as Rapid7 approved the PoC and said that “this attack is too easy”. Allowing an unauthenticated attacker to potentially take control of a Windows domain in AD could cripple some organizations, and that’s why it’s worth exploring how PetitPotam works and how to mitigate it.

How PetitPotem works

As mentioned in Microsoft documentation, EfsRpcOpenFileRaw performs maintenance and management operations on encrypted data stored remotely and accessible over a network. While previous attempts at NTLM relay attacks targeted the MS-RPRN API, the misuse of FSRpcOpenFileRaw is new in its approach.

The MS-RPRN and MS-EFSRPC APIs are enabled by default, possibly leaving many organizations vulnerable that do not harden themselves against these attacks. In the PetitPotam example, the victim’s environment authenticates against a remote NTLM controlled by an adversary using the previously mentioned MS-EFSRPF and shares its authentication information. This authentication information includes passwords hashed through NTLM.

Although exposing hashed passwords is bad enough, an attacker uses these hashed passwords to increase their level of scrutiny. Attackers can take the recovered credentials and pass them to an Active Directory Certificate Services (AD CS) web registration page to register a domain controller (DC) certificate. This allows attackers to have an authentication certificate that they can use to access domain services as a domain controller. This puts the entire Windows domain at risk. When you have large corporate environments using Microsoft AD and their user base is organized into domains, this is a huge risk with potentially devastating impact.

Mitigating NTLM Relay Attacks

Given the wide reach and impact of PetitPotam, organizations have provided mitigation advice to those who may be affected. This includes Microsoft as well as others such as the US Agency for Cybersecurity and Infrastructure Security (CISA), which helped disseminate advice to mitigate PetitPotam’s NTLM relay attack. Microsoft’s tips for preventing NTLM relay attacks include using protections like Extended Protection for Authentication (EPA) and signing features like SMB signing, which we’ll discuss below. Additionally, Microsoft recommends that customers completely disable NTLM authentication on the domain controller.

Microsoft’s guidelines were published as a KB5005413: Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS). Microsoft mentions that those who use 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 the activation of EPA. This enables kernel-mode authentication, which Microsoft says can improve authentication performance and prevent authentication issues or, in this case, vulnerabilities. Microsoft also recommends enabling ExtendedProtectionPolicy once you’ve enabled EPA and required SSL, which will only enable HTTPS encrypted connections.

Additional mitigation tips provided by Microsoft include disabling NTLM authentication on your Windows domain controller, disabling NTLM on all AD CS servers in your domain through Group Policy, and disabling NTLM for Internet Information Services (IIS ) on all AD CS servers in your domain. These changes allow forcing authentication to Negotiate: Kerberos.

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

If migrating from NTLM to Kerberos remains the first advice, it is not always practical depending on the environment and the existing applications and architectures. In cases where this is not possible, it is strongly recommended that you follow the advice of leading security researchers, experts and Microsoft to avoid falling victim.

Copyright © 2021 IDG Communications, Inc.


Leave a Reply

Your email address will not be published.