Port 138 – NetBIOS Datagram Service

Port 138 is the default UDP port for the NetBIOS Datagram Service (netbios-dgm), the connectionless half of NetBIOS over TCP/IP (NBT) that carries broadcast and mailslot traffic across a local network. Where the name service on 137 resolves names and the session service on 139 carries SMB, port 138 is the channel Windows uses for one-to-many announcements — most visibly the Computer Browser protocol that builds the old “Network Neighborhood” list of machines, domains, and workgroups. Because those datagrams are unauthenticated broadcasts sprayed to the whole subnet, port 138 is primarily an information-disclosure and spoofing surface rather than a remote-code-execution one.

Why It’s Open

NetBIOS over TCP/IP ships enabled on Windows by default, so port 138 comes up alongside 137 and 139 on nearly every Windows host, NAS box, and anything running Samba’s nmbd. The datagram service exists to deliver messages that don’t need a connection: browser-service host and domain announcements, NetLogon and domain-controller location requests, and legacy Messenger/mailslot traffic. On a modern DNS-and-Active-Directory network none of that is required — name resolution and host discovery moved on decades ago — but Microsoft never turned NBT off, so 138 keeps broadcasting. Seeing 138 open is the same legacy fingerprint as SMB on 445: a service that’s answering only because nobody disabled it.

Common Risks

• Broadcast information disclosure. This is the headline for 138. The Computer Browser protocol has every participating host periodically announce itself to the subnet — hostname, role (workstation, server, domain controller, master browser), OS version, and domain or workgroup. An attacker doesn’t have to send a single packet; sitting on the segment and reading the broadcast datagrams maps the entire Windows environment passively.
• NetBIOS name cache poisoning. A spoofed Browse Frame Request sent to UDP 138 can inject or overwrite entries in a target’s dynamic NetBIOS name cache (CVE-2000-1079), redirecting the victim’s later connections to an attacker-controlled IP — a machine-in-the-middle or denial-of-service primitive that needs no authentication.
• Fuel for the NBT poisoning chain. Port 138 is a companion to NBT-NS poisoning on 137: tools like Responder listen on 138 to fingerprint the domain and pick targets before poisoning name queries on 137 and relaying the captured hashes.
• Denial of service. The NetBIOS stack has mishandled malformed packets, allowing an adjacent attacker to make a host unresponsive (CVE-2017-0174).

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Confirm the port is open

nmap -sU -p 138 <target>

UDP scans report open|filtered when there’s no reply, so pair this with a NetBIOS query rather than trusting the state alone.

Sweep a subnet for NetBIOS hosts

nbtscan -r <target>/24

Discover the master browser and its domains

nmap --script broadcast-netbios-master-browser

This queries the local segment for the master browser and lists the servers and domains it tracks — the browser service’s whole view of the network in one command.

Passively map the network from browser datagrams

sudo responder -I eth0 -A

Analyze mode (-A) makes Responder listen on UDP 137/138 without poisoning anything: it logs the BROWSER and NBT-NS traffic and passively enumerates domains, workstations, and servers as they announce themselves.

Read the datagrams directly

sudo tcpdump -i eth0 udp port 138
# or in Wireshark, filter on:  browser || nbdgm

Every hostname, role, and domain name you pull off port 138 is reconnaissance — keep it with the run and drop it into the pentest report as both a finding and a map of the environment rather than losing it in scrollback.

What to Look For

Known CVEs and Exploits

The datagram service carries far fewer dedicated CVEs than 137 or 139 — its real risk is unauthenticated broadcast disclosure and spoofing, not memory-corruption RCE. The protocol-level flaws that do exist reflect that:

• CVE-2000-1079 — Interactions between the CIFS Browser Protocol and NetBIOS in Windows 95/98/NT/2000 let a remote attacker modify dynamic NetBIOS name cache entries with a spoofed Browse Frame Request sent as a unicast or UDP broadcast datagram to port 138. Because the source name and IP are taken from the datagram header without authentication, it enables cache poisoning and connection redirection. CVSS 7.5.
• CVE-2017-0174 — A denial-of-service flaw in the way Windows NetBIOS handles packets. An attacker on the adjacent network can send crafted NetBIOS traffic that makes the target unresponsive. Affects Windows 7 through Server 2016; CVSS 6.5, patched August 2017.

Mitigation

• Disable NetBIOS over TCP/IP. This closes 137, 138, and 139 in one move. Turn it off per-adapter (Advanced TCP/IP Settings → WINS), push it with DHCP option 001 (microsoft-disable-netbios), or set it by GPO. Modern Active Directory doesn’t need NBT, so there’s no reason to leave the datagram broadcasts running.
• Turn off the Computer Browser service. On any host that still needs SMB but not legacy browsing, disabling the Browser service stops the announcement traffic that makes 138 so useful for recon.
• Firewall UDP 137–139 and block broadcast forwarding. The datagram service should never cross a segment boundary or reach the internet; keep broadcast datagrams contained to the VLAN they originate on, or drop them entirely.
• Disable LLMNR and mDNS too. Responder-style tooling watches all the broadcast name protocols, so pair NetBIOS with the “Turn off multicast name resolution” GPO to kill LLMNR (5355) and mDNS (5353).
• Patch legacy NetBT bugs. Apply the MS17-010-era updates that fixed CVE-2017-0174 on anything still in production.

Real-World Example

On an internal engagement, the datagram service is where the quiet reconnaissance happens. Before touching a single host, a tester puts the interface in analyze mode — responder -A or just Wireshark filtered on browser — and waits. Windows machines on the segment broadcast their browser announcements to UDP 138 on a schedule, so within a few minutes the tester has a list of hostnames, which box is the master browser, which are servers, the OS versions, and the domain and workgroup names — the entire environment mapped without sending a packet that could trip an alert. That map then drives the noisy phase: the domain controller and file servers become the targets for NBT-NS poisoning on port 137 and hash relaying. No exploit, no malware — just NetBIOS broadcasting its own network diagram to anyone listening, which is why disabling NBT is on every internal-pentest remediation list.

FAQ

What is port 138 used for?

Port 138 runs the NetBIOS Datagram Service, the connectionless part of NetBIOS over TCP/IP. It carries broadcast and mailslot traffic on a LAN — most notably the Windows Computer Browser protocol that announces hosts, servers, and domains to build the legacy “Network Neighborhood” browse list.

What is the difference between port 137, 138, and 139?

They’re the three services of NetBIOS over TCP/IP. Port 137 (UDP) is the name service that resolves NetBIOS names to IPs. Port 138 (UDP) is the datagram service for connectionless broadcasts like browser announcements. Port 139 (TCP) is the session service that historically carried SMB file sharing before port 445 took over.

Is port 138 dangerous?

On an internal network it’s a reconnaissance risk rather than a direct-compromise one. Its broadcast browser announcements leak hostnames, roles, and domain names to everyone on the subnet, and a spoofed browse frame can poison a host’s NetBIOS name cache. It should never be reachable from the internet, so the exposure is a LAN concern.

Should I block port 138, and how do I close it?

Yes, in almost every modern environment. Disable NetBIOS over TCP/IP on each adapter (Advanced TCP/IP Settings → WINS tab), or push it network-wide with DHCP option 001 or a GPO — that closes 137, 138, and 139 together. Also turn off the Computer Browser service and firewall UDP 137–139. Active Directory doesn’t need NetBIOS, so disabling it is safe for the vast majority of networks.

TL;DR

• Service: NetBIOS Datagram Service (netbios-dgm), the connectionless part of NetBIOS over TCP/IP
• Default port: 138/UDP (with 137 and 139 completing the NetBIOS stack)
• Biggest risk: passive information disclosure from broadcast browser announcements, plus name-cache poisoning via spoofed browse frames
• Mitigation: disable NetBIOS over TCP/IP (and the Computer Browser service), firewall UDP 137–139, and contain broadcast datagrams to the VLAN