Port 139: NetBIOS Session Service — The Door That Trusted Everyone

Port 139 is the NetBIOS Session Service port. When you map a network drive, when you access a shared folder, when you print to a network printer on older Windows systems, that traffic flows through port 139. It is the session layer of a protocol designed in 1983 for offices with a dozen computers, still running on networks with millions.

What Port 139 Does

Port 139 carries NetBIOS session traffic over TCP/IP. NetBIOS (Network Basic Input/Output System) provides three services, each with its own port¹:

• Port 137 (UDP): Name Service, how computers find each other by name
• Port 138 (UDP): Datagram Service, for connectionless messaging
• Port 139 (TCP): Session Service, for reliable, connection-oriented communication

The Session Service is where the real work happens. When two computers need to have a conversation, not just shout announcements, they establish a session on port 139. This enables file sharing, printer sharing, and the collaborative infrastructure that made Windows networking possible.

A session on port 139 works like this: the client opens a TCP connection to port 139 on the server, sends a Session Request packet containing the NetBIOS names of both parties, and waits. The server responds with either a Positive Session Response (session established) or a Negative Session Response (access denied). Once established, the session provides full-duplex, sequenced, reliable message exchange with messages up to 131,071 bytes².

The History

In 1983, Sytek Inc. created NetBIOS for IBM's PC Network, the company's first local area network product³. This was before Ethernet dominated, before TCP/IP was ubiquitous, before most people had ever heard the word "network." IBM needed a way for their personal computers to share resources, and NetBIOS was the answer.

The original NetBIOS was not a protocol. It was an API, a set of programming interfaces that applications could use to access network services. The actual wire protocol was proprietary Sytek technology. But the API became so popular that it needed to be freed from its hardware prison.

In 1987, the Internet Activities Board published RFC 1001 and RFC 1002, defining how to run NetBIOS services over TCP/IP². The working group, which included contributors from Sytek, Excelan, Ungermann-Bass, and other networking pioneers, recognized that "the NetBIOS service has become the dominant mechanism for personal computer networking" and needed a path to the broader Internet.

The RFCs established a clear purpose: "allow an implementation to be built on virtually any type of system where the TCP/IP protocol suite is available" and "allow NetBIOS interoperation in the Internet."¹

This was the moment NetBIOS stopped being a local curiosity and became a global protocol. Port 139 was assigned for session services, and the pattern that would define Windows networking for the next two decades was set.

How NetBIOS Sessions Work

The key insight of NetBIOS sessions is establishing named connections between applications, not just IP addresses². When you connect to a file share, you are connecting to a NetBIOS name like \\FILESERVER\Documents, not to 192.168.1.50. The Name Service on port 137 resolves that name, and then the Session Service on port 139 establishes the connection.

The Session Service provides six primitives²:

1. Call: Initiate a session with a listening process
2. Listen: Accept incoming session requests
3. Hang Up: Gracefully terminate a session
4. Send: Transmit data to the session partner
5. Receive: Accept data from the session partner
6. Session Status: Query information about active sessions

Multiple sessions can exist between any pair of computers, and the service guarantees sequenced, reliable delivery. If a packet is lost, the session handles retransmission. If a message is too large, the session handles fragmentation. The application just sends and receives data.

On top of this session layer runs SMB (Server Message Block), the actual file-sharing protocol created by Barry Feigenbaum at IBM⁴. SMB handles the semantics of opening files, reading data, and writing changes. NetBIOS sessions handle the reliable delivery underneath.

The Security Nightmare

Port 139 was designed for trust. Small offices. Colleagues who knew each other. Networks where every device was physically inside the building. This trust, encoded into the protocol, became catastrophic when networks connected to the Internet.

The problems started almost immediately. In 1999, the WinNuke attack emerged, sending out-of-band (OOB) data to port 139 that Windows did not know how to handle⁵. The exploit was trivial: send malformed urgent data, watch the target crash. Documented as CVE-1999-0153, it became one of the first widely-used denial-of-service attacks against Windows systems.

That same year, the Red Button exploit (CVE-1999-0471) demonstrated how attackers could use ports 137, 138, and 139 together to log onto target computers without authorization⁵. The NetBIOS Name Server Protocol Spoofing vulnerability (CVE-2000-0673) showed that the lack of authentication in the name service allowed attackers to poison NetBIOS caches, redirecting traffic to malicious hosts⁵.

In 2002, Microsoft published security bulletin MS02-045 addressing vulnerabilities exploited by tools like SMBdie and smbnuke⁵. These were not theoretical risks. They were active weapons being used against real networks.

But nothing prepared the world for 2017.

WannaCry: When Port 139 Walked Into Hospitals

On May 12, 2017, the WannaCry ransomware worm spread to more than 200,000 computers in over 150 countries in a single day⁶. It was the largest ransomware attack in history, and it spread through ports 139 and 445.

WannaCry exploited EternalBlue, a vulnerability in SMBv1 developed by the NSA and stolen by the Shadow Brokers hacking group⁷. Once a single machine on a network was infected, the worm scanned for other machines with open SMB ports and spread automatically. No user interaction required. No phishing emails. Just an open port and an unpatched system.

The UK's National Health Service was devastated. At least 80 of 236 hospital trusts were affected, along with 603 primary care organizations and 595 GP practices⁸. Up to 70,000 devices went down, including computers, MRI scanners, blood-storage refrigerators, and operating theater equipment⁶.

Hospitals had to turn away non-critical emergencies. Ambulances were diverted. 13,500 outpatient appointments were cancelled, including 139 for patients with suspected cancer⁸. Staff could not access patient records. Telephone systems failed. Surgeries were cancelled by the thousands.

The NHS paid nothing to the attackers. But the cost was estimated at £92 million: £19 million in lost activity from cancelled operations and appointments, plus £73 million in IT recovery costs⁸.

Why was the NHS so vulnerable? Over half of NHS trusts were still running Windows XP, an operating system Microsoft had stopped supporting three years earlier⁸. The WannaCry patch had been available since March 2017, two months before the attack. But patch management in healthcare is hard, and legacy systems are everywhere.

Port 139 did not cause WannaCry. But port 139, open and trusting, was the door through which it walked.

Port 445: The Modern Alternative

Starting with Windows 2000, Microsoft introduced "Direct-hosted SMB," which runs SMB directly over TCP port 445 without the NetBIOS layer⁹. This simplified configuration, improved performance, and reduced the attack surface.

Modern Windows systems try both ports simultaneously. If port 445 responds, Windows sends a TCP reset to port 139 and continues only on 445⁹. If 445 is unavailable, Windows falls back to 139 for backward compatibility.

The recommendation today is clear: disable NetBIOS and use only port 445 with SMBv2 or SMBv3, which include encryption and modern security features¹⁰. Port 139 should be blocked at the firewall unless legacy systems absolutely require it.

But "should" and "is" are different things. Port 139 remains open on countless networks, supporting ancient applications, forgotten file shares, and the inertia of "it still works, so don't touch it."

Related Ports

Port 139 exists within a family of NetBIOS and SMB ports:

Ports 137-139 work together to provide the complete NetBIOS over TCP/IP stack. Port 445 is the modern replacement that eliminates the NetBIOS dependency.

Current Relevance

Port 139 is a legacy protocol that refuses to die. Every modern security recommendation says to disable it. Every penetration testing checklist includes checking for open 139. Every ransomware propagation tutorial mentions it as a target.

And yet it persists. Mixed Windows environments with legacy systems. Industrial control networks with devices that cannot be updated. Networks where "backward compatibility" is a religious requirement.

If you have port 139 open to the Internet, you are running a protocol designed for twelve computers in a trusted office, exposed to billions of untrusted hosts. The math does not favor you.

Summary

Port 139 is the NetBIOS Session Service, the reliable connection layer that made Windows file sharing possible. Created in 1983 for small offices, standardized in 1987 for the Internet, and exploited continuously ever since. It taught personal computers how to be a network, then became the door through which ransomware walked into hospitals.

The protocol's design reflected a world that no longer exists: small, trusted, local. When that design met the Internet, the trust became vulnerability. WannaCry was not the first attack on port 139, and it will not be the last.

Modern systems should use port 445 with SMBv3. Legacy systems should be isolated. Port 139 should be firewalled from anything that is not absolutely required to reach it.

The door that trusted everyone learned, eventually, that not everyone should be trusted.