Port 5355: LLMNR — The Trusting Fallback

Port 5355 is the home of Link-Local Multicast Name Resolution (LLMNR), a protocol that exists because sometimes DNS isn't there. When a Windows computer can't find a hostname through proper DNS channels, it shouts the name into the local network on port 5355, hoping someone will answer.

Anyone can answer. That's the problem.

What LLMNR Does

When you type a computer name into Windows Explorer or try to connect to a network share, your computer first asks DNS: "Who is ACCOUNTING-PC?" If DNS doesn't know, Windows doesn't give up. It broadcasts an LLMNR query to the multicast address 224.0.0.252 (or FF02::1:3 for IPv6) on port 5355, essentially asking everyone on the local network: "Does anyone know where ACCOUNTING-PC is?"

If a machine on the network has that name, it responds with its IP address. The protocol uses the same packet format as DNS, supports all DNS query types, and operates as a peer-to-peer system with no central authority.¹

The key word there is "anyone." LLMNR has no authentication mechanism. No verification. No way to prove that the machine answering is actually the machine you're looking for.

The Protocol Mechanics

LLMNR operates on both UDP and TCP port 5355. The typical flow works like this:

1. A host fails to resolve a name through configured DNS servers
2. The host sends a UDP multicast query to port 5355
3. Any host on the local link can respond via unicast
4. The querying host accepts the response and connects

The protocol includes some timing constants: a 100 millisecond jitter interval to prevent synchronized broadcasts, and a 1 second timeout for responses.² Link-scope multicast addresses ensure queries don't propagate beyond the local network segment.

Unlike mDNS, which sends responses via multicast so all devices can cache them, LLMNR sends responses via unicast, so only the querying device sees the answer.³

The History

The story of LLMNR begins with a problem that seemed innocent enough: how do you find computers on a small network when there's no DNS server?

In 2000, Bill Woodcock and Bill Manning proposed the original multicast DNS concept, funded in part by DARPA grant #F30602-99-1-0523.⁴ Their work laid the foundation for local name resolution without centralized infrastructure.

Microsoft took this concept and developed LLMNR through the IETF's DNS Extensions working group. Bernard Aboba, Dave Thaler, and Levon Esibov, all Microsoft engineers at Redmond, authored the specification.⁵ Aboba was a member of the Internet Architecture Board and co-chaired the IETF AAA and EAP Working Groups. These weren't junior engineers shipping untested code; they were protocol architects who understood networking deeply.

The document was originally intended for advancement as an IETF Proposed Standard, but the IETF couldn't reach consensus on the approach. RFC 4795 was published in January 2007 as an Informational document, not a standard.⁶ Despite this lukewarm reception from the standards body, Microsoft shipped LLMNR enabled by default in Windows Vista in January 2007, and it remained enabled in Windows 7, 8, 10, and 11.

The protocol solved a real problem. Home networks in the mid-2000s often had no DNS server. Small office networks might have a router providing DHCP but no local DNS. LLMNR let computers find each other by name without requiring users to understand IP addresses or set up infrastructure.

The Security Catastrophe

Here's what makes LLMNR a penetration tester's favorite protocol: when a Windows computer can't resolve a name through DNS, it broadcasts a plea into the network. An attacker just has to answer faster than anyone else, or answer when there's no legitimate responder at all.

The attack is classified as MITRE ATT&CK technique T1557.001: Adversary-in-the-Middle via LLMNR/NBT-NS Poisoning.⁷

The Responder tool, created by Laurent Gaffié (SpiderLabs), is the canonical implementation of this attack.⁸ When a victim broadcasts an LLMNR query, Responder answers with its own IP address. The victim's computer, trusting the response, attempts to authenticate to what it thinks is a file share or other resource. Instead, it sends its NTLMv2 authentication hash to the attacker.

The attacker can then either crack the hash offline using tools like Hashcat or John the Ripper, or relay it to other systems in the network for immediate access without ever knowing the password.⁹

The attack requires no exploitation of software vulnerabilities. It's not a bug. It's the protocol working exactly as designed, except someone malicious is participating in the conversation.

Even if a user doesn't type credentials into a dialog box, Windows may automatically send NTLMv2 hashes when connecting to what it believes is a trusted network resource. The user sees nothing. The attacker captures authentication material.

This isn't theoretical. LLMNR poisoning is one of the first techniques penetration testers try on internal network assessments. It works disturbingly often.

The Slow Phase-Out

In April 2022, Microsoft announced they were beginning to phase out LLMNR and NetBIOS name resolution in favor of mDNS (Multicast DNS).¹⁰ The transition is ongoing. In recent Windows Insider builds, NetBIOS operates in "learning mode," where it only activates if both mDNS and LLMNR fail.

The irony is that mDNS, standardized as RFC 6762 in 2013, has its own security concerns. But it at least achieved IETF standard status, something LLMNR never did.

For now, LLMNR remains enabled by default on most Windows systems. Every corporate network, every small business, every home network with Windows machines is potentially running a protocol that will happily accept false answers to name queries.

How to Disable LLMNR

Through Group Policy:

• Navigate to Computer Configuration → Administrative Templates → Network → DNS Client
• Enable "Turn Off Multicast Name Resolution"

Through registry:

• Set HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast to 0

The recommendation from security professionals is unambiguous: disable LLMNR unless you have a specific need for it.¹¹ Most modern networks have reliable DNS. The fallback that LLMNR provides isn't worth the attack surface it creates.

Related Ports

What Flows Through Port 5355

Every LLMNR packet on port 5355 represents a small moment of trust. A computer that couldn't find a name the proper way, asking its neighbors for help. The protocol assumes those neighbors are honest.

In a perfect world, that trust would be warranted. Your laptop would ask "where is the printer?" and the printer would answer. Simple. Elegant. The kind of zero-configuration networking that makes technology feel magical.

In the world we actually live in, that trust is exploited constantly. Port 5355 carries the conversation between a victim and an attacker pretending to be something they're not. The victim's computer sends its authentication credentials because it believes it's talking to a legitimate resource. The attacker captures those credentials and uses them to move deeper into the network.

Microsoft built LLMNR with good intentions. They wanted Windows computers to find each other easily. They shipped it in 2007 and enabled it by default on billions of machines. Fifteen years later, they started backing away from it.

Port 5355 is a reminder that protocols designed for convenience often become vectors for attack. The same openness that makes a protocol easy to use makes it easy to abuse. Every unauthenticated broadcast is an invitation for anyone listening to participate in the conversation.

The port remains open on most Windows machines. The queries keep flowing. Someone is always listening.