It's not always DNS

Picture yourself immersed in the vibrant tapestry of a bustling bazaar. The air is alive with the intoxicating aroma of freshly ground spices, a symphony of exotic languages dances upon your ears, and an array of never-before-seen fruits beckon your gaze. In a fleeting moment of distraction, you lose sight of your companions. A pang of panic rises as you call out their names, hoping to be heard above the clamour.??

Suddenly, a friendly hand emerges from the crowd, seemingly gesturing for you to follow.

You are led away from the throng, down a narrow alleyway, before a chilling realisation washes over you. It's not your friend at all, but a stranger who, with a swift and practiced motion, relieves you of your valuables.

This encounter, though unsettling, serves as a poignant metaphor for the deceptive nature of Link-local multicast name resolution (LLMNR) attacks in the digital realm.

Like the seemingly harmless gesture in the market, LLMNR can lure unsuspecting users into compromising situations, leading to significant network security breaches.

So, what is LLMNR?

Link-Local Multicast Name Resolution (LLMNR) is a protocol used to resolve hostnames to IP addresses on local networks. It operates similarly to DNS but is designed for use within a local network segment when DNS servers are not available or do not have the necessary information.

How LLMNR Poisoning Works

For an LLMNR poisoning attack to work, an adversary must first establish a foothold on the network, usually by compromising an end user device. LLMNR attacks often occur when a user mistypes a file location or share name (e.g., \filserver\shared, missing the "e"), or when a network administrator mistypes the share name in the configurations. Another common scenario is when an organization deletes a share, and an employee tries to access it without knowing it no longer exists. ?This mistake results in a multicast LLMNR query being sent to all IPs on the network; an attacker can then exploit this by replying to the multicast message, pretending to be the legitimate resource. Consequently, the user's machine accepts the attacker’s request and sends NTLM hashes and other sensitive information like usernames, domain names, session tokens and cookies.

The most well-known tool to perform an LLMNR attack is called "Responder", which initialises an LLMNR server that maliciously responds to LLMNR requests from user machines. When a malicious response is sent to a user's machine, Responder pretends to know the location of a file or share and directs the user's machine to its own IP address. When this happens, the user's machine sends the NTLM hash for authentication, which can then be captured and displayed by Responder.

?

The NTLM hash is a particularly valuable prize for the attacker, as it is used to keep passwords confidential on the network during authentication. If an adversary can intercepts another user's NTLM hash (especially NTLMv1, a deprecated version), it can therefore be used to impersonate the victim and access otherwise inaccessible machines and servers. If an administrator NTLM hash that is used to manage the domain controller is compromised, everything on the network becomes accessible to the attacker, making ransomware attacks particularly damaging.

The attack scenario:

1. An adversary compromises a device inside the network and starts an LLMNR Responder.
2. The victim attempts to access a file or share in the network, but mistakenly mistypes the location path.
3. The victim’s machine, in an attempt to find the file or share, sends a multicast query out to all devices within the network.
4. The adversary’s LLMNR Responder then responds to the query with its own IP address as the supposed location of the requested resource.
5. The user’s machine sends their NTLM hash to the attacker’s responder.

Mitigations

Disabling LLMNR is the best solution to reduces the risk of spoofing and cache poisoning attacks by removing this vulnerable protocol from the network, forcing systems to rely on more secure alternatives like DNS. However, if DNS is not available or LLMNR is required as part of normal business operations, this can lead to connectivity issues and difficulties in accessing resources.

Alternative Mitigations

For many organisations, disabling LLMNR outright might cause issues. In these cases, the following alternative mitigations can be used to reduce the damage that can be caused by the attack:

1. Configure endpoint devices to prioritise DNS over LLMNR. This can be done through group policy settings or directly on individual machines to ensure that DNS is the primary name resolution method.
2. If NTLM authentication is required, ensure that LM (LAN Manager) authentication is disabled and NTLMv2 is enforced. NTLMv2 is more secure and resistant to certain types of attacks including cracking or passing the hash compared to LM or NTLMv1 because it uses stronger hashing algorithm and more resilient against Pass-the-Hash Attacks.
3. Implement a strong password policy. Complex, lengthy, and unique passwords make captured hashes harder to crack, reducing the chance of attackers using stolen credentials to move through the network or gain higher privileges.?

Wrapping it up

Adversaries are often looming in the shadows, pretending to be a friend down a dark alley way or hiding in your network impersonating a trusted device via LLMNR attacks. Attackers can abuse the over-trusting nature of LLMNR by posing as trusted resources to steal sensitive information like NTLM hashes to obtain unauthorised access to critical systems. To protect yourself, some vital steps should be taken, including disabling LLMNR and NBT-NS, emphasising secure authentication practices, and enforcing strong password policy.

Finally, Microsoft announced plans to deprecate NTLM hash in favour of Kerberos in the second half of 2024. Despite this move, we expect NTLM hashes will still be prevalent for the next few years.

?If you would like to learn about your organisation’s exposure to LLMNR attacks (amongst a wide variety of other network traversal and privilege escalation attacks) and to develop mitigation strategies tailored to your business and networking requirements, reach out at [email protected].

?