Offsec AD (Part 6) : LLMNR Poisoning & NTLMv2 Hash Grabbing

• Prologue
• Multicast Name Resolution (mNR) Protocols
  • mDNS Protocol
  • LLMNR Protocol
  • NBNS Protocol
• LLMNR Poisoning
• Attack Analysis
• Cracking NTLMv2 Hash
• Detections
• Mitigations
• References

Prologue

In the world of Red Teaming, threats are constantly evolving, and attackers are always on the lookout for new ways to exploit attack vectors. One such technique that always been a favourtite for Threat Actors is LLMNR poisoning and NTLMv2 grabbing. In this blog, we will delve into what these terms mean, how they can be exploited by malicious actors, and most importantly, how you can defend your network against these potential threats.

Multicast Name Resolution (mNR) Protocols

In modern networks that utilize the TCP/IP stack, a standard approach is followed to enable communication between devices. This involves converting resource/host names (e.g: "pwner-dc.pwners.lab") to their corresponding IP addresses (e.g: "x.x.x.x") to establish connections. This process, known as name resolution, ensures that network traffic reaches its intended destination accurately.

When Microsoft Windows clients perform name resolution, they follow a predefined sequence of methods. These methods are employed one after another until a successful match between the resource name and its IP address is found. Once a match is achieved, the name resolution process stops, and the communication path is established, allowing seamless data exchange between devices.

In Windows Active Directory (AD), DNS is an integral part of the name resolution process, facilitating seamless communication and resource access within the domain. When a Windows computer or device needs to connect to another device or service in the AD domain, it queries the DNS server to translate human-readable domain names into their corresponding IP addresses. The DNS server, typically hosted on a domain controller, holds the necessary records for name resolution, including A (Address), PTR (Pointer), and SRV (Service) records. Dynamic DNS updates keep the records up to date as new devices join the domain or IP addresses change. This enables proper authentication, resource access, and the establishment of trusts between AD domains. DNS's hierarchical structure ensures the organization of domain names, reflecting the AD domain's logical boundaries and facilitating efficient communication across the network. Without robust DNS functionality, Windows AD cannot function effectively, making DNS a critical component in the smooth operation of Active Directory environments.

But there comes a scenario, what if the DNS fails to resolve the target hostname. And it arises a question, "How does Windows manage the hostname resolution, if DNS fails?". This is where the Multicast Name Resolution (mNR) protocols (PS: collectively known as mNR) are being used. The protocols take responsibility of finding the target hostname by broadcasting the target hostname within the local network.

mDNS Protocol

mDNS (Multicast DNS) is a networking protocol that allows devices on a local network to discover and communicate with each other without the need for a centralized DNS server. It is specifically designed for small, local networks where traditional DNS may not be available or practical.

mDNS operates using multicast UDP (User Datagram Protocol) packets. Devices on the network can broadcast mDNS queries to resolve hostnames to IP addresses, and other devices that have the requested information respond with the appropriate answers. This allows devices to discover each other's presence and services without relying on a dedicated DNS server.

LLMNR Protocol

LLMNR (Link Local Multicast Name Resolution) is a protocol used by modern Windows operating systems, starting from Windows Vista and later, to resolve the hostnames of devices on a local network. When a DNS query fails, LLMNR enables devices to send multicast messages (IPv6: FF02:1:3 or IPv4: 224.0.0.252) to the local subnet, asking if any other devices know the requested hostname. If another device with the same hostname responds, the requesting device can establish communication with it. LLMNR is enabled on Windows by default.

NBNS Protocol

NetBIOS (Network Basic Input/Output System) is an older protocol used in Windows for sharing resources and communicating on a local network. NetBIOS is enabled by default on Microsoft Windows 2000 machines and above. NBNS (NetBIOS Name Service) uses a combination of broadcast and multicast messages to resolve NetBIOS names to IP addresses. When DNS resolution fails, Windows devices may fall back to NetBIOS Name Resolution as an alternative way to locate devices on the local network by broadcasting a request for the NetBIOS name.

When a DNS resolution fails, the hostname gets resolved by sending broadcast/multicast queries by the below following protocols in the order:

1. mDNS - Multicast DNS
2. LLMNR - Link Local Multicast Name Resolution
3. NBNS - NetBIOS Name Service

NetBIOS is considered outdated and is mainly utilized for communication with older systems. On the other hand, LLMNR is intended for use in consumer-grade networks where a DNS server might be absent or not available.

So this is what happens when the hostname is getting resolved technically in the low level.

1. The machine checks whether there is any entry for the hostname in C:\Windows\System32\Drivers\etc\hosts.
2. If there is no entry, it will try to query the Local DNS Cache to check the hostname is being resolved recently or not.
3. If it didn't find any resolved IP with its machine, it will query the DNS server (typically Domain Controller in Active Directory environment) to get the resolved IP from the DNS records of it.
4. If it couldn't find it there, it will start sending broadcast/multicast messages via mNR protocols to devices to find the IP belonging to the hostname.
5. If any of the device acknowledges that the hostname belongs to it, the IP will be used to communicate further.

LLMNR Poisoning

An LLMNR poisoning attack is an man-in-the-middle (MITM) attack where an attacker sends malicious LLMNR responses to legitimate hostname queries on the local network. These responses are crafted to impersonate a legitimate host or service, tricking the requesting device into establishing communication with the attacker-controlled machine instead. This effectively allows the attacker to act as a man-in-the-middle (MITM) and intercept network traffic meant for the genuine host.

The LLMNR protocol's drawback lies in its broadcasting nature, as it sends requests to the entire intranet, exposing them to all network devices. However, the protocol lacks a mechanism for validating response authenticity. Consequently, an attacker can exploit this flaw by sending fake responses, deceiving the victim into trusting a malicious server. This allows the attacker to capture the user's NTLM hash, potentially leading to unauthorized access or data theft.

LLMNR poisoning attacks often occur when a user mistypes a resource's name or requests an unreachable resource. Microsoft includes LLMNR enabled by default in their operating systems, but it becomes unnecessary in typical corporate networks where an internal DNS server is used, and all devices rely on it for name resolution. In such cases, disabling LLMNR can enhance security and prevent potential vulnerabilities.

When the attacker poisons the LLMNR requests, the victim blidly trusts the attacker's machine as the target machine and it resolves the attacker's IP as the target IP to initiate the communication. When the victim tries to access the resource on the spoofed machine, the attacker asks for NTLM authentication for the victim. In most cases, authentication takes place without user interaction. When the victim processes the NTLM challenge and sends back the response to the attacker, the NTLMv2/Net-NTLMv2 response can cracked to obtain the plain text password or it can be used to perform authentication over other machines/servers.

An alternative attack approach involves the attacker relaying the captured credentials to another system within the environment where the credentials hold validity. Similar to the previously described method, instead of merely saving the credentials, the attacker forwards them to a second system. If the account's credentials prove valid on the second system, the attacker gains access. This tactic enables the attacker to navigate through the environment, repeating the process until accessing all reachable systems where the relayed credentials remain effective. We'll delve into these Relaying Attacks in our upcoming posts.

The sole requirement for this attack vector is that the attacker's system must reside on the same network segment (local subnet) as the victim's computer. Essentially, the attacker's computer needs to have visibility of the victim's computer's network traffic.

To perform LLMNR poisoning there are many offensive tools, but these two are the most used by Threat Actors.

• Responder
• Inveigh

Attack Analysis

Let's create a new Domain User who has weak password which can be easily bruteforced.

Logging as pwner.weakuser in our Domain Computer pwner-desk2.

Lets start our Responder in analysis mode on our attacker machine. Responder comes with inbuilt server support for various protocol listed in it, which can be switched based on the attack requirements. By running it on analysis mode, we can passively monitor the network and start studying the communication in it.

Now when the victim tries to query an invalid hostname to access a resource, it is going to query the DNS server and send mNR requests on the network level.

In Wireshark, we can clearly see how the resolution is working on network level.

• Packet 23 - DNS request sent from the pwner-desk2 (Domain Computer) to pwner-dc (Domain Controller/DNS) to resolve the hostname
• Packet 24 - DNS response No such name from the DC to the Workstation
• Clearly, the hostname resolving was failed here by our DNS Server/Domain Controller

• Packet 26 - Packet 29 - mDNS resolution for the hostname
• Packet 30 - Packet 33 - LLMNR resolution for the hostname
• Packet 25 , Packet 40 - NBNS resolution for the hostname

Responder automatically detects the mNR requests, since we are in the analyse mode there will be no poisoning.

Now lets start poisoning the LLMNR packets via Responder. Make sure to turn on the respective servers for the protocols which you intend to attack.

When a victim enters a invalid hostname which is being sent to resolve via LLMNR, an attacker poisons the request and impersonates the requested resource as his machine. The responder automatically generates Domain Name, Machine Name, DCE-RPC port and Random challenge on its own, which will be further used for communication.

We can clearly see that the LLMNR requests have been poisoned and the attacker sends LLMNR responses pointing the requested hostname to the attacker's IP.

Afer poisoning the LLMNR protocol, the attacker leverages this as an advantage and asks for NTLM authentication to prove the victim's authenticity. The victim sends the NTLM challenge response without prompting the user to the target hostname which was being impersonated by the server.

Anyways even after sending a legit NTLM challenge response, the responder sends a STATUS_ACCESS_DENIED to terminate the communication. Now we should receive the NTLMv2 hash of the victim by spoofing the LLMNR protocol.

Don't bother about the other hash, which was generated by our dummy prompt values in the user's machine. The NTLM authentication for the Domain User while accessing the network share gets triggered automatically. You can compare the NTLMv2 challenge response from the Packet 43 with the responder sniffed value.

Cracking NTLMv2 Hash

Now we have successfully poisoned the LLMNR protocol and obtained the NTLMv2 hash of our victim. It's time to crack the hash and gain the plain text password which can be reused later and gain persistence over the domain.

This scenario will not be successful always, becuase it depends on the two parameters.

1. Complexity of the user's password to generate NTLMv2 response
2. The wordlist used to crack the obtained NTLMv2 hash.

Now lets crack the NTLMv2 has using john.

We can even use hashcat to crack the password by the below command.

hashcat -m 5600 user.hash wordlist.txt

Now we have gained initial access over the Active Directory domain and we can even use the cracked plain text password to query/execute any unauthorized action over the AD domain.

Detections

The detection mechanism for the LLMNR poisoning is very simple as the attack vector. A defender just needs to send a multicast request for a fake random hostname to get resolved. When the user receives a poisoned LLMNR response from a attacker for the fake random generated hostname, we can directly pin point the attacker's IP. Below are the tools which we can use to detect an attacker performing LLMNR poisoning in the local network.

• Respounder
• Conveigh
• HoneyCreds

Mitigations

Mitigating LLMNR poisoning is crucial to enhance the security of your network and prevent potential attacks. Here are some effective measures to help protect against LLMNR poisoning:

• Disable LLMNR: In corporate environments with a DNS server, LLMNR is often unnecessary. Disabling LLMNR on all devices can prevent attackers from exploiting this protocol. You can disable LLMNR through Group Policy settings or by modifying registry entries. Open the Group Policy Editor gpedit.msc > Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

• Implement VLAN Segmentation: Using VLANs (Virtual LANs) to segment different parts of your network can limit LLMNR traffic to specific subnets, reducing the potential impact of LLMNR poisoning attacks.

• Firewall Rules: In addition to disabling NetBIOS on the NIC of each computer and through DHCP and disabling LLMNR, the outbound NetBIOS and LLMNR traffic should be restricted on the host firewall of each system by blocking the NetBIOS protocol and TCP port 139 as well as the LLMNR UDP port 5355. This step can prevent any NetBIOS or LLMNR traffic from accessing or leaving the computer, even when the device is taken out of the corporate network and connected to less secure public networks.

• Disable NetBIOS over TCP/IP: NetBIOS over TCP/IP can be exploited by attackers, similar to LLMNR. Disabling it on all devices can provide an additional layer of protection. Select the IPv4 properties of the NIC and disable NetBIOS under WINS tab of Advanced TCP/IP settings.

• Strong Password Policy: Implement password policy which implements the Domain Users to set complex passwords for their user accounts.

• Enable SMB Signing: Enabling SMB (Server Message Block) signing ensures that data transmitted between devices remains intact and unaltered. This helps prevent man-in-the-middle attacks, relaying attacks which often exploit LLMNR poisoning.

By implementing these mitigations, you can significantly reduce the risk of LLMNR poisoning and enhance the overall security posture of your network. It is crucial to adopt a defense-in-depth approach, combining multiple security measures to protect against a wide range of cyber threats.

References

RFC for mDNS - https://www.rfc-editor.org/rfc/rfc6762.html

RFC for LLMNR - https://datatracker.ietf.org/doc/html/rfc4795s

https://book.hacktricks.xyz/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks