During a penetration test SureCloud’s Security Consultants utilise a variety of different methods when trying to gain access to the client’s network in order to escalate our privileges. These include the exploitation of vulnerabilities on servers and workstations, along with misconfiguration of services, and the exploitation of the ‘human’ element from a social engineering perspective.
A common vulnerability that we often come across provides the opportunity to obtain Domain User credentials by exploiting a combination of weaknesses within the LLMNR and NBT-NS protocols.
This post explains the potential for LLMNR and NBT-NS Poisoning in your local network and how to disable these protocols to minimise risk.
What is the LLMNR protocol?
LLMNR (Link-Local Multicast Name Resolution) is a protocol that was introduced with Windows Vista and is based upon the Domain Name System (DNS). It is often used by network-connected systems 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), with NBT-NS being available on all Windows releases.
Is a network vulnerable if LLMNR and NBT-NS are enabled?
Whilst both protocols have their uses, they are inherently vulnerable to attack. The outcome of attacks that are targeted against LLMNR and NBT-NS result in the disclosure of Domain User names 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 and dictionary-based password attacks if weak passwords have been set. As such it is recommended that both LLMNR and NBT-NS protocols are disabled should there be 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:-:
- ‘Computer Configuration\Policies\Administrative Templates\Network\DNS Client\Turn off Multicast Name Resolution’
- Set this option to ‘Enabled’, which will disable the use of LLMNR
- 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 by the command line.
The registry setting would require this to be set against each of the interfaces that are in use and can be found within the following location:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\
- The DWORD value for ‘NetbiosOptions’ will need to be changed to ‘2’
- Value ‘0’ keeps the default setting, which is to use the NetBIOS settings from the DHCP server, whilst setting this value as ‘1’ enables NetBIOS over TCP/IP
Screenshot of the registry editor within Windows 8 showing the default configuration.
The resulting setting, which will disable NetBIOS over TCP/IP, and NBT-NS.
Attack Scenario Example
To provide an example of how this attack works, a ‘demo’ environment has been created which 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.
Additional Comments
Disabling both 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 greatly improved.
Resources
IETF
TECHNET
Attack Scenario Example
To provide an example of how this attack works, a ‘demo’ environment has been created which 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.
Additional Comments
Disabling both 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 greatly improved.