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.