Choose your topics

How to Prioritize Your Third-Party Risks

How can you prioritize effectively and enhance your organization’s security posture? Here are our top tips for setting up realistic, sustainable processes.

Third-Party Risk Management GRC
Top Tips to Save Time When Assessing Third-Party Risks

Is assessing third-party risks taking up too much of your time? How can you make the process more effective and efficient? Find out in the latest post from SureCloud.

Third-Party Risk Management GRC
The GRC Trends to Look Out for in 2024

Our GRC experts at SureCloud share their 2024 predictions for the world of governance, risk and compliance.

The Top 5 Challenges of Third-Party Risk Management

With the supply chain now seen as a legitimate attack path, what can your organization do? Let’s explore 5 challenges of TPRM and how to overcome them.

Third-Party Risk Management GRC
What is Third-Party Risk Management?

What is third-party risk management and how should you approach it? Find out in this post.

Third-Party Risk Management GRC
The Top 4 Challenges of Risk Management

What are the top four challenges of risk management today and how can you overcome them? Find out in this post from SureCloud.

Third-Party Risk Management GRC
Transform Compliance into Your Competitive Advantage

In GRC, compliance is often viewed as a cost that makes it harder to pursue growth. Here's how to make it your competitive advantage.

Compliance Management GRC
Questions You Should Ask when Preparing For Your First Pen Test

Understand the processes that you and your chosen pentest provider will travel through for your first pen test, from the initial point to the day the test starts.

Penetration Testing
TPRM Blog 6-Writing Clear Questions

Our GRC Practice Director explores the importance of clear communication and how to achieve it in your third party questionnaires. Read more here.

Third-Party Risk Management GRC
Vector (7)
Vulnerability Management, Cyber Security

Local Network Vulnerabilities: Protecting Against LLMNR Poisoning and NBT-NS Poisoning

Local Network Vulnerabilities: Protecting Against LLMNR Poisoning and NBT-NS Poisoning
Written by

Ellie Owen

Published on

3 Sep 2015

Local Network Vulnerabilities: Protecting Against LLMNR Poisoning and NBT-NS Poisoning


During penetration testing, SureCloud’s Security Consultants use various methods when trying to gain access to the client’s network to escalate our privileges.


These can include:

  • Exploitation of vulnerabilities on servers and workstations
  • Misconfiguration of services 
  • Exploitation of the ‘human’ element – take a look at our article on social engineering.


A common vulnerability we often encounter provides the opportunity to obtain Domain User credentials by exploiting a combination of weaknesses within the LLMNR and NBT-NS protocols.


Here, we’ll explain the potential for LLMNR poisoning and NBT-NS poisoning in your local network and teach you the network management tools you need to disable these protocols to minimise risk.


What is the LLMNR protocol?

LLMNR (Link-Local Multicast Name Resolution) is a protocol introduced with Windows Vista based on the Domain Name System (DNS). Network-connected systems often use it to identify hosts on the local subnet when DNS fails, is not present, or where peer-to-peer name-resolutions services are required (or to complement a DNS infrastructure).


What is the NBT-NS protocol?

NBT-NS (NetBIOS Name Service) is a precursor protocol to LLMNR and operates similarly to ARP (Address Resolution Protocol) broadcasts. 

LLMNR is enabled by default on Windows Vista and later releases (which includes Server 2008 and later). 

NBT-NS is available on all Windows releases.


Is a network vulnerable if LLMNR and NBT-NS are enabled?

Both protocols have their benefits, but they are inherently vulnerable to attack. Attacks targeted against LLMNR and NBT-NS result in the disclosure of Domain Usernames and their respective credentials, either in hashed format (challenge/response such as NTLMv1 and NTLMv2) or in clear-text.


In the example of NTLMv1 and NTLMv2 hashes, they can be cracked reasonably quickly using brute-force or dictionary-based password attacks – but only if weak passwords have been set. 

As such, we recommend that LLMNR and NBT-NS protocols be disabled if there is no business requirement to support them.


How do I disable LLMNR?

The LLMNR protocol can be disabled on servers and workstations by amending the configuration within Group Policy. This can be completed by changing the following Group Policy setting:

  1. ‘Computer Configuration\Policies\Administrative Templates\Network\DNS Client\Turn off Multicast Name Resolution’
  2. Set this option to ‘Enabled’, which will disable the use of LLMNR
  3. Set this option to ‘Disabled’ to continue to use LLMNR


How do I disable NBT-NS?

To disable NBT-NS, the support for NetBIOS will also need to be disabled. Unfortunately, this cannot be completed via Group Policy natively; however, it can be disabled using a registry key or the command line. The registry setting would require this to be set against each of the interfaces in use; you can find it in the following location:

  1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\
  2. Change the DWORD value for ‘NetbiosOptions’ to ‘2.’


Value ‘0’ keeps the default setting, which is to use the NetBIOS settings from the DHCP server. Setting this value as ‘1’ enables NetBIOS over TCP/IP.


Screenshot of the registry editor within Windows 8 showing the default configuration.


The result will disable NetBIOS over TCP/IP and NBT-NS.



Example Cyberattack on LLMNR and NBT-NS Vulnerabilities

To show how this attack works, we built a ‘demo’ environment that consists of a Domain Controller and a server client. On this network, the ‘attacker’ system has visibility of the network. 


Although directly on the same subnet as the Domain Controller, the ‘attacker’ would only need to be situated on the same subnet as other clients for this attack to be possible.


Figure A shows the Client requesting ‘\\server1.local’, which doesn’t exist on the network or as a DNS record.


Figure B displays the attempted connection in the results of the ‘net use’ command.


Figure C shows what an ‘attacker’ would be able to retrieve using LLMNR poisoning in this subnet. The authentication challenge/response hash is NTLMv2.


Figure D provides an example of the password-cracking process, and the speed at which the password is cracked by utilising a common wordlist.


SureCloud’s Security Recommendations

Disabling LLMNR and NBT-NS on workstations and servers can reduce the risk of an attacker on the internal network gaining access to the domain. Combined with other practices such as regular patch management, system hardening, and strong password policies, the security posture of the internal network will be significantly improved.

Penetration Testing Services