Port 5355 – LLMNR (Link-Local Multicast Name Resolution)

Port 5355 is the default port for LLMNR (Link-Local Multicast Name Resolution), a Windows fallback name-resolution protocol that kicks in when normal DNS can’t answer. When a host fails to resolve a name — a typo, a decommissioned server, a \\share that no longer exists — Windows multicasts the query to 224.0.0.252 (IPv4) or ff02::1:3 (IPv6) on UDP 5355 and trusts whichever machine on the segment answers first. Queries usually ride UDP, with a TCP 5355 fallback for large responses. That unauthenticated, trust-the-first-reply design makes port 5355 one of the most productive footholds on an internal network, and it puts LLMNR in the same name-resolution-poisoning family as NetBIOS-NS on port 137 and mDNS on port 5353.

Why It’s Open

LLMNR ships enabled by default on Windows and was designed for convenience in small, unmanaged networks where there’s no DNS server to rely on. The problem is the fallback behavior: whenever a lookup fails in DNS (port 53), the client quietly broadcasts the name over LLMNR (and NBT-NS) and accepts the first answer with no authentication at all. In a managed Active Directory environment LLMNR is almost never needed — internal DNS already resolves everything legitimate — so an LLMNR responder on the wire is usually pure liability. Where 5355 is answering, its poisoning cousins NBT-NS (137) and mDNS (5353) are typically answering on the same host, which is why Responder captures hashes on nearly every internal assessment.

Common Risks

• LLMNR poisoning → NTLMv2 hash capture — the headline attack. When a Windows host mistypes a name or DNS fails, it multicasts an LLMNR query to 5355. An attacker on the segment running Responder (or Inveigh) answers “that’s me,” the victim connects and tries to authenticate, and the attacker captures the NTLMv2 challenge/response — crackable offline with hashcat. It’s a top finding on almost every internal pentest, and it needs no exploit and no malware.
• NTLM relay to lateral movement. Instead of cracking the captured hash, the attacker relays it live with ntlmrelayx to SMB (445) or LDAP on another host. If SMB signing isn’t enforced, that turns a single poisoned lookup into a foothold — command execution or a domain compromise — with nothing to crack.
• Internal reconnaissance / information disclosure. LLMNR broadcasts leak hostnames a passive listener can map, fingerprinting the subnet without sending an active scan.
• Protocol design weakness, not a patchable bug. LLMNR poisoning isn’t a CVE — it’s the intended behavior of an unauthenticated multicast name-resolution protocol. No patch fixes it; the fix is turning LLMNR off.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Check if it’s open

nmap -sU -sV -p 5355 <target>

Sniff LLMNR queries on the segment

sudo tcpdump -i eth0 -n port 5355

Resolve a name over LLMNR with the nmap NSE script

nmap --script llmnr-resolve --script-args 'llmnr-resolve.hostname=<hostname>' -e eth0

Poison LLMNR to capture NTLMv2 hashes (authorized engagements only)

sudo responder -I eth0

Relay a captured authentication instead of cracking it

impacket-ntlmrelayx -t smb://<target> -smb2support

Spoof LLMNR from a Windows host with Inveigh

Import-Module .\Inveigh.ps1
Invoke-Inveigh -LLMNR Y -NBNS Y -mDNS Y -ConsoleOutput Y

Every hostname you pull and every hash Responder captures is both a finding and a map of the domain, so keep it in the pentest report rather than terminal scrollback you’ll lose.

What to Look For

Known CVEs and Exploits

LLMNR poisoning itself is not a CVE — it’s a protocol design weakness. LLMNR is an unauthenticated multicast protocol that trusts the first answer, so responding to a victim’s query with your own address is the protocol working as designed. No patch closes it; the remediation is disabling LLMNR. That said, the LLMNR implementations have carried real bugs:

• CVE-2011-0657 — A remote code execution flaw in DNSAPI.dll, the Windows DNS client, addressed by MS11-030. The client mishandles DNS query processing, and a crafted LLMNR broadcast query can trigger code execution. It affected Windows XP through Windows 7 and Server 2008 R2. CVSS v2 7.5; the modern re-scored CVSS v3.1 rating is 9.8 (Critical) — a genuine LLMNR-triggered RCE, distinct from the poisoning design flaw.
• CVE-2025-5688 — An out-of-bounds write in FreeRTOS-Plus-TCP (2.3.4 through 4.3.1) when processing LLMNR or mDNS queries with very long DNS names, on systems using Buffer Allocation Scheme 1 with LLMNR/mDNS enabled. CVSS 4.0 7.5 (High), CWE-787; fixed in 4.3.2. Proof the LLMNR parser in embedded stacks is still an active attack surface.
• Responder — the standard tool for LLMNR, NBT-NS, and mDNS poisoning; answers name queries and harvests NTLMv2 hashes.
• Inveigh — a PowerShell/C# LLMNR/NBNS/mDNS spoofer for running the same attack from a Windows foothold.
• Impacket’s ntlmrelayx — relays the captured authentication to SMB (445) or LDAP for lateral movement, no cracking required.

Mitigation

• Disable LLMNR via Group Policy — the standard fix. Enable Computer Configuration → Administrative Templates → Network → DNS Client → “Turn off multicast name resolution.” This is the single most effective control and closes the LLMNR side of the Responder poisoning surface network-wide. Modern Active Directory doesn’t need LLMNR, so it’s safe in almost every environment.
• Disable NBT-NS and mDNS too. Responder poisons all three broadcast name protocols, so turning off only LLMNR leaves the door open. Disable NetBIOS over TCP/IP (137) per-adapter or via DHCP option 001, and mDNS (5353) where possible, so name-resolution poisoning has no fallback.
• Enforce SMB signing and LDAP signing / channel binding. A captured hash is only dangerous if it can be relayed — signing and channel binding blunt the SMB (445) and LDAP relay paths that turn a poisoned lookup into a foothold.
• Segment workstations from servers. Limit how far a poisoned response and a relayed session can reach across the network.
• Monitor for LLMNR spoofing. A host answering LLMNR queries for names it doesn’t own is the classic rogue-responder signature — alert on it in network/endpoint monitoring.
• Require MFA on privileged accounts. So a cracked or relayed credential alone isn’t enough to move laterally.

Real-World Example

The reliable internal-pentest opener is to start Responder and wait. A Windows host tries to reach a name DNS can’t resolve — a mistyped \\fileserver01, a decommissioned server — and falls back to multicasting the query over LLMNR (and NBT-NS) on the local segment. Responder answers “that’s me,” the workstation connects and authenticates to the attacker, and the tester walks off with a domain user’s NTLMv2 hash. If it cracks in hashcat, that’s a valid credential; if a nearby server has SMB signing turned off, ntlmrelayx forwards the authentication straight to SMB (445) for a foothold with no cracking at all. No exploit, no malware — just LLMNR trusting the first machine to answer, exactly like NBT-NS (137) and mDNS (5353), which is why “disable LLMNR by GPO” is on every internal-pentest remediation list.

FAQ

What is port 5355 used for?

Port 5355/UDP carries LLMNR (Link-Local Multicast Name Resolution), a Windows fallback name-resolution protocol. When a host can’t resolve a name through DNS (53), it multicasts the query to 224.0.0.252 (or ff02::1:3 on IPv6) on port 5355 and trusts whichever machine answers. It’s meant for small networks with no DNS server; a TCP 5355 fallback handles large responses.

Is port 5355 dangerous?

On an internal network, yes. Because LLMNR is unauthenticated and accepts the first answer, an attacker on the segment can poison name lookups with Responder to capture NTLMv2 hashes, then crack them offline or relay them to another host for lateral movement. It’s not usually an internet-facing risk — 5355 should never leave the LAN — but on a corporate subnet it’s one of the most dependable attacker footholds.

What is LLMNR poisoning?

It’s the attack where an attacker answers a victim’s LLMNR broadcast query with their own address. The victim, trusting the first reply, tries to authenticate to the attacker and hands over its NTLMv2 challenge/response. That hash is cracked offline or relayed live (via ntlmrelayx) to SMB (445) or LDAP. It’s a design flaw in LLMNR, not a software bug, so the only real fix is disabling the protocol.

What’s the difference between LLMNR, mDNS, and NetBIOS-NS?

All three are broadcast/multicast name-resolution protocols that kick in when DNS (53) doesn’t answer. LLMNR (5355) is Microsoft’s link-local resolver; mDNS (5353) is the cross-platform Zeroconf/Bonjour resolver for .local names; and NetBIOS-NS (137) is the legacy Windows name service. All three are unauthenticated, all three are poisoned by Responder, and all three should be disabled together.

How do I disable LLMNR or close port 5355?

Enable the “Turn off multicast name resolution” Group Policy (Computer Configuration → Administrative Templates → Network → DNS Client). Disable NetBIOS over TCP/IP and mDNS at the same time so poisoning has no fallback, enforce SMB signing to blunt relay, and rely on properly maintained internal DNS. Rescan with nmap -sU -p 5355 <target> to confirm it no longer answers.

TL;DR

• Service: LLMNR (Link-Local Multicast Name Resolution) — Windows fallback name resolution
• Default port: 5355/UDP (TCP fallback; multicast 224.0.0.252 / ff02::1:3)
• Biggest risk: LLMNR poisoning → NTLMv2 hash capture (Responder), then offline cracking or relay (ntlmrelayx) to SMB/LDAP for lateral movement
• Mitigation: disable LLMNR via the “Turn off multicast name resolution” GPO, disable NBT-NS and mDNS too, enforce SMB/LDAP signing, and segment