LLMNR / NBT-NS: You’re Poison!

By Ben Rediboim - 09 Dec 2020.

Tags:

Attention Windows sysadmins: search for "LLMNR" and once you've finished panicking, then get that nonsense disabled.

Over the past year and over 50 internal network penetration tests, one issue in particular keeps popping up and is regularly overlooked: LLMNR / NBT-NS Poisoning.

Many organizations are reluctant to patch this. You should not underestimate this vulnerability. It is dangerous, very common, often overlooked, easily exploited, and provides an attacker many paths to compromise your systems and domains.

Overview

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are two components Microsoft Windows systems use as a backup when DNS is unable to resolve a user’s query.

If one endpoint attempts to resolve a particular host, but DNS resolution fails, the machine will then attempt to ask all endpoints on the local network for the correct address via LLMNR or NBT-NS. Even though this seems harmless in theory, it enables an attacker to poison responses and perform various attacks to obtain unauthorized access to the network.

With the exception of a few, most customers will prefer not to remediate this issue as some systems fall outside the agreed upon rules of engagement still rely on these obsolete components and operate under different security and risk profiles.

Much has been said and blogged about this vulnerability, its’ technical details, and how to abuse it using open source tools. Here we will show you how easy it can be for an attacker to chain this and other vulnerabilities together to compromise multiple systems, and often even a full domain.

All paths lead to Domain Admin

As a first step, we will use our tool of choice: Responder.

Responder essentially advertises itself on a network, and whenever a client cannot resolve a name via DNS or if a wrong name (e.g., a typo) has been entered, it will take the “identity” of that resource and receive the authentication from the client.

Frequently, we start getting responses containing usernames and the password hashes within a few minutes to a couple of hours.

Responder in Action

This is our starting point in the attack, and we can proceed in multiple directions at this point.

Path 1 – SMB Signing Not Required

SMB Signing Not Required

From Microsoft:

Server Message Block (SMB) is the file protocol most commonly used by Windows. SMB Signing is a feature through which communications using SMB can be digitally signed at the packet level. Digitally signing the packets enables the recipient of the packets to confirm their point of origination and their authenticity. This security mechanism in the SMB protocol helps avoid issues like tampering of packets and “man in the middle” attacks.

If SMB signing is not required on the target host, it will enable us to use the credentials (username + hashed password) and authenticate to it without needing to crack the password, also known as a “pass-the-hash” attack.

Unsigned SMB Screenshot

Once logged in, we can use Mimikatz and obtain more credentials, in cleartext.

Mimikatz in Action Screenshot

Or simply dump a bunch of locally stored credentials for further off-line cracking attempts.

Dumping Hashes Screenshot

Path 2 – Weak Passwords

Weak Passwords Cracked

From CWE:

Authentication mechanisms often rely on a memorized secret (also known as a password) to provide an assertion of identity for a user of a system. It is therefore important that this password be of sufficient complexity and impractical for an adversary to guess. The specific requirements around how complex a password needs to be depends on the type of system being protected. Selecting the correct password requirements and enforcing them through implementation are critical to the overall success of the authentication mechanism.

Another challenge for many organizations is getting users to choose and maintain strong passwords. It can be exceptionally difficult to achieve a balance between complex and usable passwords. If the password policy requires many factors, human nature dictates that users will always find ways to make remembering and re-using their passwords easier. This is also the reason why attackers will successfully crack them.

So, after collecting a few sets of usernames and password hashes, we will attempt to crack as many of them as possible offline with our password cracking tool of choice (e.g., Hashcat, John-the-Ripper, etc.).

Here we must consider some factors, time being a major one. In a real-world scenario, an attacker will usually have a few months at their disposal, but when conducting a time-boxed penetration test, we need to show the value in a shorter amount of time. We use the same techniques that actual attackers use, such as utilizing the cloud (AWS, Azure) to deploy large numbers of GPU instances to help with the cracking process, and dictionaries/password lists that will be customized to the organization being targeted.

When people use weak passwords that are either too short, contain dictionary words, or have been re-used, the cracking time drops significantly. Often passwords can be cracked in a matter of minutes.

Cracked!

Once we have a few juicy credentials (i.e. admins, service accounts) in our hands, we can try to spray them across the network to see which machines could be compromised.

Compromised

Mitigation and Remediation:

Require SMB Signing

SMB signing and security signatures can be configured for the Workstation service and for the Server service. The Workstation service is used for outgoing connections. The Server service is used for incoming connections.

We recommend the use of Group Policies to configure SMB signing because a local registry value change does not function correctly if there is an overriding domain policy.

Disable LLMNR & NBT-NS

Active Directory has a GPO that can be configured to prevent its domain workstations from using LLMNR. Disabling NBT-NS can be done manually on each client through the network connection properties or on the domain clients getting IP addresses from a DHCP server.

Improve password policies (This is a large topic that could fill an article itself)

First and foremost, employees should be aware of the risks associated with using and re-using weak passwords. Then you can improve the technical aspects by leveraging password re-use plugins (Dehashed, HaveIBeenPwned), encouraging the use of password managers, and employing better password policies all around.