What is Port 135 (MS-RPC)? Understanding Microsoft RPC and Its Security Implications

In the complex world of network security, certain ports stand out due to their critical function and inherent vulnerabilities. TCP port 135 is one such port, inextricably linked to Microsoft's Remote Procedure Call (MS-RPC) service. For anyone managing Windows-based networks, understanding what port 135 is, how it functions, and the significant security risks it poses is not just important—it's absolutely essential.

MS-RPC is a fundamental component of the Windows operating system, enabling communication between different processes, whether they are on the same machine or across a network. It's the backbone for a vast array of Windows services, from Active Directory to Group Policy, and even distributed applications. While its utility is undeniable, its pervasive nature and historical vulnerabilities have made port 135 a frequent target for attackers seeking to gain unauthorized access, execute malicious code, or disrupt operations.

This comprehensive guide will delve into the technical specifics of port 135, explore the high-stakes security risks associated with it, detail common attack vectors, and provide actionable strategies for securing your systems. By the end, you'll have a clear understanding of why port 135 is considered a high-risk port and how to implement robust defenses to protect your network in 2025 and beyond.

Port 135 Technical Details: The Core of Microsoft RPC

To truly grasp the security implications of port 135, we must first understand its technical underpinnings. Port 135 is specifically designated for the Microsoft Remote Procedure Call (MS-RPC) Endpoint Mapper service. This service acts as a directory for other RPC services running on a Windows machine.

How MS-RPC Works

MS-RPC is Microsoft's implementation of the Distributed Computing Environment (DCE) RPC specification. It allows a program on one computer to execute code on a remote computer as if it were a local procedure call. Here's a simplified breakdown:

1. Client Request: A client application wants to use a service on a remote server. It doesn't know the specific port the service is listening on, only its RPC interface UUID (Universally Unique Identifier).
2. Endpoint Mapper Query: The client connects to the server's port 135 (the RPC Endpoint Mapper). It queries the Endpoint Mapper, asking for the dynamic port number associated with the desired RPC interface UUID.
3. Dynamic Port Assignment: The Endpoint Mapper responds with the dynamic port number (often in the ephemeral port range, e.g., 49152-65535 for Windows Server 2008 and later) where the requested RPC service is actually listening.
4. Direct Communication: The client then establishes a direct connection to the RPC service on that dynamic port to perform the remote procedure call.

This dynamic port allocation is crucial for understanding network security. While port 135 is the initial point of contact, the actual RPC communication often occurs over a range of other ports. This makes comprehensive firewalling more challenging, as simply blocking port 135 might break legitimate services without fully securing the system if other RPC-related ports are open.

MS-RPC is deeply integrated into core Windows functionalities, including:

• Active Directory: Essential for domain controllers to communicate and replicate data.
• Group Policy: Used for applying policies to client machines.
• Distributed Component Object Model (DCOM): Enables software components to communicate across networks.
• Exchange Server: Relies on RPC for various internal communications.
• System Center Configuration Manager (SCCM): Uses RPC for client management.

Given its foundational role, any vulnerability in MS-RPC or its associated services can have far-reaching consequences across an entire Windows domain, elevating port 135 to a critical security concern.

Security Risks of Open Port 135: A Gateway for Attackers

An open or improperly secured TCP port 135 is a significant security liability for any Windows environment. Due to MS-RPC's fundamental role in Windows operations and its history of vulnerabilities, attackers frequently target this port to gain initial access, escalate privileges, or move laterally within a compromised network. Exposing port 135 directly to the internet is akin to leaving your front door wide open, inviting a myriad of sophisticated threats.

Common Attacks on Port 135: Exploiting MS-RPC Vulnerabilities

The history of Windows security is rife with examples of critical vulnerabilities affecting MS-RPC and services that rely on port 135. These attacks often leverage buffer overflows, authentication bypasses, or logic flaws to achieve their objectives. Understanding these common attack vectors is crucial for effective defense.

How to Check if Port 135 is Open on Your Network

Before you can secure port 135, you need to know if it's currently open and accessible on your systems. There are several methods to check for open ports, ranging from command-line tools to online scanners. It's crucial to perform these checks from both inside your network and, if applicable, from an external perspective to understand your true exposure.

Using Nmap (Network Mapper)

Nmap is the industry-standard tool for network discovery and security auditing. It can quickly scan a single host or an entire network for open ports. To check if TCP port 135 is open on a target system, you can use the following command:

nmap -p 135 target.com

Replace target.com with the IP address or hostname of the system you want to scan. If the port is open, Nmap will report its state as 'open'. You can also add the -sV flag to attempt service version detection, which might provide more details about the RPC service running:

nmap -p 135 -sV target.com

For a more comprehensive scan that includes common RPC-related ports and scripts, you might use:

nmap -p 135,139,445 --script=rpcinfo target.com

Using Online Port Scanners

For a quick external check, online port scanners can be very useful. These tools scan your public IP address from the internet, showing you which ports are accessible from the outside world. When checking for port 135, ensure you use a reputable and secure online tool.

You can easily scan port 135 with our free Secably Port Scanner. Simply enter your public IP address or domain name, specify port 135, and initiate the scan to see if it's exposed to the internet.

Using PowerShell (Windows)

On a Windows machine, you can use PowerShell to check local port status or attempt a connection to a remote host:

# Check local port 135 status (requires admin privileges)
Get-NetTCPConnection -LocalPort 135

# Test connection to a remote host on port 135
Test-NetConnection -ComputerName target.com -Port 135

If TcpTestSucceeded is True, the port is likely open and reachable.

Regularly scanning your network for open ports, especially critical ones like 135, should be a routine part of your security posture. This helps identify unintended exposures and ensures your firewall rules are functioning as expected.

How to Secure Port 135: Essential Hardening Steps

Securing TCP port 135 is paramount for protecting your Windows infrastructure. Given its high-risk nature and its integral role in Windows services, a multi-layered approach is required. The goal is to minimize its exposure, especially to the internet, and to ensure that only authorized and necessary communication occurs.

When Should Port 135 Be Open? Legitimate Use Cases

Despite the significant security risks, TCP port 135 is not inherently malicious. It's a fundamental component of Windows networking, and there are legitimate scenarios where it must be open, but always with strict controls and within a trusted network boundary. The key principle is to never expose it directly to the internet.

Legitimate use cases for port 135 primarily involve internal communication within a Windows domain or between trusted Windows systems:

• Active Directory Domain Controllers: Domain controllers heavily rely on MS-RPC for replication, authentication, and communication with other domain controllers and client machines. Port 135 is essential for these core Active Directory functions.
• Group Policy Processing: Client machines use RPC to communicate with domain controllers to retrieve and apply Group Policy settings.
• Distributed Component Object Model (DCOM) Applications: Many legacy and some modern Windows applications use DCOM for inter-process communication across networks. If you have such applications, port 135 will be required for their functionality.
• Microsoft Exchange Server: Exchange servers utilize RPC for various internal services and communication between server roles.
• System Center Configuration Manager (SCCM/MECM): SCCM clients and servers use RPC for management tasks, software distribution, and inventory collection.
• Remote Administration Tools: Some remote administration tools and scripts (e.g., PsExec, WMI) leverage RPC for their operations. These should only be used within a secure, internal network.
• Windows Management Instrumentation (WMI): WMI, a core component for managing Windows environments, often uses RPC for remote queries and operations.

In all these scenarios, port 135 should only be accessible from within your trusted internal network segments. It should be protected by firewalls that restrict access to only the specific IP addresses or subnets that require it. Exposing port 135 to untrusted networks, especially the public internet, creates an unacceptable risk.

Is port 135 dangerous?

Yes, port 135 is considered dangerous if it's open to untrusted networks, especially the internet. It's associated with the Microsoft Remote Procedure Call (MS-RPC) Endpoint Mapper, a critical Windows service that has been historically targeted by numerous severe vulnerabilities, including remote code execution (RCE) flaws. An exposed port 135 can be a gateway for attackers to compromise Windows systems, leading to data breaches, system disruption, and full network control.

Should I close port 135?

You should close or strictly restrict access to port 135 from any untrusted network, particularly the internet. For internal networks, you cannot simply 'close' port 135 on Windows systems that rely on MS-RPC for core functionalities like Active Directory, Group Policy, or DCOM applications, as this would break essential services. Instead, you should implement strict firewall rules to allow access only from specific, trusted internal IP addresses or subnets that legitimately need to communicate via RPC.

How do I block port 135?

Blocking port 135 should be done at your network perimeter firewall and on individual host-based firewalls. Here are common methods:

Windows Defender Firewall (PowerShell):

# Block inbound TCP port 135 from any source
New-NetFirewallRule -DisplayName "Block Port 135 Inbound" -Direction Inbound -Action Block -Protocol TCP -LocalPort 135

Linux (iptables - for a gateway/proxy):

# Block inbound TCP port 135
sudo iptables -A INPUT -p tcp --dport 135 -j DROP
# Remember to save iptables rules (e.g., sudo netfilter-persistent save)

Linux (UFW - Uncomplicated Firewall):

# Block inbound TCP port 135
sudo ufw deny 135/tcp

Always test your firewall rules after implementation to ensure you haven't inadvertently blocked legitimate internal traffic.

What runs on port 135 by default?

By default, TCP port 135 is used by the Microsoft Remote Procedure Call (MS-RPC) Endpoint Mapper service on Windows operating systems. This service acts as a directory for other RPC-based services. When a client wants to communicate with a specific RPC service, it first queries the Endpoint Mapper on port 135 to discover the dynamic port number where that particular service is listening. Many core Windows components and services, including Active Directory, Group Policy, DCOM, Exchange Server, and SCCM, rely on MS-RPC and thus indirectly on port 135 for their functionality.