While this attack has been around for a long time, it’s still a common finding, and successful method of lateral movement, when our red team performs vulnerability assessments for customers. I thought it might be helpful to revisit how this attack works and how easy it is to remediate and defend against it.
An description of this attack can be found on the MITRE ATT&CK website. Essentially, this attack exploits a process whereby Windows clients try to assist other Windows clients in locating SMB resources. The attacker falsely advertises as a valid SMB resource on the network and fakes the unsuspecting client into providing the users NTLTMv2 hash. With this hash, the attacker can impersonate the stolen users identity and increase their lateral movement around the network. Let’s take a slightly more detailed look into how this attack really works…
Netbios Name Service (NBT-NS) and its successor Link-Local Multicast Name Resolution (LLMNR) have been around for quite some time and were designed to help Windows clients locate hosts when DNS resolution has failed. This might be helpful in non-enterprise networks or in a legacy era where DNS services were less robust and perhaps poorly architected, but there’s really no place for this on an enterprise network today. It’s a method of last resort for name resolution if all else fails. Both services use UDP broadcasts to make requests (LLMNR:5355, NBT-NS:137). An attacker can either place a device on the physical network or compromise an existing machine and install tools such as “NBNSpoof”, “Metasploit” or “Responder” to listen for these broadcast requests.
All we need at this point is a client to make a unknown SMB resource request. If we are in a hurry, we could phish a user into clicking on an SMB URL that doesn’t exist, or we can simply wait for a user on the network to mis-type a valid SMB path: \\Srver\Share instead of \\Server\Share or something similar. DNS will obviously fail to provide a valid response for the mis-typed server name, and NBT-NS or LLMNR on the client kicks in broadcasting the request. The attacking machine hears this request and acknowledges: “Oh hey, I’m actually Srver!” The unsuspecting client machine, thinking it’s located the correct server resource, blindly sends the NTLMv2 hash of the logged in user to the attacking machine. Game over… The attacker now has a copy of the users NTLMv2 hash which can be spoofed to access valid resources on the network. Or even better, the attacker can leverage tools to crack the hash and discover the actual password, extending the chances of their persistence in the environment.
How do we prevent this all from occurring? It’s rather simple, actually. We just need to disable NBT-NS and LLMNR on all Windows devices on the network. This can be done with legacy tools such as Group Policy if your clients are all joined to Active Directory, or we can use modern device management tools such as Microsoft Intune to push the configuration setting. Of course with any major change, it’s advisable to pilot this on a handful of devices first just in case you have an oddball scenario where NBT-NS or LLMNR is actually in use. This should be an abnormal scenario and I would suggest investigating heavily if you discover disabling either solution causes an issue as this should not really be happening on enterprise networks in this day and age.
Group Policy Setting for Disabling LLMNR
Computer Configuration > Administrative Templates > Network > DNS Client > Turn Off Multicast Name Resolution
Intune Settings for Disabling LLMNR:
Unfortunately, there are no Group Policy settings for disabling NBT-NS so we need to rely on other methods such as registry key manipulations via scripts or management tools. I’ve had great success using the following PowerShell script on clients to disable:
$RegEntry = “HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces”
Get-ChildItem $RegEntry |foreach { Set-ItemProperty -Path “$RegEntry\$($_.pschildname)” -Name NetbiosOptions -Value 2 -Verbose}
I’ve also read that you can use DHCP scope options to accomplish this, although I’ve honestly never tried using this method, myself: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/disable-netbios-tcp-ip-using-dhcp#disable-netbios-on-the-dhcp-server
If you are a Microsoft 365 shop, I also highly encourage you to check out the Defender for Identity solution as it can monitor for these “pass the hash” attacks as well as many other common exploits in on-premises Active Directory. Defender for Identity also brings user and entity behavioral analysis (UEBA) to on-premises Active Directory which is helpful in locating adversaries already inside your network.
I hope this article will encourage you to either revisit your existing policies, if you’ve performed these steps in the past, or perhaps deploy this endpoint hardening recommendation for the first time.