How poisoning legacy broadcast name resolution protocols led to domain compromise
In a recent client engagement, the HALOCK Security Team identified a significant yet common weakness in a client’s Windows environment: a reliance on legacy protocols, specifically Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS). While Windows hosts typically use DNS to resolve hostnames, they fall back on these older protocols when DNS is unavailable or unable to resolve the requested hostname.
These legacy protocols are considered weak because they can be exploited by attackers to perform malicious activities like man-in-the-middle attacks, where they can intercept or redirect network traffic.
HALOCK Security Labs Internal Network Penetration Testing addresses controls and safeguards within the private network and systems of an organization. HALOCK’s penetration testers attempt to gain access to assets by targeting networks, hosts, and all responding controls currently in place to simulate insider threats. This service is commonly utilized to fulfill PCI DSS annual requirements, or six-month requirements if the organization is a service provider. But it can be offered for any legitimate reason if there are suspected threats to the internal network.
All HALOCK Security Labs penetration tests are performed with consent in controlled environments.
How did this exploit work?
In a real-world scenario, malicious hosts on the network can impersonate legitimate servers and respond to the discovery messages sent by systems using legacy protocols like LLMNR or NBT-NS. Here’s how the attack unfolds:
Discovery via LLMNR or NBT-NS: When a Windows device is unable to resolve a hostname through DNS, it will fall back on legacy protocols such as LLMNR or NBT-NS to try and discover the requested host. These protocols send broadcast requests to the local network for name resolution.
Poisoning the Response: The attacker, monitoring the network, can respond to these discovery requests as though they are the requested host. This tricks the requesting device into thinking it’s communicating with the legitimate server, when in fact, it’s communicating with the attacker’s machine.
Authentication and Capturing Credentials: When the legitimate device attempts to authenticate with the malicious host, it sends its username and password hash. The attacker captures this authentication attempt, which includes the password hash, potentially providing access to sensitive credentials.
Credential Relaying: The attack doesn’t stop at just capturing the password hash. If the network doesn’t enforce SMB Message Signing (a security feature that helps ensure the integrity of SMB communications), the attacker can relay these captured credentials to other systems on the network, gaining authenticated access. If SMB signing is enforced, the attacker would have to crack the captured password hash offline before exploiting the account.
HALOCK’s team took the following steps in the attack:
Identifying Vulnerable Hosts: HALOCK first identified hosts on the network that didn’t require SMB Message Signing. These were vulnerable to credential relaying.
Using Tools for Credential Relaying: After identifying the vulnerable systems, the team used Impacket’s ntlmrelayx.py tool, which is designed to handle the relaying of credentials. This tool allows the attacker to forward the captured credentials to a target system, potentially gaining unauthorized access.
Intercepting Requests with Responder: HALOCK then used the Responder tool to intercept LLMNR and NBT-NS requests. When a device on the network sent a name resolution request, Responder would respond as if it were the legitimate host, tricking the client into authenticating against the attacker’s system. This captured the NetNTLM hash (a form of the password hash).
Privilege Escalation and Domain Compromise: Eventually, HALOCK captured credentials for a domain user account and relayed them to systems that didn’t enforce SMB Message Signing, granting authenticated access. Upon further investigation, HALOCK discovered that the user account had local administrator privileges on two systems. This access allowed them to extract more credential material from those systems.
The team submitted several Domain Cached Credential (DCC2) hashes for offline brute-forcing. One of these hashes belonged to a Domain Administrator account. Because the password was weak, it was easily cracked offline, giving HALOCK full Domain Administrator access.
With the Domain Administrator account, HALOCK fully compromised the domain and moved forward with establishing persistent privileged access for the remaining testing period.
What did we learn and how can this type of exploitation be prevented?
By poisoning legacy broadcast name resolution protocols, HALOCK was able to intercept NetNTLM authentication and relay credentials to gain unauthorized access to Windows systems, ultimately obtaining Domain Administrator-level access. HALOCK went on to access network shares containing sensitive business, operational, and employee data. Access to critical manufacturing equipment was also obtained.
Had this attack been executed by a real-world adversary, the impact could have been devastating for the business, leading to ransomware deployment, financial fraud, or corporate espionage.
Mitigation for This Type of Attack:
Disable LLMNR and NBT-NS: Since modern networks use DNS for name resolution, disabling these legacy protocols eliminates this attack vector.
Enforce SMB Message Signing: Enforcing SMB signing ensures that attackers cannot relay credentials to vulnerable SMB servers.
Enable LDAP Channel Binding and EPA: Enforce channel binding and Extended Protection for Authentication (EPA) to prevent NTLM relay attacks over LDAP.
Monitor and Detect LLMNR and NBT-NS Attacks: Use SIEM solutions to monitor network traffic for excessive LLMNR and NBT-NS queries. Look for Windows event IDs 4624 (logon attempts) and 8004 (NTLM authentication) to detect unusual activity.
Aaron Lesmeister – Internal Network Penetration Testing
