Port 135: MSRPC — The Map That Became a Weapon

Port 135 is the switchboard operator of Windows networks. When a program on one computer needs to talk to a service on another, it does not know where that service lives. It asks port 135. And port 135 tells it.

This is the RPC Endpoint Mapper. It is the reason Windows computers can coordinate across networks. It is also one of the most attacked ports on the Internet.

What Port 135 Does

Port 135 runs the Microsoft Remote Procedure Call (MSRPC) Endpoint Mapper service.¹ Its job is simple but essential: it maintains a registry of which services are listening on which ports.

Here is the problem RPC solves. When a service starts on a Windows machine, it does not always listen on a fixed port. Many services use dynamic port allocation, grabbing whatever port is available in the ephemeral range (typically 49152-65535). This means a service might be on port 49668 today and port 49721 tomorrow.²

So how does a client find the service? It asks port 135.

The conversation goes like this:

1. Client connects to port 135 on the server
2. Client says: "I need the service with interface UUID X"
3. Port 135 looks up which port that service registered on
4. Port 135 replies: "That service is on port 49668"
5. Client disconnects from 135 and connects to 49668

Port 135 is a directory service for ports. It is metadata about the machine's network configuration, available to anyone who asks.³

The Lineage: From Apollo to Microsoft

The story of port 135 begins not at Microsoft but at a company called Apollo Computer in Chelmsford, Massachusetts.

In 1980, Apollo was building something ambitious: workstations that could share resources across a network as if they were all part of one giant computer.⁴ The founding engineering team, which included Paul Leach, created the Network Computing System (NCS), a framework for remote procedure calls.⁵

The key innovation was the location broker. Previous RPC systems required clients to know exactly where services lived. Apollo's location broker let services register themselves dynamically and let clients discover them on the fly.⁶ Sound familiar? This is exactly what port 135 does today.

In 1988, seven major computer companies, including Apollo, IBM, DEC, and Hewlett-Packard, formed the Open Software Foundation (OSF).⁷ They pooled their technologies. Apollo contributed NCS. The result, released in 1992, was the Distributed Computing Environment (DCE), with DCE/RPC at its core.⁸

Microsoft, building Windows NT in the early 1990s, needed distributed computing capabilities. Rather than invent their own, they licensed DCE 1.1 and built MSRPC on top of it.⁹ They assigned it to port 135.

The port carries the DNA of four decades of distributed systems research. Every time you authenticate to Active Directory, manage a remote server, or access a shared resource on a Windows network, you are using technology that traces back to engineers in Massachusetts trying to make computers cooperate.

How the Endpoint Mapper Works

The RPC Endpoint Mapper maintains a database of registered endpoints. When a service starts, it registers its interface UUID, the protocol it uses, and the endpoint (port or named pipe) where it is listening.¹⁰

The registration includes:

• Interface UUID: A unique identifier for the service type
• Protocol sequence: How to reach it (TCP, UDP, named pipes, HTTP)
• Endpoint: The specific port or pipe name

Clients query this database using the epmapper interface. The query is performed anonymously, even when the eventual RPC call will use authentication.¹¹ This is by design, since you need to find the service before you can authenticate to it.

Common protocol sequences include:

• ncacn_ip_tcp: RPC over TCP/IP (dynamic ports)
• ncacn_np: RPC over SMB named pipes (port 445)
• ncacn_http: RPC over HTTP (port 593 or 80/443)
• ncadg_ip_udp: RPC over UDP

The endpoint mapper itself listens on TCP 135, UDP 135, and through SMB on ports 139 and 445.¹²

What Runs Over Port 135

Nearly every critical Windows service that communicates across a network uses MSRPC and, by extension, port 135:

Active Directory: Domain controllers use RPC for replication, authentication, and policy distribution. Port 135 is essential for domain-joined machines to function.¹³

Windows Management Instrumentation (WMI): Remote system management queries start with a trip to port 135 to find the WMI provider.¹⁴

Distributed Component Object Model (DCOM): Microsoft's technology for network-transparent object communication. DCOM is built on top of MSRPC.¹⁵

Task Scheduler: Remote task scheduling uses the \pipe\atsvc interface.

Service Control Manager: Remotely starting, stopping, and configuring services uses \pipe\svcctl.

Remote Registry: Accessing the registry of a remote machine uses \pipe\winreg.

Security Account Manager (SAM): Enumerating users and groups uses \pipe\samr.

In a Windows enterprise environment, port 135 is not optional. It is load-bearing infrastructure.

August 2003: The Blaster Worm

On July 16, 2003, Microsoft released security bulletin MS03-026.¹⁶ A Polish security research group called Last Stage of Delirium had found a buffer overflow in the DCOM RPC interface. The vulnerability allowed an attacker to send a specially crafted packet to port 135 and execute arbitrary code with SYSTEM privileges.¹⁷

The patch was available. The window was open.

On July 25, a working exploit appeared. On August 11, the Blaster worm arrived.¹⁸

Blaster was different from previous worms. It did not require email attachments or user interaction. It simply scanned for machines with port 135 open, sent the exploit, and gained control. Then it downloaded its payload and started scanning for more victims.¹⁹

The infection numbers tell the story:

• August 12: 30,000 infected systems
• August 15: 423,000 infected systems
• Total: Over 1.4 million computers worldwide²⁰

Blaster contained a message in its code: "billy gates why do you make this possible? Stop making money and fix your software!!" It also carried a time bomb, programmed to launch a distributed denial-of-service attack against windowsupdate.com on August 16.²¹

The DDoS largely failed because Microsoft had already redirected the domain. But the damage was done. The worm disrupted CSX Transportation's railway systems. It interfered with Seattle's emergency dispatch system. Government experts later revealed that Blaster may have contributed to the cascading effects of the August 14 blackout, degrading communications between utility companies managing the power grid.²²

Mi2g estimated $32.8 billion in economic damages from malware in August 2003, the largest amount in Internet history at that time.²³

An 18-year-old from Minnesota named Jeffrey Lee Parson created a variant of the worm. He was sentenced to 18 months in prison.²⁴ The original author was never caught.

Security Reality

Port 135 should never be exposed to the Internet. Full stop.

The Endpoint Mapper provides attackers with a detailed map of what services are running on a system. Even without exploits, this information disclosure is valuable for reconnaissance. With exploits, it becomes catastrophic.²⁵

Every security guide says the same thing: block ports 135, 137, 138, 139, 445, and 593 at your perimeter firewall.²⁶ These are Windows networking ports. They were designed for trusted networks. The Internet is not a trusted network.

Within a corporate network, the calculation changes. You cannot simply disable port 135 if you run Active Directory. The domain would stop functioning. The challenge becomes segmentation: ensuring that port 135 is only accessible between machines that legitimately need to communicate via RPC.²⁷

Modern Windows versions have hardened MSRPC significantly since 2003. Authentication requirements are stricter. Interface restrictions limit which RPC services can be called remotely. But the fundamental architecture remains: a port that tells you where everything else is.

Related Ports