From 0 to domain admin in only 5 minutes

Most companies nowadays use active directory to manage their Windows environments. This includes the pcs the employees use as well as many other services in their network such as fileservers, SharePoint, etc. In these environments a wide array of accounts is used, however the accounts attackers are the most interested in are the domain admins. This is because once an attacker gains access to a domain admin account the attackers usually have enough permissions to access any system/object in the network.

Attackers have discovered a plethora of attacks they could potentially perform in the attempt to get domain admin credentials. Here we will explain one of these attacks which gets often forgotten by sysadmins and security staff alike.

The attack we are covering today is the Link-Local Multicast Name Resolution(LLMNR) poisoning. This attack abuses the LLMNR protocol which by default is still enabled on any Windows device for the sake of legacy support.

Tldr

Attackers abuse the Link-Local Multicast Name Resolution (LLMNR) protocol to obtain valid hashes of any device in the network that issues an LLMNR multicast request.

What is LLMNR?

The Link-Local Multicast Name Resolution (LLMNR) is a protocol that is based on the Domain Name System (DNS). Which can be used to act as a host discovery/identification method in Windows systems as an alternative for the DNS protocol. LLMNR uses a multicast request which means that the client is asking every device in that network “Do you know where host X is?”. It then waits a short while for an answer from any device in the network in the hope any of them know the location of the file share. Attackers can abuse this by answering these requests and claiming they are what the device was looking for.

This protocol allows a host to perform name resolution on the same local network by sending a name resolution request using a multicast address to each and every host on the same network.

Windows Name resolution

By default, Windows systems use the following list of services to perform name resolution requests.

1. Local host file
2. Domain Name Service (DNS)
3. Link-Local Multicast Name Resolution (LLMNR)
4. NETBIOS Name Service (NBNS/WINS)

Attack scenarios

A pre-requirement for this attack to succeed is that a user/service tries to resolve a name that is not earlier in the Windows name resolution order. This means that neither the local host file and the DNS server can answer the before the LLMNR protocol gets triggered. Below a short list of scenarios that potentially could cause the LLMNR protocol to be used:

– Unreachable SMB shares: Many companies automatically map specific network drives to their employees devices. If these devices were to come in an environment where these shares are not reachable/missing the device will also issue an LLMNR request to try and locate these shares.
– Browser search bar: Multiple browsers try to resolve the name of single word string searches as if they were a hostname before using it in a search query. This means that every time you search for a single word in a browser it will first try to resolve it using the standard Windows name resolution order before treating the string search as a search term.
– Mistyping: As silly as it may sound if a user mistypes the name of a legitimate host the DNS server usually would not have a valid response for this resulting in LLMNR being used.
– Misconfiguration DNS infrastructure: If the DNS server either locally or remote has been misconfigured it could also cause for name resolution issues.
– Misconfiguration Web Proxy Auto-Discovery (WPAD): The WPAD protocol automatically tries to detect the web proxy settings by trying to fetch the URL of a proxy configuration file. For each URL it cannot resolve with DNS it will send out LLMNR requests. (Do note that this is not default behavior for Google Chrome and Mozilla Firefox, however it is for Internet explorer)

LLMNR poisoning

Adversaries can spoof an authoritative source for name resolution on a victim network by responding to LLMNR (UDP 5355)/NBT-NS (UDP 137) traffic as if they know the identity of the requested host, effectively poisoning the service so that the victims will communicate with the adversary-controlled system. If the requested host belongs to a resource that requires identification/authentication, the username and NTLMv2 hash will then be sent to the adversary-controlled system. The adversary can then collect the hash information sent over the wire through tools that monitor the ports for traffic or through network sniffing and crack the hashes offline through brute force to obtain the plaintext passwords.

LLMNR poisoning detailed example

First the client tries to resolve the \\fileshare name by using DNS.

The DNS then responds that it does not know any host named fileshare.

The client tries again to resolve the fileshare name, However this time it uses LLMNR using a multicast request asking the entire subnet if they know the location of the fileshare.

The attacker then responds to this request claiming they are \\fileshare. Additionally the attackers device requests the client to send their username and hash to them.

The client then proceeds to send their username and NTLMv2 hash to the attackers device.

The attacker issues an authentication failed response code after capturing the hash, resulting in the termination of the connection.

Conclusion

LLMNR poisoning is an attack that is still to this day and age a very big risk to many active directory environments, because this feature is enabled by default and forgotten by a large amount of IT admins and security people alike. Unless dealing with legacy systems the LLMNR feature should be disabled on all devices to mitigate this type of attack.