As a penetration tester, I find it too easy to fully compromise an internal network without finding a single “vulnerability.” I spend most of my time on two types of engagements—PCI projects and penetration tests. The pen tests are way more exciting than the PCI projects! I’m going to share with you a popular method that both pen testers and hackers alike use to gain a foothold on your internal network which typically leads to a full compromise/hack.
There are two broadcast type features in the Windows operating system that allow for spoofing and capturing of password hashes on a local subnet of a network. Several popular tools in the hacking/penetration testing world exist that take advantage of this and make it EXTREMELY easy to capture a Windows user’s password hash on the same subnet. There is a 3rd broadcast feature –WPAD that I’ll explain in a later blog post. I’ll explain the two similar features here. Link-Local Multicast Name Resolution (LLMNR) is a protocol enabled by default that allows both IPv6 and IPv4 hosts to perform name resolution for the names of neighboring computers without requiring a DNS server or DNS client configuration. NetBIOS Name Service (NBTNS) is basically the same thing as LLMNR but only works on IPv4 hosts and is most associated with Windows XP machines. If you’re running a Windows O/S on your computer chances are it has LLMNR and NBTNS enabled by default. Never heard of these features? That’s because you, your computer, and your corporate network don’t need them. Here’s how it works: On a local network a Windows computer (typically a workstation) will send out a broadcast message (i.e., a message to all computers on your “local link” or subnet) when you or your computer is looking for single name resources. (e.g. \fileserver ) If that computer is on that same subnet it will respond to the broadcast request and the connection will be made without needing DNS. But it’s only good for the local subnet! It is in effect a poor man’s DNS for a single subnet or small network. But in the corporate world, this “feature” is not needed and has become a security issue.
The problem is all computers on the same local network receive these broadcast requests, and if they so choose can respond to the request without any checks that the system responding is legitimate. Here’s how the hack works:
When a workstation makes a broadcast request looking for a resource (in our example \fileserver) a malicious computer (Workstation 2 in our example) can respond, tricking the requesting computer (Workstation 1) that they are the resource they are looking for. In a corporate environment (domain joined computers), the requesting computer will automatically attempt to authenticate to the malicious computer over normal Microsoft networking ports (TCP 445). The malicious computer runs spoofing software to capture the authentication process and will obtain the User ID and challenge/response password hash of the user logged-in to the requesting computer (Bob on Workstation 1 in our example). With the password hash (Bob’s) the hacker can now use offline password cracking tools such as Hashcat or John the Ripper to crack the password. Note: a Challenge/Response password hash cannot be used in a “pass-the-hash” attack only a raw LanMan or NTLM hash can be passed. However, most passwords can be cracked in minutes using modern word mangling rules built into Hashcat or John the Ripper. Or the malicious computer can relay the credentials from the requesting computer to a 3rd system and authenticate as that user – without knowing the password! This is called an SMB Relay attack. There are many tools to carry out this attack, SpiderLabs has a great standalone tool called Responder and Metasploit has auxiliary modules for this attack as well.
On a typical corporate network, an attacker can obtain the challenge/response password hashes of many users within minutes.
Once a hacker (or pen tester) has a valid user ID and password they can quickly use the access of that user to find other issues and obtain access to sensitive data. The beauty of this attack (from the hacker’s perspective) is that it is very stealthy. No port scanning or other noisy network traffic that might set off alerts.
The good news is that it’s relatively easy to prevent! The bad news is awareness of this attack is low and very few companies have implemented the fix. Here’s what you need to do:
Disabling LLMNR can be done via GPO (follow along on the screenshots)
Unfortunately Disabling NetBIOS cannot be done via GPO, I’ve provided screenshots on how to do this manually and also provided a reference to a script that could be pushed down via GPO to disable NetBIOS (See below)
The script to disable NetBIOS is at the end of the TechNet article https://technet.microsoft.com/en-us/library/ee692589.aspx
If you follow my recommendations above (after careful testing, of course) you will have a more secure environment with little effort or impact to the network. Hackers and penetration testers will find it more difficult getting a foothold on your internal network, hopefully, this will force them to try other attacks that are more likely to get noticed by your IDS/ logging processes. If you implement these changes, which I highly recommend, post a comment and let me know your experiences.
Content provided by LBMC security professional, Stewart Fey.
