Abusing legacy Windows name-resolution protocols
Introduction
When a computer needs to communicate with another device, it normally needs to translate a hostname into an IP address.
For example cybertrainer.uk -> 109.228.34.178 or big-red -> 192.168.0.5
Typically, this resolution is normally handled by DNS.
However, Windows also supports several legacy name-resolution mechanisms, including:
- LLMNR – Link-Local Multicast Name Resolution
- NBT-NS – NetBIOS Name Service
These protocols can become a security problem when a Windows system cannot resolve a hostname through normal DNS. An attacker on the same local network can potentially respond to the failed name-resolution request and claim “I am the system you are looking for.”
If the victim subsequently attempts to authenticate to the attacker’s machine, the attacker may be able to capture an NTLM authentication exchange.
This makes LLMNR/NBT-NS poisoning an important example of how a seemingly harmless network service can become a source of credential theft and lateral movement.
What is LLMNR?
Link-Local Multicast Name Resolution (LLMNR) is a Windows name-resolution protocol designed to allow systems to resolve hostnames when conventional DNS resolution is unsuccessful.
Instead of asking a DNS server “What IP address belongs to FILESERVER01?”, the computer can effectively ask other devices on the local network “Does anyone know where FILESERVER01 is?”
The request is sent using multicast communications, creating an opportunity for another system on the network to respond.
What is NBT-NS?
NetBIOS Name Service (NBT-NS), is an older Windows networking mechanism used for name resolution. Like LLMNR, it can allow Windows systems to resolve names when DNS is unavailable or unsuccessful.
Where LLMNR uses Multicasts, NBT-NS uses broadcast-based communications on the local network.
The important security characteristic here is that The requesting computer does not necessarily know which system should answer.
As such, an attacker can potentially exploit this behaviour by responding to the request.
Why Are LLMNR and NBT-NS Dangerous?
The fundamental problem is trust.
Imagine a Windows computer attempts to access a resource – \FILESERVER01\Documents
DNS cannot resolve the hostname, so Windows may attempt alternative name-resolution mechanisms.
The request effectively now becomes – “Who is FILESERVER01?”
An attacker monitoring the network can respond to this request with “I am FILESERVER01.”
If the victim believes the response, it may attempt to authenticate to the attacker’s system which will produce an NTLM authentication exchange. The attacker can then acquire the victims authentication hash data.
Once obtained, this hash data can be either cracked to recover the password, or used in a Pass-The-Hash attack where the hash is relayed to another service to authenticate without ever recovering the credentials.
Why Would the Victim Authenticate?
Windows frequently uses integrated authentication. When a user attempts to access a network resource, Windows may automatically attempt to authenticate using available credentials.
If an attacker has successfully poisoned the name-resolution process, the authentication attempt may instead reach the Attackers machine
The user may not even realise that their computer has communicated with the attacker.
The Importance of User Behaviour
LLMNR/NBT-NS poisoning frequently relies on users or applications attempting to access resources that do not exist. Common triggers can include:
- Typing an incorrect hostname
- Incorrect network paths
- Mistyped file-server names
- Broken shortcuts
- Applications requesting nonexistent hosts
- Incorrect DNS records
- Legacy applications
This makes the attack particularly interesting because the attacker may not need to directly compromise the victim first.
They can simply wait for a system to make a mistake and then capitalise on that mistake
NTLM Challenge-Response
NTLM authentication uses a challenge-response mechanism.
Conceptually the server issues a challenge to which the client responds with data derived from secret material – The objective is to allow authentication without ever transmitting the plaintext password across the network.
However, if an attacker captures the exchange, they may be able to attempt offline password guessing against the captured material.
What Happens After Hash Capture?
Capturing an NTLM authentication exchange is potentially only the beginning.
As previously mentioned, once a hash has been obtained, the attacker may attempt offline password cracking and, if the password is weak, the attacker may eventually recover it.
Alternatively, they may attempt credential reuse which is where the recovered password may work elsewhere in the network
Another approach is lateral movement which is where the attacker may use the credentials to access additional systems.
Finally, depending on the circumstances, the authentication exchange may be used in a relay attack.
NTLM Relay attacks
One of the most important concepts associated with LLMNR/NBT-NS poisoning is NTLM relay.
Instead of trying to crack the captured authentication material, an attacker may attempt to relay the authentication to another service that accepts NTLM data
Here, the attacker is attempting to use the victim’s authentication against another system.
This is particularly dangerous because the attacker may not need to recover the user’s password.
LLMNR/NBT-NS Poisoning vs NTLM Relay
These are related but distinct concepts.
- LLMNR/NBT-NS Poisoning – The attacker manipulates name resolution to attract authentication traffic.
- NTLM Relay – The attacker forwards captured authentication to another service.
Disabling LLMNR and NBT-NS can significantly reduce an organisation’s exposure to this attack path.
Why DNS Configuration Matters
A correctly configured DNS infrastructure reduces the circumstances in which Windows needs to fall back to LLMNR or NBT-NS.
This is one reason DNS hygiene is an important part of Windows network security.
LLMNR/NBT-NS and Active Directory
The attacks described here are particularly relevant to Active Directory environments. Domain-joined Windows systems frequently use:
- SMB
- NTLM
- Kerberos
- DNS
- Windows integrated authentication
An attacker who obtains valid domain credentials may potentially use them to move further through the environment.
The initial poisoning attack may therefore be relatively simple while its ultimate consequences can be significant.
A single captured credential can potentially provide a path into a much larger environment.
LLMNR/NBT-NS Poisoning and Credential Security
Strong password policies can reduce the impact of captured NTLM authentication material.
If passwords are:
- Long
- Unique
- Random
- Not reused
then offline cracking becomes substantially more difficult.
However, password strength alone is not sufficient.
Organisations should also reduce the opportunity for attackers to capture authentication material in the first place.
Disabling LLMNR
One of the most effective defensive measures is to disable LLMNR where it is not required. In a managed Windows environment, this can typically be performed through Group Policy.
The objective is to prevent Windows clients from falling back to LLMNR when DNS resolution fails.
Disabling NBT-NS
NBT-NS should also be disabled where it is not required. This is particularly important in environments that still have legacy Windows networking enabled.
If a protocol is not required for business operations, there is little reason to expose the organisation to its associated attack surface.
Prefer Kerberos Over NTLM
Where possible, modern Windows environments should prefer Kerberos rather than NTLM. Kerberos provides stronger authentication mechanisms and is the standard authentication protocol used within modern Active Directory domains.
Reducing unnecessary NTLM usage can make several credential-based attacks more difficult.
However, legacy applications and systems may still require NTLM, so organisations should understand where it remains in use and put other security controls around those legacy systems to limit any exposure to potential threats
Network Segmentation
Network segmentation provides another layer of protection. If an attacker gains access to one workstation, they should not automatically have unrestricted access to the entire network.
This limits the potential consequences of credential theft and lateral movement.
Monitoring for LLMNR/NBT-NS Attacks
Security teams should monitor for unusual name-resolution activity. Potential indicators include:
- Unexpected LLMNR requests
- Unexpected NBT-NS broadcasts
- Multiple responses to the same hostname
- Unknown devices responding to name-resolution requests
- Workstations acting as name-resolution responders
- Unexpected NTLM authentication attempts
- Authentication to unusual systems
- Repeated failed DNS lookups followed by LLMNR/NBT-NS traffic
A workstation suddenly responding to large numbers of name-resolution requests should be investigated.
Indicators of Compromise
Potential indicators of a compromise include:
Network indicators
- Unexpected LLMNR traffic
- Unexpected NBT-NS broadcasts
- Unknown devices responding to queries
- Multiple systems responding to the same hostname
Authentication indicators
- Unexpected NTLM authentication
- NTLM authentication to unusual workstations
- Repeated authentication attempts
- Authentication occurring immediately after failed DNS resolution
Host indicators
- Poisoning tools running on endpoints
- Unusual network listeners
- Suspicious processes responding to name-resolution traffic
Correlation between these indicators can help distinguish normal legacy traffic from active poisoning.
Tools Used by Attackers
Security professionals should be familiar with tools capable of demonstrating or detecting this attack technique.
Examples include:
- Responder
- Inveigh
- Metasploit modules
- Impacket tooling
These tools can be used in authorised penetration testing and security laboratories to demonstrate how name-resolution poisoning can lead to NTLM credential capture or relay.
The important defensive lesson is understanding what network behaviour these tools generate. If you know what the tools do, you can better protect against their use in your network.
LLMNR/NBT-NS Poisoning vs ARP Poisoning
These attacks are sometimes confused because both involve manipulating network communication.
| Feature | LLMNR/NBT-NS Poisoning | ARP Poisoning |
|---|---|---|
| Primary target | Name resolution | IP-to-MAC resolution |
| Main objective | Attract authentication traffic | Redirect network traffic |
| Typical credential risk | NTLM capture | Traffic interception |
| Network scope | Local network | Local network |
| Protocol abused | LLMNR/NBT-NS | ARP |
| Can support MitM? | Yes | Yes |
The key distinction is that ARP poisoning changes where IP traffic is delivered, whereas LLMNR/NBT-NS poisoning changes who answers a hostname request.
LLMNR/NBT-NS Poisoning vs DNS Spoofing
DNS spoofing also involves manipulating name resolution, however, the mechanisms are different.
With DNS Spoofing – The attacker manipulates DNS responses.
With LLMNR/NBT-NS Poisoning – The attacker responds to Windows fallback name-resolution requests.
Both can cause a victim to communicate with an attacker-controlled system, however, LLMNR/NBT-NS poisoning is particularly associated with Windows fallback behaviour and NTLM authentication capture.
Defending Against LLMNR/NBT-NS Poisoning
A layered defence should include:
- Disable LLMNR – Remove unnecessary fallback name resolution.
- Disable NBT-NS – Remove unnecessary legacy NetBIOS name resolution.
- Maintain reliable DNS – Ensure internal hostnames resolve correctly.
- Reduce NTLM usage – Prefer Kerberos where possible.
- Strengthen authentication – Use strong, unique passwords and modern authentication mechanisms.
- Segment networks – Limit lateral movement between systems.
- Monitor network traffic – Detect unexpected LLMNR/NBT-NS responses.
- Monitor NTLM authentication – Investigate unusual authentication paths.
Conclusion
LLMNR/NBT-NS poisoning is a network-based attack technique that abuses legacy Windows name-resolution mechanisms to redirect authentication attempts toward an attacker-controlled system.
The technique is particularly significant in Windows and Active Directory environments, where NTLM authentication and integrated Windows networking can provide attackers with opportunities to move from a simple name-resolution attack toward broader credential compromise.
The strongest defence is to remove the unnecessary attack surface:
Disable LLMNR and NBT-NS, maintain reliable DNS, reduce NTLM usage, prefer Kerberos, segment networks, and monitor for unusual authentication behaviour.
The key lesson is simple – A hostname lookup should never become a credential-theft opportunity.
A simple typo or missing DNS record can provide an attacker with an opportunity to impersonate a trusted system.
When Windows asks “Who is this?“, an attacker should never be able to answer “Me.“
Understanding how attackers can abuse legacy Windows name-resolution protocols to capture NTLM authentication