Skip to main content
5355

Port 5355LLMNR

TCP/UDP

Port 5355 is the LLMNR (Link-Local Multicast Name Resolution) port used by Windows for local name resolution when DNS fails. LLMNR is a major security vulnerability – Responder and similar tools exploit it to capture NTLMv2 hashes from Windows machines. Disable LLMNR via Group Policy in all production Active Directory environments.

Port Number

5355

Protocol

TCP/UDP

Service

Link-Local Multicast Name Resolution

Range

IANA Registered (1024–49151)

Description

LLMNR on UDP port 5355 is Windows' fallback name resolution protocol when DNS queries fail. A machine multicasts the query to the local network, and any host can respond claiming to be the requested name. This design is inherently insecure – there is no authentication of responses. Attack tools like Responder poison LLMNR queries to redirect traffic through the attacker's machine, capturing NTLMv2 authentication hashes. These hashes can be relayed for immediate access or cracked offline. LLMNR poisoning is one of the most common initial access techniques in Active Directory penetration testing. Disable via: Group Policy > Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution = Enabled.

Security risks

  • 1NTLM hash capture (Responder attack): LLMNR queries are sent to the entire subnet when DNS fails. Tools like Responder answer these queries, tricking the victim into authenticating – capturing NTLMv2 hashes for offline cracking
  • 2Wpad.dat poisoning: when a Windows machine searches for proxy auto-config via LLMNR, Responder claims to be the WPAD server and serves a malicious proxy configuration, intercepting all HTTP traffic
  • 3No authentication: LLMNR responses are accepted without any verification – any host on the subnet can claim any name, redirecting traffic to the attacker (poisoning)
  • 4Relay attacks: captured NTLM authentication (via LLMNR poisoning) can be relayed in real-time to SMB, LDAP, or MSSQL servers using ntlmrelayx, achieving immediate access without cracking the hash
  • 5Enabled by default on all Windows versions: LLMNR is active out-of-the-box on Windows 10/11/Server unless explicitly disabled via Group Policy or registry

Firewall guidance

Disable LLMNR entirely via Group Policy: Computer Configuration → Administrative Templates → Network → DNS Client → Turn off multicast name resolution = Enabled. Also disable NBT-NS (NetBIOS) via network adapter settings. These two changes eliminate the most common internal network attack vector for credential theft. No legitimate modern service requires LLMNR – proper DNS should resolve all names.

Diagnosis commands

Windows: check if LLMNR is disabled (0 = disabled, absent = enabled)

shell
reg query 'HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' /v EnableMulticast

PowerShell: test if LLMNR resolution is active (should fail if disabled)

shell
Resolve-DnsName -Name nonexistent -LlmnrOnly

Linux: capture LLMNR queries on the network (detect Windows machines broadcasting)

shell
tcpdump -i eth0 -n udp port 5355 -c 5

Run Responder in analyze mode to see LLMNR/NBT-NS queries without poisoning (penetration test)

shell
responder -I eth0 --analyze

Usage examples

Port 5355 – LLMNR
shell
responder -I eth0
Get-NetAdapter | Set-DnsClient -EnableMulticast $false
tcpdump -i eth0 udp port 5355

Common services on this port

Windows LLMNR responder (built-in)Responder (attack tool)Inveigh (PowerShell attack tool)

Related ports

History

LLMNR (Link-Local Multicast Name Resolution) was defined in RFC 4795 (2007) by Microsoft as a local name resolution protocol for networks without DNS. Port 5355 (UDP and TCP) with multicast 224.0.0.252. It was designed as a replacement for NetBIOS Name Service (port 137) with IPv6 support. LLMNR became the single most exploited protocol in internal penetration testing – Responder + ntlmrelayx gives domain admin access on most unhardered corporate networks within minutes.

FAQ

Why is LLMNR so dangerous?

Combination of factors: (1) Windows sends LLMNR queries for ANY failed DNS lookup (typos, stale records, disconnected servers), (2) queries go to the entire subnet (multicast), (3) no authentication on responses, (4) Windows automatically sends NTLM credentials to whoever responds. So: user types \\fileserverr (typo) → DNS fails → LLMNR broadcasts 'who is fileserverr?' → attacker responds 'that's me' → Windows sends NTLMv2 hash to attacker → hash cracked or relayed to another server.

How do I detect LLMNR poisoning attacks?

1. Deploy a honeypot: create DNS records for common typos that should never resolve via LLMNR – alert if LLMNR resolves them. 2. Monitor for Responder signatures: IDS rules for LLMNR responses from unexpected IPs. 3. Windows Event Log: Event ID 5765 (LLMNR name resolution). 4. Network monitoring: any unicast LLMNR response (normal is multicast query → unicast response from one host; multiple responses = poisoning). Best fix: disable LLMNR entirely via GPO.

Specification

RFC 4795 – Port 5355 specification →