TCP port 135 is a critical network port primarily used by the Microsoft Remote Procedure Call (MSRPC) Endpoint Mapper service. In the ecosystem of Windows networking, this port serves as a central directory or "switchboard operator." Its fundamental purpose is to help client machines locate the specific dynamic ports assigned to various RPC-based services running on a server. Because many Windows services do not utilize a static port, port 135 provides the essential mechanism for service discovery and connection establishment.

While port 135 is indispensable for the seamless operation of Active Directory, Windows Management Instrumentation (WMI), and Distributed Component Object Model (DCOM), its role as a service directory also makes it a high-value target for attackers. An exposed port 135 can reveal a wealth of information about a system's configuration and provide a gateway for lateral movement within a network.

The Technical Mechanism of the MSRPC Endpoint Mapper

To comprehend why port 135 is so pervasive, it is necessary to understand the architecture of Microsoft's implementation of the Distributed Computing Environment / Remote Procedure Call (DCE/RPC) protocol.

The Concept of Service Discovery

In a traditional client-server model, a service might listen on a well-known port (e.g., HTTP on port 80). However, Windows hosts hundreds of distinct RPC services. If every service occupied a static port, the management of these ports would become a logistical nightmare, and the limited range of available ports would quickly be exhausted. Instead, Microsoft uses a dynamic allocation system. When an RPC service starts, it requests a random port from the ephemeral port range—typically 49152 to 65535 on modern Windows versions.

This is where the Endpoint Mapper (epmapper) comes into play. Port 135 acts as the permanent, static anchor. When a service registers itself, it tells the Endpoint Mapper its Universally Unique Identifier (UUID) and the dynamic port it has claimed.

The Four-Step Connection Process

  1. Initiation: A client machine needs to access a specific service on a remote server, such as a remote registry or a management task. The client knows the UUID of the service but does not know which port it is currently using.
  2. The Endpoint Lookup: The client establishes a connection to the server on TCP port 135. It sends a request to the Endpoint Mapper service, asking: "I am looking for the service with this specific UUID. Where is it?"
  3. The Resolution: The Endpoint Mapper queries its internal database (the endpoint map). If it finds a match, it returns the dynamic port number (e.g., TCP 50432) to the client.
  4. Direct Communication: The client terminates the connection to port 135 and opens a new connection directly to the dynamic port provided by the server. From this point forward, the actual data transfer and procedure calls occur on the dynamic port, not on port 135.

Core Windows Services Dependent on Port 135

The operational integrity of a Windows domain environment relies heavily on the Endpoint Mapper. Several foundational technologies cannot function without the ability to query port 135 for service locations.

Active Directory and Domain Controller Communication

Active Directory (AD) uses RPC for replication between domain controllers and for client authentication. While some AD services have specific ports, the initial negotiation often involves port 135. If this port is blocked internally between domain controllers, replication will fail, leading to inconsistent global catalogs and authentication errors for users across the organization.

Distributed Component Object Model (DCOM)

DCOM is a proprietary Microsoft technology for communication among software components on different networked computers. It extends the Component Object Model (COM) and provides the substrate for many legacy and modern enterprise applications. DCOM is notorious for its complex port requirements, as it initiates connections via port 135 before shifting to a wide range of dynamic ports. This behavior often requires network administrators to implement "RPC-aware" firewalls or open large port ranges, which introduces significant security challenges.

Windows Management Instrumentation (WMI)

WMI is the primary framework for management data and operations on Windows-based operating systems. It allows administrators to query system information, manage processes, and execute scripts remotely. Because WMI is built on top of DCOM, it is entirely dependent on port 135 for the initial handshake. In modern DevOps and system administration, WMI is frequently used for monitoring and configuration management, making the availability of port 135 a prerequisite for infrastructure visibility.

Microsoft Exchange Server

In enterprise mail environments, Microsoft Exchange uses RPC (often encapsulated in HTTPS in newer versions) for communication between Outlook clients and the server, as well as for inter-server communication. Even when RPC-over-HTTP is used, internal backend services often still rely on the standard MSRPC Endpoint Mapper on port 135 to coordinate various sub-services like the Information Store or the Directory Service.

Security Risks and Vulnerabilities Associated with Port 135

From a security perspective, port 135 is often classified as a "noisy" and "leaky" port. Its design, which favors discovery and ease of connection, inherently conflicts with the principles of minimal exposure and zero-trust security.

System Reconnaissance and Enumeration

The most immediate risk of an open port 135 is reconnaissance. Because the Endpoint Mapper is designed to tell clients what is running on a system, it will do the same for an attacker. Tools like rpcdump or Nmap scripts can query port 135 to retrieve a complete list of RPC endpoints. This list includes the UUIDs, service names, and port numbers of every RPC-based application on the host. For an attacker, this is a roadmap that identifies the software versions, installed services, and potential entry points without ever having to brute-force or scan the entire port range.

Lateral Movement and Remote Execution

Historically, port 135 has been the primary vector for some of the most damaging malware in Windows history. The Blaster Worm (MS03-039) famously exploited a buffer overflow in the RPCSS service (which listens on port 135) to achieve remote code execution with SYSTEM privileges. Once a single machine was infected, the worm scanned port 135 on other machines to propagate automatically through the network.

While Microsoft has significantly hardened the RPC stack since the early 2000s, vulnerabilities still emerge. For instance, CVE-2022-26809 identified a critical vulnerability in the MSRPC implementation that could allow a remote unauthenticated attacker to execute code with high privileges. These types of vulnerabilities are particularly dangerous because port 135 is often open by default on internal networks, allowing an attacker who has gained a foothold on a low-security workstation to move laterally to high-value servers.

The Complexity of Firewalling

One of the greatest security challenges posed by port 135 is that blocking it is often not enough to secure the RPC ecosystem, yet opening it necessitates opening thousands of other ports. Since port 135 only handles the "directory lookup," a firewall that permits port 135 but blocks the dynamic port range (49152-65535) will break the application. Conversely, opening the entire dynamic range significantly increases the attack surface. This "all or nothing" dilemma is a frequent point of failure in network security configurations.

How to Detect and Audit Port 135 Exposure

Effective management of port 135 begins with visibility. Administrators must know which systems are exposing this port and to which networks.

Using Nmap for Network Auditing

Nmap (Network Mapper) is the industry standard for identifying open ports and the services behind them. To check if a specific host has port 135 open, a simple scan can be performed:

nmap -p 135 <target-ip>

However, to gain deeper insight into the RPC services registered with the Endpoint Mapper, the msrpc-enum script is invaluable:

nmap -p 135 --script msrpc-enum <target-ip>

This command will not only confirm if the port is open but will also attempt to list the RPC interfaces, giving the auditor a clear picture of what an attacker would see during the reconnaissance phase.

Checking Local Listeners with PowerShell

On a local Windows machine, you can verify the status of the RPC Endpoint Mapper using the Get-NetTCPConnection cmdlet. This is useful for troubleshooting why a local service might not be reachable from the network:

Get-NetTCPConnection -LocalPort 135

If the state is "Listen," the service is active. To identify the specific process associated with the port, you can cross-reference the OwningProcess ID with the Task Manager or the Get-Process cmdlet. Typically, this will be svchost.exe running the RpcSs service.

Testing Remote Connectivity

For troubleshooting connectivity issues through firewalls, the Test-NetConnection cmdlet is a powerful tool. It allows you to simulate a TCP handshake without needing specialized scanning tools:

Test-NetConnection -ComputerName <ServerName> -Port 135

If TcpTestSucceeded returns False, it indicates that a network firewall, host-based firewall (like Windows Defender Firewall), or a network routing issue is preventing the initial RPC handshake.

Best Practices for Securing and Hardening Port 135

Given the critical nature of port 135 and its inherent risks, a multi-layered defense strategy is required. The goal is to allow legitimate administrative traffic while completely isolating the port from untrusted zones.

1. Perimeter Isolation

The absolute first rule of Windows security is: Never expose port 135 to the public internet. There is virtually no legitimate reason for the MSRPC Endpoint Mapper to be reachable from outside a secured corporate network or a VPN tunnel. Most modern ISP routers and corporate firewalls block this port by default, but misconfigurations during cloud migrations or manual port forwarding can lead to disastrous exposure.

2. Internal Network Segmentation

Within the internal network, not every machine needs to talk to every other machine on port 135. You should implement network segmentation (VLANs) to separate user workstations from sensitive servers. Use Access Control Lists (ACLs) to ensure that only designated management workstations or monitoring servers can initiate RPC calls to your database or application servers.

3. Restricting RPC Dynamic Port Ranges

To make firewalling more manageable, you can configure Windows to use a specific, narrowed range of ports for RPC dynamic allocation instead of the default 16,000+ ports. This is done via the registry:

  • Navigate to: HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet
  • Define a specific range (e.g., 5000-5100).

By narrowing the range, you can create much tighter firewall rules, reducing the overall attack surface while still allowing RPC-based services to function.

4. Implementing IPsec Policy

For high-security environments, using IPsec (Internet Protocol Security) to encrypt and authenticate all traffic between servers is a highly effective strategy. By requiring IPsec for all connections to port 135, you ensure that only domain-joined, authorized computers can even attempt the initial RPC handshake. This effectively neutralizes reconnaissance attempts from unauthorized devices or rogue actors on the network.

5. Transitioning to WinRM and Modern Protocols

Where possible, move away from DCOM/RPC-based management in favor of Windows Remote Management (WinRM). WinRM uses HTTP/HTTPS (ports 5985 and 5986) and is much more firewall-friendly. It provides a single, consistent port for management tasks and integrates better with modern security frameworks like Just-Enough-Administration (JEA). While Active Directory still requires RPC, many other management tasks previously handled via WMI/DCOM can be migrated to WinRM.

6. Regular Patching and Vulnerability Management

Since many RPC vulnerabilities reside in the underlying Windows components (like rpcrt4.dll), keeping the operating system patched is non-negotiable. Critical security updates from Microsoft often include fixes for the RPC stack that prevent remote code execution exploits.

Conclusion

Port 135 is the gateway to the Windows RPC ecosystem. Its role as the Microsoft RPC Endpoint Mapper makes it a fundamental requirement for the operation of Active Directory, DCOM, and WMI. However, its efficiency in service discovery is matched by its utility to attackers for system enumeration and lateral movement.

Securing port 135 requires a disciplined approach to network architecture. By enforcing strict perimeter controls, utilizing internal segmentation, and narrowing dynamic port ranges, organizations can maintain the functional benefits of RPC while significantly mitigating the risks of exploitation. In an era of increasing ransomware and sophisticated lateral attacks, treating port 135 as a high-risk entry point is a cornerstone of a robust Windows security posture.

Frequently Asked Questions

What happens if I block port 135?

If you block port 135 on a Windows server, most remote management tools (like WMI and remote Registry) will stop working. Furthermore, if the server is a Domain Controller, Active Directory replication will fail, which can lead to login issues and directory synchronization errors across the entire domain.

Does port 135 use TCP or UDP?

While the MSRPC Endpoint Mapper can listen on both TCP and UDP port 135, the vast majority of modern Windows services and client requests use TCP. UDP 135 is rarely used in modern environments but is often kept open for legacy DCE/RPC compatibility.

Is port 135 related to SMB?

No, port 135 is distinct from SMB (Server Message Block). SMB primarily uses port 445 for file and printer sharing. However, the two often work together; an attacker might use port 135 to find which services are running and then use port 445 to deliver a payload or exploit a file-sharing vulnerability.

How do I close port 135?

You cannot easily "close" port 135 by stopping a single service without breaking core Windows functionality. Instead of closing it, you should secure it using the Windows Defender Firewall to restrict access only to specific, trusted IP addresses or internal networks.

Can port 135 be used for a DDoS attack?

While port 135 is not typically used as a primary vector for Distributed Denial of Service (DDoS) amplification in the way that DNS or NTP is, it can be targeted in a resource exhaustion attack. By flooding the Endpoint Mapper with requests, an attacker can prevent legitimate services from registering or clients from finding the services they need, effectively causing a DoS for Windows management functions.