Some cybersecurity issues draw attention because they’re newly discovered.

Others draw attention because they remain prevalent in enterprise environments long after they should have been addressed.

Link-Local Multicast Name Resolution, or LLMNR, and NetBios Name Service, or NBT-NS fall squarely into the second category. They’re not new weaknesses, and aren’t especially obscure. And yet RMC continues to encounter them during client assessments as a common pathway to credential exposure and broader compromise.

For many organizations, LLMNR/NBT-NS remain enabled simply because they are part of the default behavior in Windows environments. They are link-local name resolution protocols (multicast on the local subnet), primarily useful in small or poorly configured networks. In properly configured enterprise environments (e.g., DNS integrated with Active Directory), they should not be relied upon for business continuity. In modern enterprise networks, LLMNR/NBT-NS provide little operational value while introducing disproportionate security risk, which is why disabling them is considered a baseline hardening measure.

What is LLMNR?

At a high level, LLMNR is a fallback name resolution protocol. When DNS cannot resolve a name, Windows systems may use LLMNR to find the requested device on the local network. Microsoft describes LLMNR as a protocol for link-local scenarios where conventional DNS resolution is not possible. NBT-NS serves a similar legacy purpose by helping Windows systems identify devices by name on the local network.

In a small or informal environment, that may sound useful. It can help devices discover one another when central name resolution is unavailable or incomplete. Microsoft has also noted that disabling LLMNR may be noticeable in less structured networks, such as home environments where a user is trying to connect to a printer.

But enterprise environments are different.

In a corporate network, especially one supporting critical operations, fallback behavior that blindly trusts local responses can create an opening for attackers. When a system sends an LLMNR query, an attacker on the network may be able to answer that request first, impersonate the device being sought, and trigger authentication activity from the victim system. Microsoft’s own security guidance describes this as part of adversary-in-the-middle behavior and recommends reducing that risk by disabling LLMNR and NBT-NS.

Why this matters in real environments

RMC continues to encounter LLMNR and NBT-NS during client assessments because they often remain enabled by default and go unaddressed. While it may seem like a minor legacy protocol issue, it can create a meaningful path for attackers to capture credentials, gain a foothold, and move deeper into an environment.

In many cases, the risk becomes even more serious when LLMNR is combined with weak password practices, authentication weaknesses that allow attackers to relay access to other systems, or other defensive gaps. What looks like a routine configuration oversight can become part of a larger chain that leads to significant compromise.

That’s what makes LLMNR and NBT-NS worth addressing. The concern is not simply that the protocols exist. It’s that they can still play a role in real-world enterprise attacks when organizations assume default settings are secure enough.

This is not merely an assessment finding. It reflects tradecraft that’s also appeared in real-world intrusions. Public reporting and MITRE ATT&CK have linked LLMNR and NBT-NS poisoning, often paired with Server Message Block (SMB) relay and tools such as Responder, to real-world threat activity, including use by advanced persistent threat (APT) actors to harvest credentials and move laterally through compromised environments.

The bigger problem behind LLMNR and Similar Legacy Protocols

LLMNR reflects another major enterprise security issue: too many organizations assume vendor defaults align with security best practices. Often, they don’t.

One recurring pain point is that technical teams may follow Microsoft documentation or deploy standard configurations and still end up with critical exposure – resulting in a knowledge gap. The system was implemented correctly from a product standpoint, but not sufficiently hardened from a security standpoint.

That’s another important distinction for security leaders, OT operators, and infrastructure owners.
Vendors generally deliver products that are functional and broadly deployable. It’s still the responsibility of the organization to harden those products based on their environment, threat model, and risk tolerance. In other words, default settings are not the same as secure settings.

LLMNR and NBT-NS are good examples of how long-known weaknesses can remain embedded in enterprise networks.

Why mature organizations still miss it

It would be easy to assume that only immature security programs still struggle with something like LLMNR. In practice, that’s not always true.

Many organizations are focused on bigger headline issues like ransomware, third-party risk, identity governance, cloud exposure, and regulatory mandates. Although those are legitimate priorities, older protocol risks can remain in the environment for years because they are treated as routine, low-level, or effectively handled when they may still create meaningful exposure.

This is especially true in environments where teams are balancing legacy systems, segmented operations, incomplete asset visibility, constrained maintenance windows, and the fear that changing a long-standing protocol could disrupt critical operations. In many cases, LLMNR remains enabled not only because it’s a Microsoft default, but because backward compatibility and a “don’t touch it, it works” mindset make these legacy protocols harder to remove. Seemingly small weaknesses persist because nobody has fully owned the remediation, or because the organization assumes a standard Microsoft deployment is already reasonably secure.

That assumption can leave organizations more exposed than they realize.

What organizations should do now

For many enterprise environments, the first step is straightforward: determine whether LLMNR is still enabled anywhere it’s not needed and disable it where doing so is practical and supportable. But that decision isn’t always as simple in OT and ICS environments, where some vendors may still rely on legacy name resolution behavior and may not support systems configured where LLMNR or NBT-NS are disabled.

Microsoft has stated that organizations can reduce this risk by disabling broadcast name resolution via LLMNR and NBT-NS, and that LLMNR can be turned off through Group Policy, Intune, or the registry. Microsoft also notes that disabling LLMNR should not negatively affect environments where DNS is properly resolving required names. Notably, it isn’t enough to simply disable LLMNR. If LLMNR fails, Windows will conveniently fall back to NBT-NS. This is why it’s imperative to check for and disable both legacy protocols.

Remediation must be guided by environment-specific risk, not just a blanket hardening checklist. Where disabling these protocols is feasible, organizations should do it. Where it’s not, they should focus on compensating controls that reduce both the likelihood and impact of abuse.

Organizations should also evaluate the surrounding controls that determine whether an attacker can turn name resolution abuse into meaningful access. Those include:

• DNS health and name resolution hygiene
• NTLM exposure and legacy authentication pathways
• SMB signing enforcement
• password strength and resistance to cracking
• network segmentation, especially between IT and OT environments
• blocking SMB and other unnecessary protocols at the IT/OT boundary
• detection capabilities that can identify poisoning, spoofing, or suspicious authentication behavior tied to LLMNR or NBT-NS
• visibility into where broadcast and fallback protocols are still in use

This is where security maturity and detection capabilities become important. In a traditional enterprise environment, disabling a risky fallback protocol may be the right answer. In OT, the better answer may be containing the exposure through segmentation, protocol restrictions, and detection. Either way, the goal is the same: reduce the attacker’s ability to see the traffic, intercept authentication, and turn a legacy protocol into broader access.

The RMC perspective

At RMC, we believe one of the most persistent cybersecurity problems isn’t always the newest exploit. Often, it is the accumulation of long-known weaknesses that remain embedded in business and operational environments because they were never revisited after deployment.

LLMNR and NBT-NS are familiar examples of that problem.

They are legacy convenience features that may still serve a purpose in loosely managed networks, but in enterprise environments they often create more risk than value. When left enabled, they can help attackers collect credentials, impersonate systems, and establish footholds that lead to more significant outcomes.

That’s why this issue keeps showing up in assessments – and why organizations should not dismiss it as old news.

If your environment still relies on default name resolution fallbacks, the real question is whether LLMNR is serving a legitimate business need or preserving an opportunity for attackers.