LLMNR Poisoning

What is

LLMNR (Link-Local Multicast Name Resolution) is a protocol used by Windows hosts to resolve hostnames when DNS is unable to do so.

Its predecessor is NBT-NS (NetBIOS Name Service), which provides similar functionality for NetBIOS names.

The main security issue with these protocols is that clients accept responses from other hosts on the local network without having a reliable way to verify that the response actually comes from the legitimate host.

An attacker can therefore respond to name-resolution requests and cause a Windows client to authenticate against an attacker-controlled machine.

When the authentication uses NTLMv2, the attacker can capture the resulting NTLMv2 challenge-response. This authentication material can subsequently be analyzed or, depending on the scenario, cracked offline.

Requirements

For a controlled lab, the following conditions should be met:

• The attacker and Windows clients must be on the same network segment.

• LLMNR or NBT-NS must be enabled on the Windows clients.

• Windows clients must generate a name-resolution request that cannot be resolved through DNS.

• The attacker must be able to receive the resulting authentication traffic.

How to

Summary

The basic workflow is:

sudo responder -I <interface> -dw

Detailed

1. Start Responder

The first step is to start Responder and configure it to listen on the appropriate network interface.

sudo responder -I <interface> -dw

The important parameters are:

• -I specifies the network interface.

• -d enables Responder’s DHCP functionality.

• -w enables WPAD functionality through the DHCP server.

For example:

sudo responder -I eth0 -dw

Once started, Responder will display the services that are enabled.

We should leave Responder running while waiting for a client to generate a name-resolution request.

2. Wait for an LLMNR request

When a Windows client attempts to resolve a hostname that cannot be resolved through DNS, it may generate an LLMNR request.

Responder can answer this request and advertise the attacker’s machine as the destination for the requested service.

The client may subsequently attempt to authenticate to the attacker-controlled service using NTLM.

3. Capture the authentication

When the authentication reaches Responder, it will display information about the client and the NTLMv2 authentication.

An example is:

[SMB] NTLMv2-SSP Client   : 172.16.14.130
[SMB] NTLMv2-SSP Username : MARVEL\fcastle
[SMB] NTLMv2-SSP Hash     : fcastle::MARVEL:9d34be9375e61037:BB1DD5E285B9FAE12194E4F06934720A:0101000000000000807A7D9AA342DD014639658E51409A880000000002000800510030004E00340001001E00570049004E002D004E00540042003600320059004100360046005700350004003400570049004E002D004E0054004200360032005900410036004600570035002E00510030004E0034002E004C004F00430041004C0003001400510030004E0034002E004C004F00430041004C0005001400510030004E0034002E004C004F00430041004C0007000800807A7D9AA342DD01060004000200000008005000500000000000000001000000002000006F90C7F55D453604EB943A2D552781C7C6222E0D27CA8DBB1CFD684727655D72B9BE8DB2C8D22BEB8ABE37611ADD8DA0664AE39DD78782E8BAE57F435D7FC4F40A001000000000000000000000000000000000000900240063006900660073002F003100370032002E00310036002E00310034002E003100330031000000000000000000

The important information in the output is the username, domain and NTLMv2 challenge-response.

The captured authentication is not the user’s plaintext password. It is an NTLMv2 challenge-response that may be susceptible to offline password cracking depending on the password strength.

Understanding the attack

The complete attack can be represented as:

Windows Client
     |
     | LLMNR / NBT-NS request
     v
Attacker / Responder
     |
     | Malicious response
     v
Windows Client
     |
     | NTLM authentication
     v
Attacker / Responder
     |
     | Captured NTLMv2 challenge-response
     v
Offline analysis / cracking

The attack relies on the client trusting responses to name-resolution requests that were not successfully resolved through DNS.

The important distinction is that the attacker does not need to know the user’s password to capture the NTLMv2 authentication.

Common problems

Responder does not receive any requests

If no authentication is captured, verify that:

• Responder is running on the correct interface.

• The attacker and Windows client are on the same network segment.

• LLMNR or NBT-NS is enabled.

• The Windows client is actually generating a failed name-resolution request.

• Another service is not already responding to the request.

The client does not authenticate

A name-resolution response does not necessarily result in an authentication.

The exact behaviour depends on the application and protocol that generated the request.

No useful NTLMv2 authentication is captured

Verify which Responder services are enabled and whether the Windows client is attempting to access the advertised service.

Defensive considerations

The most effective mitigation is to eliminate the unnecessary name-resolution mechanisms that allow this attack.

Recommended measures include:

• Disable LLMNR through Group Policy.

• Disable NBT-NS where it is not required.

• Use DNS correctly so clients do not need fallback name-resolution protocols.

• Reduce or disable NTLM authentication where possible.

• Enforce SMB signing where appropriate.

• Monitor the network for unexpected LLMNR and NBT-NS responses.

• Monitor for unusual NTLM authentication activity.

Disabling LLMNR alone does not necessarily eliminate every NTLM relay or credential-theft path. Other mechanisms, including IPv6-based attacks, can result in similar authentication flows.

Notes

LLMNR poisoning is particularly useful for understanding a broader Active Directory security concept: Windows authentication can be triggered by network services without the user explicitly entering their credentials.

The captured NTLMv2 material should therefore be treated as sensitive authentication data.

In a lab, it is useful to document:

• Attacker IP address.

• Windows client IP address.

• Active Directory domain.

• Network interface used by Responder.

• Whether LLMNR is enabled.

• Whether NBT-NS is enabled.

• Which Responder service received the auth