In the world of penetration testing, one of the most important steps in compromising an environment is gaining authentication. In the realm of Microsoft™ Windows™ operating systems, one of the most common ways to accomplish this is abusing the native and default enabled name resolution protocols – NetBIOS and LLMNR. What are these protocols and why are they enabled in an environment? How do they work? How are attackers using them? What can an attacker do with this access once gained? Let’s explore.
First, let’s break down these terms. NetBIOS-NS stands for network basic input/output system name service. NetBIOS-NS is often referred to as its base application programming interface, NetBIOS, for short. LLMNR stands for link-local multicast name resolution.
NetBIOS and LLMNR are protocols used to resolve host names on local networks. Their main function is to resolve host names to facilitate communication between hosts on local networks. NetBIOS is generally outdated and can be used to communicate with legacy systems. LLMNR is designed for consumer-grade networks in which a domain name system (DNS) server might not exist. NetBIOS is enabled by default on Microsoft Windows 2000 machines and above (while existing independently of DNS in older versions), and LLMNR is enabled on Microsoft Windows Vista™ machines and above.
On a network using the transmission control protocol (TCP) and internet protocol (IP) stack, which includes most networks today, it is necessary to convert names of resources to IP addresses to connect to these resources. So a network would need to resolve “resource.domain.com” to its IP address of “x.x.x.x” in order to know exactly where to send the traffic. Microsoft Windows clients follow a sequence of methods when attempting to resolve a name to an address, stopping the search when it successfully matches a name to an IP address.
When a computer requests a network resource, it usually follows the hierarchy of queries (using slightly different configurations) specified below to identify the target resource. It stops once the name is identified.
Note that the NetBIOS name of a computer and its host name can be different. However, in most cases, the NetBIOS name is either the same or a truncated version of the full host name. NetBIOS name resolution to an IP can happen via broadcast communications, using a WINS server, or using the LMHOSTS file.
The main issue with these protocols is the inherent trust the victim computer assumes with other devices within its segment of the network. If the computer cannot identify the resource it’s looking for among the first four steps listed above, our favorite local name resolution protocols come into play. The best example of this is when a user mistypes the name of a resource or requests a resource that is no longer reachable.
Naturally, this scenario occurs often in user segments of the network, and this is where the attacker enters. Once the attacker notices that these resources are being requested on the network via either LLMNR or NetBIOS-NS, nothing is stopping the attacker from responding to the victim computer and is essentially telling it, “Yes! I’m that network resource!” In fact, the attacker’s response goes further – it tells the victim computer, “Not only am I that network resource, but you should authenticate to me!” Sure enough, the victim computer responds to the attacker with a hashed version of its network credentials. Exhibit 1 details the exploitation steps associated with the vulnerable network discovery protocols:
Source: Crowe Horwath
The usual goal here is for the attacker to obtain the user credentials from the victim machine. In the end, to get the actual password in “cleartext” such that it is usable to gain authentication to the network, the hashed passwords must be cracked in their NetNTLMv2 format.
Cracking passwords can be achieved via a hybrid dictionary attack, which takes a significant amount of computing, depending on the strength of the password. Briefly described, the password cracking via a hybrid dictionary attack entails taking a large list of potential passwords (including common passwords and dictionary words) and a set of rules for transforming those passwords (such as combining them, swapping out zeroes for O’s, or adding numbers and special characters to the end). Once these passwords and rules are available, then they are hashed with the same one-way algorithm as the password and then compared to see if they are the same.
Alternatively, attackers can perform the same attack simply by trying every possible combination of all possible characters. Called a “brute force” attack, this method generally takes much longer, depending on the length of the password.
Another possible attack vector is for the attacker to relay the credentials to another system in the environment in which those credentials are valid. This method is similar to the previously described method, except for instead of simply saving the credentials, the attacker aims them at another, second system. If the account’s credentials are valid on the second system, then the attacker can successfully gain access to that system. This method allows an attacker to pivot around an environment, and it can be repeated until access is gained to all reachable systems upon which the relayed credentials are valid.
To recap, the conditions necessary for such attacks to occur include the following:
Now that we understand the grave implications of leaving these protocols enabled, how do we get these off the network?
Since most enterprise networks use dynamic host configuration protocol (DHCP), NetBIOS name resolution can be disabled through DHCP server options that apply to each network interface card (NIC) that requests an IP address, such as the network adapter on each computer. The Microsoft support site describes the detailed steps to accomplish this on each DHCP server.
As for LLMNR, it can be disabled through the Group Policy. The appropriate configuration is to set “Turn off Multicast Name Resolution” to “Enabled” as follows:
Source: Crowe Horwath
As an alternative to disabling NetBIOS through the DHCP server(s), one can also create a one-time logon script to run on each Windows device by configuring the following registry key value “NetbiosOptions” to “2” as follows:
In addition to disabling NetBIOS on the NIC of each computer and through DHCP and disabling LLMNR, the outbound NetBIOS and LLMNR traffic should be restricted on the host firewall of each system by blocking the NetBIOS protocol and TCP port 139 as well as the LLMNR UDP port 5355. This step can prevent any NetBIOS or LLMNR traffic from accessing or leaving the computer, even when the device is taken out of the corporate network and connected to less secure public networks.
Lastly, in terms of the third condition of this attack, if user passwords are too strong for attackers to crack, then they cannot do much locally with the NetNTLMv2 hashed credentials they have obtained via these protocols. According to previous posts on this blog discussing password expirations and password policies, once a password reaches a length of around 16 characters and does not consist of solely common dictionary words, it becomes exponentially harder to crack via the methods described in this post. As for the possible relay of credentials, server message block (SMB) signing should be put in place where possible to prevent the relay of credentials in the NetNTLMv2 format across the network. For more details about the protections offered by SMB signing, check out this post on Microsoft’s TechNet blog.
Although the options discussed here are not the sole answer to addressing the vulnerability of name resolution protocols, they’re a good layer to add to your security controls and strengthen your environment, even once these overly-generous protocols are incapacitated.
Many features of the Microsoft Windows operating system are designed for ease of use rather than security. The NetBIOS and LLMNR name resolution protocols enabled by default are just another example of features designed to make connectivity easy for end users but that also open the door for attackers on your network. Evaluating these default configurations and disabling those that are not absolutely necessary to create a secure computing baseline is a critical step to any workstation deployment in an enterprise environment. A great starting point would be the examples of baselines provided by the Center for Internet Security, the National Institute of Standards and Technology, the U.S. National Security Agency (you will need to install the Department of Defense's root certificate to view the site securely), and, of course, Microsoft. Hopefully this post has highlighted at least one strategy that brings you one step closer to the secure baseline that’s right for you and your organization.
Microsoft, Windows, and Windows Vista are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.
Jonathan Avery | Posted: Feb. 18, 2018
Great write-up Michael. I plan on sitting for the new CompTia PenTest+ exam soon, both NetBIOS and LLMNR vulnerabilities are on the objective list. Your information will help me with those topics, as well as be more aware of those potential weaknesses in my systems.
In accordance with applicable professional standards, some firm services may not be available to attest clients.
© 2018 Crowe Horwath LLP, an independent member of Crowe Horwath International.
As of June 1, 2016, the professionals of AbleBridge have joined Crowe Horwath LLP, a public accounting, consulting, and technology firm. We continue our focus on Microsoft Dynamics® CRM (now Dynamics 365) sales and implementation as well as innovative add-on products.
The personnel of SDGblue have joined Crowe Horwath LLP, a public accounting, consulting, and technology firm with a global risk consulting practice and offices around the world. This move provides SDGblue clients access to a broader range of products, services, and solutions, while expanding the Crowe cybersecurity risk management capabilities with a deeply specialized team.
Looking for the Client Login?
Access the SDGblue Client Portal
As of Oct. 30, 2017, the professionals of Rowbotham International have joined Crowe Horwath LLP, a public accounting, consulting, and technology firm. We continue our focus on domestic and international tax and audit compliance services, as well as advisory services.
The personnel of Tru8 Solutions LLC have joined Crowe Horwath LLP, a public accounting, consulting, and technology firm with a global risk consulting practice and offices around the world. This move provides Tru8 clients access to a broad range of products, services, and solutions, while deepening the Crowe GRC technology expertise to manage risk by better leveraging data and gaining more predictive insight.