Port 137 – NetBIOS Name Service (NBNS)

Port 137 is the default UDP port for the NetBIOS Name Service (NBNS), the legacy Windows mechanism for mapping NetBIOS computer names to IP addresses on a local network — effectively NetBIOS’s answer to DNS. A host broadcasts a name query to UDP 137 (“who is FILESERVER01?”) and whichever machine owns that name replies with its address. It’s one third of NetBIOS over TCP/IP (NBT), sitting alongside the datagram service on 138 and the session service on 139. Decades after DNS took over, Windows still ships NBT enabled by default — which is exactly why port 137 remains one of the most productive targets on an internal network.

Why It’s Open

NetBIOS predates DNS-only networking, but Microsoft never turned it off. Every Windows workstation and server, plus most NAS boxes, network printers, and anything running Samba’s nmbd, still answers on 137 out of the box. The catch is the fallback behavior: when a normal DNS lookup fails — a typo, a decommissioned host, a \\share that no longer resolves — Windows quietly broadcasts the name over NBT-NS (and LLMNR) and trusts whoever answers. That unauthenticated, trust-the-first-reply broadcast is the whole problem, and it’s why 137 shows up next to SMB on 445 on nearly every Windows host you’ll scan.

Common Risks

• NBT-NS poisoning. This is the headline attack. When a host broadcasts a name query to 137 and nothing legitimate answers, an attacker on the segment (running Responder) replies “that’s me.” The victim connects and hands over its NTLMv2 hash, which the attacker cracks offline or relays straight to another host for lateral movement. It’s the opening move of most internal pentests.
• Information disclosure. A single nbtstat or nmblookup query against 137 returns the NetBIOS name table: the hostname, the domain or workgroup, the logged-in user, whether the box is a file server or domain controller, and its MAC address — a complete fingerprint, no credentials needed.
• Name-service spoofing and DoS. NBNS has no authentication, so a spoofed Name Release or Name Conflict datagram can knock a host off the network or hijack its name (CVE-2000-0673 / MS00-047).
• Legacy code execution. The NetBT stack itself has carried remote code execution bugs (CVE-2017-0161), so an unpatched, exposed NetBIOS service is more than just an information leak.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Query the NetBIOS name table

nmap -sU -sV -p 137 --script nbstat.nse <target>

Sweep a subnet for NetBIOS hosts

nbtscan <target>/24

Read the name table with the native tools

nmblookup -A <target>      # Samba
nbtstat -A <target>        # Windows

Poison NBT-NS to capture hashes

responder -I eth0

Every name table you pull — usernames, roles, domain membership — feeds the next step, so keep it with the run rather than in scrollback; it belongs in the pentest report as both a finding and a map of the domain.

What to Look For

Known CVEs and Exploits

• CVE-2017-0161 — A remote code execution flaw in the Windows NetBT (NetBIOS over TCP/IP) Session Services component. A race condition in sequence handling lets a remote, unauthenticated attacker run code. CVSS 8.1, patched across Windows 7 through Server 2016.
• CVE-2000-0673 — “NetBIOS Name Server Protocol Spoofing” (MS00-047). Because NBNS performs no authentication, a spoofed Name Conflict or Name Release datagram to port 137 causes a denial of service — or lets an attacker steal a name. The protocol-level flaw that Responder-style poisoning still abuses.
• CVE-1999-0519 — The canonical null-session finding: a NetBIOS/SMB share with a default, null, or missing password. Paired with a name-table dump from 137, it turns anonymous NetBIOS access into real reconnaissance and often file access.

Mitigation

• Disable NetBIOS over TCP/IP. This is the real fix. Turn it off per-adapter (Advanced TCP/IP Settings → WINS), push it network-wide with DHCP option 001 (microsoft-disable-netbios), or set it by GPO. If nothing on the network depends on NetBIOS name resolution — and modern AD doesn’t — there’s no reason to leave 137 answering.
• Turn off LLMNR and mDNS too. Responder poisons all three broadcast name protocols, so disabling only NetBIOS leaves the door open. Use the “Turn off multicast name resolution” GPO to kill LLMNR (5355) and mDNS (5353) as well.
• Firewall UDP 137–139. Block the whole NetBIOS range at the perimeter and between segments; it should never be reachable from the internet.
• Enforce SMB signing and LDAP channel binding / EPA. A captured hash is only dangerous if it can be relayed — signing and channel binding blunt that path.
• Watch for the poisoning signature. A host answering large numbers of NBT-NS queries it shouldn’t own is the classic Responder tell.

Real-World Example

On a typical internal engagement, the first thing a tester does is start Responder and wait. It doesn’t take long: a Windows machine tries to reach a share that no longer resolves in DNS — a decommissioned server, a fat-fingered \\fileserver01 — and falls back to broadcasting the name over NBT-NS on port 137. Responder answers, the workstation “finds” the server and authenticates to it, and the tester walks away with a domain user’s NTLMv2 hash. If it cracks, that’s a valid credential; if a nearby server has SMB signing turned off, the hash gets relayed there directly for a foothold with no cracking at all. No exploit, no malware — just NetBIOS trusting the first machine to answer, which is why disabling NBT-NS is on every internal-pentest remediation list.

FAQ

What is port 137 used for?

It runs the NetBIOS Name Service (NBNS), which resolves NetBIOS computer names to IP addresses on a LAN — the legacy Windows equivalent of DNS. Hosts broadcast name queries to UDP 137 and register their own names there so others can find them.

Is port 137 dangerous?

On an internal network, yes. NBNS has no authentication, so an attacker can poison name responses to capture password hashes (via Responder), and a simple query leaks the hostname, domain, and logged-in user. It’s rarely an internet-facing risk because 137 should be firewalled, but on a LAN it’s a reliable attacker foothold.

How do I disable NetBIOS or close port 137?

Disable NetBIOS over TCP/IP on each network adapter (Advanced TCP/IP Settings → WINS tab), or push it everywhere with DHCP option 001 or a GPO. Also disable LLMNR and mDNS so name-resolution poisoning has no fallback, and firewall UDP 137–139. Modern Active Directory doesn’t need NetBIOS, so turning it off is safe in most environments.

Do I still need ports 137, 138, and 139 open?

Almost never on a current network. They’re the legacy NetBIOS over TCP/IP stack — name service (137), datagrams (138), and sessions (139). File sharing moved to SMB on 445 years ago, so unless you’re supporting genuinely old systems, all three can be disabled.

TL;DR

• Service: NetBIOS Name Service (NBNS / NBT-NS), part of NetBIOS over TCP/IP
• Default port: 137/UDP (with 138 and 139 completing the NetBIOS stack)
• Biggest risk: NBT-NS poisoning for NTLM hash capture and relay, plus name-table information disclosure
• Mitigation: disable NetBIOS over TCP/IP (and LLMNR/mDNS), firewall 137–139, and enforce SMB signing