Last month, security researcher Lionel Gilles, who uses the handle Topotem, discovered a method to hijack the Windows NT LAN Manager (or NTLM), a feature first introduced decades ago. In the attack method, called PetitPotam, the attacker uses Microsoft’s Encrypting File System Remote Protocol (MS-EFSRPC) to connect to a server, hijack the authentication session, and manipulate the results such that the server then believes the attacker has a legitimate right to access it.
The attack method has one limiting factor: The attacker needs to already be inside the network in order to take advantage of it. But for attackers who engage in manually-controlled, long term attacks on corporate networks (such as have become much more common in ransomware attacks), this may not present much of an impediment. Indeed, the threat actors behind a ransomware named LockFile allegedly have already begun to implement the exploit into their attacks.
By manipulating the data being exchanged between the attacker and the server, the attacker can force the server to authenticate the attacker as a legitimate user, in what’s known as an NTLM Relay attack. Using the authentication, the attacker can then drop tools such as a remote shell on the server, and then leverage other exploits using that remote shell to elevate their own privileges.
If the server happens to be running Active Directory Certificate Services (AD CS), they can use those privileges to assign themselves a security certificate, and then leverage that certificate to take control of an Active Directory server, and from there, the entire network that DC manages.
While this seems like a significant flaw in the NTLM protocol, there’s one important limiting factor: The hypothetical attacker in the above scenario must have at least one valid credential (which does not need to have Administrator privileges) to log on to a Windows machine from which they will stage the attack. They have to already be inside the network and in possession of this credential in order to start.
Microsoft has stated that they have no plans to issue a patch, though Microsoft and CISA have issued guidance about how to mitigate the impact of the attack. Considering the age of the protocol, and its widespread use on Windows machines dating back more than a quarter century, it’s instructive to understand how an attacker might take advantage of this in order to recognize when an attack is underway. In this article, I’ll run through the stages an attacker might use in a hypothetical scenario.
Speaking very generally, there are a few stages to a PetitPotam attack. In these stages, the attacker would:
Attempt to authenticate to a server using the credential they already have, over the NTLM protocol
Force the server to initiate NTLM authentication to another computer, using the MS-EFSRPC API command EfsRpcOpenFileRaw
Perform the NTLM Relay attack, and gain access to a more important machine, such as an AD Certificate Server
Generate an AD Certificate, which then gives the attacker Administrator privileges to an Active Directory server.
In this scenario, stages 3 and 4 might take place on the same server, because some organizations use the Active Directory server to run the Certificate Server service. So when the attacker takes control the machine that generates the certificates, they’re also in control of the AD server.
In order to understand the attack, let’s first take a look at how NTLM authentication works.
NTLM uses an encrypted challenge/response protocol to authenticate a user. It does this without sending the user’s password over the network. Instead, the system requesting authentication must perform a calculation that proves it has the credentials — a domain name, a username, and the user’s password.
After prompting the user to enter that information, the user’s computer calculates a hash of the password, and that client sends the plaintext username to the server the user is trying to log on to. The server responds by sending a 16-byte random number (called the “proof string”) to the client machine, which then replies by sending the server the product of encrypting the password’s hash value with the 16-byte number.
A packet capture of a typical NTLM authentication
If this challenge/response is successful, the server then passes along the username, the challenge (the 16-byte number), and the response (the encrypted password hash) to a Domain Controller. The DC compares the challenge and response values, and if they match, the DC sends a message back to the server that grants the user access.
A close-up look at the message that indicates “STATUS_SUCCESS” of an NTLM authentication
The PetitPotem method is just one of a number of known attack methods collectively called NTLM Relay attacks. In an NTLM Relay attack, the attacker sets up a computer they control that’s running an SMB server, and attempts to place the machine they control in the middle of the conversation between the client computer and the server they’re trying to log in to. With the attacker’s machine able to see and retransmit messages both from the client computer and the responses from the server, the attacker can read or manipulate data in that exchange.
One common method that the attacker might use to insert themselves into the middle of that conversation is to perform a trick called LLMNR/NBT-NS Poisoning.
Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows components that serve as alternate methods of host identification. LLMNR is based upon the Domain Name System (DNS) format and allows hosts on the same local link to perform name resolution for other hosts. NBT-NS identifies systems on a local network by their NetBIOS name.
When Windows hosts fail to resolve a machine name using DNS, they revert to LLMNR/NBT-NS as a backup. Since LLMNR and NBT-NS both are multicast protocols, any machine that’s connected to the same network can listen on the ports these services use and can respond to the request. Normally, they’d only receive a response from an official source, but an attacker in this scenario interjects a response that, in essence, says the machine name you are asking is me. Tools like Responder make this task easy.
When the attacker uses this method to spoof an authoritative source for name resolution by responding to LLMNR (UDP 5355)/NBT-NS (UDP 137) traffic as if they know the identity of the requested host, they effectively poison the service so that the victims will communicate with the attacker machine, instead. In an NTLM Relay attack, the attacker’s machine pretends to be the server the user is trying to connect to.
Packet capture shows the NTLMv2 “proof string,” Hash and Username transmitted in an NTLMSSP_AUTH request
Once the attacker metaphorically inserts itself into the middle of this conversation, they can intercept the NTLMSSP_AUTH packets from the client, which contains the username and the NTLM hash. With that information in hand, the attacker can crack the password using tools like John the Ripper or Hashcat, and then with the username and plaintext password in hand, the attacker can authenticate to (and potentially compromise) the server.
When it comes to the PetitPotam attack, the attacker may not even need to perform LLMNR/NBT-NS poisoning, and insert themselves into the conversation, because the attacker can simply force the server to connect to them.
In a hypothetical PetitPotam attack, the attacker abuses the Windows API function EfsRpcOpenFileRaw, which forces the server to connect to the location the attacker inserts into the FileName parameter (shown in the figure below). When the attacker passes along their own IP address in the FileName parameter, the server just connects to the attacker’s machine, which is running an SMB server and relays the SMB traffic on behalf of the attacker.
The FileName parameter in a PetitPotem-initiated EfsRpcOpenFileRaw request packet
Once the attacker establishes this communication path, they can then relay the NTLM authentication between the server and client machine, and authenticate their own machine instead of the legitimate user’s.
If the server is running Active Directory Certificate Services, the attacker can generate a legitimate certificate for themselves, and then use the cert to compromise the Domain Controller, and take over the entire network.
The proof-of-concept for the PetitPotam attack was made public on Github in July.
Now that we understand the various concepts involved in this attack, we can link all the concepts and understand the attack end to end.
In the diagram above, the attacker runs the exploit from their machine (labeled A), and acts as a relay between the server (B) and the Active Directory Certificate Services server (C).
Running the PoC requires you to pass the username, domain, and password hash as well as a target IP address in the command string.
In the initial stage, the attacker machine (A) contacts the server (B) to authenticate.
The attacker’s machine (A) sends a DCERPC bind request to the LSARPC service on the server (B). The UUID of LSARPC service is c681d488-d850-11d0-8c52-00c04fd90f7e, which is shown in the packet capture below.
Once the attacker machine (A) sends the bind request, it receives in response a bind Ack from Machine B with STATUS_SUCCESS if it’s successful.
Next, the attacker machine (A) sends an EfsRpcOpenFileRaw request to machine (B) with the location of share that it wishes to access. In the figure below, UNC path of the share that client wishes to access. Here, 192.168.56.120 is attacker-controlled with an SMB server and SMB relay. Once the attacker machine receives SMB communication, it relays it to the machine running the certificate server (C) at 192.168.56.140.
This is the important part in this attack: The attacker can perform an NTLM Relay attack for the Communication between 192.168.56.156 and 192.168.56.140. The use of the EfsRpcOpenFileRaw API call forces machine B (192.168.56.156) to start a NTLM authentication with machine A (192.168.56.120). On the attacker’s machine, where they’ve previously set up an SMB relay, they receive an NTLM negotiation between 192.168.56.120 (B) and the server at 192.168.56.140 (C).
The attacker’s machine then passes this communication along to the server.
An NTLM Relay attack as shown in the Metasploit framework
In the packet capture screenshot below, you can see two NTLM_NEGOTIATE and NTLM_CHALLENGE requests. One is received from the client machine, and the other is the same packet that the attacker machine relays to the server.
A packet capture showing the two NTLM requests
In this process, the attacker gets authenticated to the server.
The PetitPotem attack vector is not likely to go away any time soon, but there are still some things network administrators can do to reduce their risk and mitigate the vulnerability in their networks.
Microsoft’s most current authentication guidance is for networks to use Kerberos as the authentication method instead of NTLM, and it’s also possible to simply disable NTLM authentication altogether on critical machines, such as Domain Controllers, and to restrict its use in places where it cannot be avoided. In those cases, it’s possible to add an additional security layer by using SMB Signing to prevent the NTLM relay attacks from working correctly.
To disable NTLM on any AD CS Servers in the domain, use the group policy Network security: Restrict NTLM: Incoming NTLM traffic. To configure this GPO, open the Group Policy editor and navigate 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.
Admins can add exceptions, as necessary, using the setting Network security: Restrict NTLM: Add server exceptions in this domain. But it’s best to avoid using these exceptions altogether.
Admins should also disable NTLM for Internet Information Services (IIS) on AD CS Servers in domain running the “Certificate Authority Web Enrollment” or “Certificate Enrollment Web Service” services, to avoid the attacker being able to leverage the exploit to generate a valid certificate for themselves.
However, many older networks and older machines still default to the NTLM standard. A few companies, such as 0patch, have issued their own third-party micropatches that will limit the susceptibility to NTLM relay attacks.
4909 Murphy Canyon Road Suite, 500
San Diego, CA 92123
Store
Company
Support
Newsletter
