Field Reports
LLMNR & NBT-NS Poisoning
Field Report: Listening to the Network’s Whispers (LLMNR/NBT-NS Poisoning)
In this report, we look at how a simple configuration oversight allowed me to intercept user credentials and move laterally across the domain without even needing to scan a single port.
The Setup: Sitting and Waiting
During the initial phase of this internal assessment, I didn’t start with aggressive scanning. Instead, I simply started “listening.” Many Windows environments still have LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) enabled. These are fallback protocols used when a computer can’t find a host via DNS. If an internal network has these services enabled, adversaries can spoof an authoritative source for name resolution on the victim’s network by responding to LLMNR (UDP 5355)/NBT-NS (UDP 137) traffic as if they know the identity of the requested host.
When a user requests a named resource, the name of this resource needs to resolve to an IP address so that the user’s computer knows where to send the network traffic. If enabled and no other methods resolved the name of the resource, LLMNR and NBT-NS queries will be sent to all other hosts on the local network, asking them to respond if they know the IP of the hostname being queried.
The Catch: Harvesting Hashes with Responder
To pull this off and exploit the protocols, I fired up Responder, the industry standard for LLMNR/NBT-NS poisoning. As soon as a victim machine sent out a multicast request, Responder jumped in the middle, claiming to be the destination the user was looking for. For a comprehensive cheat sheet on how to use Responder, click here.
Because the victim system believed they were talking to a legitimate internal server, their machine automatically attempted to authenticate using the Net-NTLMv2 protocol. Responder captured these “handshakes”, which contain the user’s username and an encrypted version of their password (the hash). The commands I used were:
sudo responder -I ens33 -v -FDdP sudo responder -I ens33 -v -FDdw
It didn’t take long to get a hit.
I took the captured hash offline and ran it through a dictionary-based brute-force attack using John the Ripper. Because the user was using a weak, easily guessable password. The plain-text password was revealed almost instantly. For a great cheat sheet on using John the Ripper, click here. The command I used was:
john Responder_Hashes.txt --wordlist=/home/mrnobody/Hacking/CustomPasswords/common_custom --rules=ALL --fork=4
If you’re wondering why the terminals look different, the way I prefer to test an internal network is to ship a dropbox to the client. I connect to it remotely and run tools like Responder and then I copy and crack the hashes on my local system at home.
The Pivot: SMB Relaying
Cracking passwords is high-value and opens the door for several authenticated tests and data extraction (Bloodhound is a must), but relaying them is often the path of least resistance. For machines that didn’t have SMB Signing enforced, I didn’t even need to crack the hashes. I simply caught the authentication attempt from one user and relayed it to another server on the network.
This gave me an interactive SMB client shell, allowing me to browse sensitive file shares as if I were that user. The commands used were:
#Responder to capture hashes (Turn off SMB in resonder config) sudo responder -I ens33 -v -FDdP #Ntlmrelayx to relay Responder hashes (Use Netexec to get a list of machine with no SMB signing) impacket-ntlmrelayx -tf targets.txt -socks -smb2support -i #Proxychains to access relayed SMB session proxychains smb-client domain/[email protected]
The Impact
This attack is particularly dangerous because it requires zero prior knowledge of the network. By exploiting these legacy protocols, an attacker can:
-
Obtain Domain Privileges: Access resources in the context of the captured user’s account.
-
Access File Shares: Combine the credentials with other vulnerabilities to reach sensitive SMB shares.
-
Complete Account Takeover: Crack the password hashes to gain full access to the user’s account.
Remediation
Disable LLMNR
- Open gpedit.msc
- Goto Computer Configuration -> Administrative Templates -> Network -> DNS Client
- Click on “Turn Off Multicast Name Resolution” and set it to “Enabled”
Disable/Configure WPAD
To disable WPAD, you must turn off the automatic proxy configuration settings option in Internet Explorer
- In group policy, expand User Configuration>Administrative Templates>Windows Components>Internet Explorer>Disable changing Automatic Configuration settings
- Another option is to configure WPAD, as this will make poisoning the entry impossible.
Local Windows Firewall
Create a LLMNR Windows Firewall block 5355 UDP
