How to Protect Against LLMNR and NBT-NS Poisoning

LLMNR and NBT-NS Poisoning

Last Updated on 25 July 2023 by Elise Imison

Active Directory (AD) is a critical component of many organizations’ IT infrastructure. It provides a centralized repository for user and computer accounts, as well as a variety of other services. As a result, AD is a common target for attackers and there has been no shortage of AD attacks in the headlines.

In this blog post, we will dive into the depths of LLMNR and NBT-NS poisoning, understanding their mechanisms, implications, and ways to mitigate the risks they pose.

What is LLMNR and NBT-NS Poisoning?

Whilst you’ve likely heard of DNS; you may not have heard of LLMNR and NBT-NS.

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows protocols for name resolution – translating hostnames to IP addresses. When trying to resolve a hostname in your local network, your device will first query its local DNS cache (stored on the device itself). If the answer cannot be found there, it will forward the request to the local DNS Server (usually located at the router, or a DNS Server within the network if you have one configured). If the host is not found in either of these locations, your device will fall back to name resolution via LLMNR and NBT-NS.

To resolve hostnames, these protocols will initiate a multicast or broadcast message to the entire network requesting the address of the resource it needs.  This is where the attack comes in. Using tools such as Responder, the attacker can monitor network traffic for LLMNR and NBT-NS requests, and subsequently respond to those requests by impersonating the requested hostname. The requesting device will then believe it has located the correct host and attempt to connect over SMB by sending the hash of the user’s password to the attacker.

Consider the following scenario

A user wants to access an SMB file share over the network.

The resource they want to access is a file named ‘2023Targets’ located on a server named ‘FileServer’. To do so, they type the server and share it into either their Windows search bar or file explorer. However, they accidentally mistype the hostname:

As ‘fileservr’ does not exist, DNS will fail to locate the device, and the LLMNR and NBT-NS protocols will kick in. An attacker posing as ‘fileservr’ would now receive the password hash of the user who initiated the request.

This password hash can be used for two purposes:

  • Offline password cracking to retrieve the plaintext password from the hash. Depending on the strength of the password, this could take minutes or hours. If sufficiently strong and complex passwords are used this could take much longer.
  • NTLM Relay whereby the attack acts as a middle-man to relay the captured password hash to another device, providing command execution on the target. Note that this relies on the user account having admin rights over the target PC and SMB signing not being required.

In either case, if the hash belongs to a domain user, the attacker now has the same privileges as the compromised domain account to proceed with further exploitation. In other words, they have succeeded in gaining access to the domain.

How to Defend Against LLMNR/NBT-NS Poisoning

Disable LLMNR

You can disable LLMNR for all computers in the domain by setting the following Group Policy Object (GPO) to ‘Enabled’:

Computer Configuration → Administrative Templates → Network à DNS Client → “Turn off multicast name resolution”

Disable NBT-NS

You can manually disable NBT-NS for each network adaptor like so:

Unfortunately, there is no GPO available at the time to disable NBT-NS across the domain.

As a workaround, you can save the following PowerShell script and add it Group Policy under the path: Computer Configuration -> Policies -> Windows Settings -> Scripts -> Startup- > PowerShell Scripts.

$regkey = “HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces”
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path “$regkey\$($_.pschildname)” -Name NetbiosOptions -Value 2 -Verbose}

Final Thoughts

In conclusion, LLMNR and NBT-NS poisoning attacks pose significant threats to network security. By implementing the best practices outlined in this article you can protect your network from these types of attacks. Remember, proactive defense and a comprehensive security strategy are crucial in safeguarding your network and sensitive information.

Frequently Asked Questions

Can LLMNR and NBT-NS poisoning attacks be prevented entirely?

While it is challenging to completely eliminate the risk of these attacks, following the best practices mentioned in this article can significantly reduce the likelihood of successful LLMNR and NBT-NS poisoning attempts.

Is it necessary to invest in expensive security solutions to protect against these attacks?

While there are advanced security solutions available in the market, implementing basic security measures, such as using reliable antivirus software, enabling firewalls, and regularly updating systems, can provide a substantial level of protection.

How often should network security pen testing be conducted?

Network penetration tests should be conducted periodically, ideally at least once a year or whenever significant changes occur in the network infrastructure or security landscape.

Are LLMNR and NBT-NS poisoning attacks specific to certain industries or organizations?

No, these attacks can target any organization or individual connected to a network. It is essential for all entities to be aware of the risks and take appropriate measures to protect against them.

What should I do if I suspect an LLMNR or NBT-NS poisoning attack?

If you suspect an LLMNR or NBT-NS poisoning attack, you should immediately notify your IT department or network administrator. They can investigate the issue, take remedial action, and implement additional security measures if necessary.