Cleaning Up Risky Traffic, A Mini Series: LLMNR

To view other posts in this mini series, select the tag “Cleaning Up Risky Traffic, A Mini Series”

Cleaning Up Risky Traffic, A Mini Series: LLMNR

Link-Local Multicast Name Resolution (LLMNR) is defined in RFC 4795 and became a standard protocol in Windows operating systems starting with Vista (it is also implemented in systemd-resolved on Linux). Basically, it is used to resolve hostnames on local networks, but really only comes in play on consumer networks where DNS may not be implemented. In corporate environments, LLMNR packets appear when someone or something is attempting to connect to a host for which there is no DNS entry (think fat fingering a file server name). So what happens?

Say your file server is file01.company.org. A user attempts to connect to file1.company.org. Their workstation first checks the hosts file, then queries DNS, and after those fail to yield results the workstation will send out a multicast LLMNR packet to all systems on its subnet asking “who is file1?”

So why is that bad? Well, if a machine then responds with “I’m file1!” there is no mechanism to validate that response. This means, that anyone on the network can respond to any LLMNR request and depending on what kind of connection was occurring, this could lead to password hashes being passed which can later be cracked.

In this article we will review what LLMNR is, what controls can be implemented to prevent compromise, a list of MITRE Tactics and CVE’s associated with LLMNR, and we’ll set up a honeypot to detect for this attack vector.

LLMNR Vulnerabilities

Every single pentest I have seen for the last several years starts the same way: Pentester opens a terminal, launches a program called Responder which responds to LLMNR requests (among other things), and minimizes said terminal to come back to later. In many, many environments this is THE method for gaining initial credentials on a domain. It is so common that I’ve had penetration testers accuse me of sticking them on an isolated guest network because they weren’t seeing any multicast traffic on our user segments.

In order to protect against LLMNR vulnerabilities, it is important to understand the risks associated with this protocol and to implement effective mitigation strategies. By disabling LLMNR, keeping systems up to date, and utilizing tactics such as network segmentation and endpoint detection and response, organizations can help to mitigate the risks associated with LLMNR and keep their networks safe from attacks.

1. Spoofing Attacks: LLMNR is vulnerable to spoofing attacks, where an attacker can send fake name resolution responses that redirect a user to a malicious website or resource. Tactic ID: TA444 – Ingress Tool Transfer – https://attack.mitre.org/tactics/TA0444/
2. Man-in-the-middle (MITM) attacks: LLMNR is also susceptible to MITM attacks, where an attacker can intercept and manipulate name resolution requests and responses. Tactic ID: TA444 – Ingress Tool Transfer – https://attack.mitre.org/tactics/TA0444/
3. Network Sniffing: LLMNR uses clear-text communication, which means that attackers can easily sniff network traffic and obtain sensitive information such as login credentials. Tactic ID: TA0003 – Credential Access – https://attack.mitre.org/tactics/TA0003/
4. Denial of Service (DoS) attacks: LLMNR can be used as an amplifier in DoS attacks, where attackers flood the network with name resolution requests, causing legitimate traffic to be dropped. Tactic ID: TA0040 – Resource Exhaustion – https://attack.mitre.org/tactics/TA0040/
5. Rogue Server Attacks: Attackers can set up rogue LLMNR servers on the network, which can be used to capture sensitive information or perform other malicious activities. Tactic ID: TA0005 – Defense Evasion – https://attack.mitre.org/tactics/TA0005/
6. Cache Poisoning: LLMNR relies on a caching mechanism to speed up name resolution. However, an attacker can exploit this mechanism by poisoning the cache with malicious entries, causing the system to resolve names to the wrong IP address. Tactic ID: TA0040 – Resource Exhaustion – https://attack.mitre.org/tactics/TA0040/
7. SMB Relay Attacks: LLMNR is also used in SMB (Server Message Block) Relay attacks, where attackers can hijack authentication attempts and gain access to sensitive resources. Tactic ID: TA0006 – Persistence – https://attack.mitre.org/tactics/TA0006/

LLMNR is commonly referred to as T1557.01 on the Mitre ATT&CK framework.

T1557.01 is a technique on the Mitre ATT&CK framework that refers to the use of LLMNR/NBNS poisoning and SMB relay attacks to gain initial access to a network. Additionally, there are several CVEs related to LLMNR that have been discovered over the years, and it’s important for organizations to stay up to date on these vulnerabilities to ensure their networks remain secure.

1. CVE-2017-11779 – This vulnerability in Windows Server 2016 and Windows 10 allows an attacker to perform a man-in-the-middle (MITM) attack by spoofing LLMNR responses, leading to the disclosure of sensitive information.
2. CVE-2018-8209 – This vulnerability affects Windows 10 and Windows Server 2016, allowing an attacker to intercept and redirect LLMNR traffic to a malicious host, resulting in the disclosure of sensitive information.
3. CVE-2020-16947 – This vulnerability in Windows Server allows an attacker to bypass security restrictions and execute code remotely via a specially crafted LLMNR response.
4. CVE-2020-16898 – This vulnerability in the Windows TCP/IP stack allows an attacker to execute code remotely by sending a specially crafted LLMNR response packet.
5. CVE-2021-24094 – This vulnerability in Microsoft Windows allows an attacker to remotely execute code by sending a specially crafted LLMNR response to a vulnerable system.

Note that this is not an exhaustive list, and there may be other CVEs related to LLMNR that have not been included.

Testing and Verification

Checking if LLMNR is in your environment is easy! Wireshark can be used to capture LLMNR traffic and analyze it for potential vulnerabilities. It is important for organizations to regularly test and verify their mitigation strategies to ensure they are effective against new and evolving threats. A good write-up for using Wireshark to capture LLMNR traffic can be found here:

https://en.wikiversity.org/wiki/Wireshark/LLMNR

Try using this before, and after the mitigation below!

Mitigation Strategies

Although Network segmentation, micro-segmentation, and IDS tools are effective controls for this vulnerability, perhaps the most effective control is disabling LLMNR altogether. This can be done by following the steps outlined in the previous article. It’s important to note that disabling LLMNR may cause some compatibility issues with older applications. Primarily if they resolve hostnames via broadcast traffic. If this is the the case, it is highly recommended the application is deprecated, or updated to use DNS.

Disabling LLMNR is easy, a simple GPO is all you need!

Here is an example GPO that can be used to disable LLMNR:

1. Open the Group Policy Management Console (gpmc.msc).
2. Create a new GPO, or edit an existing one.
3. Navigate to Computer Configuration > Administrative Templates > Network > DNS Client.
4. Double-click “Turn off multicast name resolution” to open the policy settings.
5. Select “Enabled” to turn off LLMNR.
6. Click “OK” to save the policy settings.
7. Link the GPO to the appropriate organizational unit (OU) or domain.

Once the GPO is applied, LLMNR will be disabled on all computers within the scope of the GPO. Even if a single host is compromised and this is disabled, other hosts will still ignore LLMNR traffic!

In Linux, modify /etc/systemd/resolved.conf and set LLMNR=no

Time For Some Honeypots!

Since a common first step in every pentest (and after getting a foothold from a malicous actor!) is launching Responder. Knowing that this is step one in so many attacker’s playbooks allows us to create a high-accuaracy Honeypot! There’s a tool that generates LLMNR broadcasts and then alerts if anything ever replies, it is called Respounder and it can be found here: https://github.com/codeexpress/respounder This runs great on a Raspberry Pi (or a tiny VM) and makes for a terrific low cost security monitor that should be 100% no false positives… If you have LLMNR disabled in your environment and Respounder alerts, then you got someone on your network.

Vulnerability Scanners and ‘Informational’ Vulnerabilities

You’ll notice on your vulnerability scanner (Nessus, Rapid7, etc.) that LLMNR and many other multicast traffic controls show up as a ‘low’ or ‘informational’ vulnerability. My assumption is that it scores this as Informational because LLMNR is not technically a “vulnerability” (assuming devices are patched). Meaning the software itself works as designed… There is no patch needing to be installed to make it secure.

It’s kind of like standing up an FTP server and allowing anonymous logins with full access. It’s a bad idea, but I wouldn’t expect a vulnerability scanner to scream about it unless you are running an FTP server with a known vulnerability.

In a vendor-centric world, a real internal conversation to be had at most orgs is about not hinging one’s security practices squarely on compliance requirements and/or “best practices” (present company included). Don’t count on 3rd party tools to make you secure. If they did, then we wouldn’t see breaches every week. I just recently learned more about maturity models, which are models that scan across multiple secure frameworks (NIST, PCI, GDPR, HIPAA and more) to look for overlapping controls that actually make a difference. check out SCF — Secure Controls Framework.

https://securecontrolsframework.com/

https://securecontrolsframework.com/capability-maturity-model/

Conclusion

In conclusion, LLMNR can pose a significant risk to network security if not properly understood and mitigated against. Disabling LLMNR, keeping systems updated, and utilizing tactics such as network segmentation and endpoint detection and response are all effective strategies for protecting against the vulnerabilities associated with LLMNR. Organizations should also regularly test and verify their mitigation strategies to ensure they are effective against new and evolving threats. By taking these steps, organizations can help to ensure the security of their networks and the sensitive information they contain.

For more information about this security control, feel free to reach out to blog@tridentstack.com. For professional services around this configuration, professionalservices@tridentstack.com, and lastly, for a full service SIEM/SOC/SOAR tool we highly recommend you check out our home page: https://tridentstack.com