Port 135 – Microsoft RPC Endpoint Mapper

Port 135 is the default port for the Microsoft RPC Endpoint Mapper (EPMAP), the Windows service that tells an RPC client which port a given RPC or DCOM service is currently listening on. RPC services don’t sit on fixed ports — they register with the endpoint mapper at startup and get a dynamic port in the 49152–65535 range. A client connects to 135 first, asks “where is service X?”, gets back a port, then connects there. That makes port 135 the front door to WMI, DCOM, the Service Control Manager, the task scheduler, and dozens of other interfaces — and one of the most useful ports on any Windows host to an attacker.

Why It’s Open

Windows can’t function without it. DCOM, WMI, MSDTC, Active Directory replication, the classic Outlook-to-Exchange connection, and most remote-management tooling all reach their services through the endpoint mapper, so 135 is open by default on every Windows workstation, member server, and domain controller. In an Active Directory environment you can’t simply close it without breaking replication and management — which is exactly why it’s a reliable target. It’s always there, it rarely gets firewalled internally, and it hands out a map of everything else the host is running. Where you find 135 you’ll usually find SMB on port 445 next to it, and on a domain controller, Kerberos on 88 and LDAP on 389.

Common Risks

• Endpoint-map disclosure. Dumping the endpoint mapper lists every RPC interface the host has registered. That single query fingerprints the OS, says whether the box is a domain controller, an Exchange server, or a SQL host, and points you at the exact dynamic ports to hit next — all unauthenticated.
• Lateral movement. DCOM, WMI, remote service creation, and scheduled tasks all ride RPC through 135 to a dynamic port. With valid credentials, tools like Impacket’s wmiexec.py/dcomexec.py, wmic, and PsExec turn port 135 into a SYSTEM shell — which is why practitioners now talk about “135 being the new 445” for remote execution.
• Authentication coercion. RPC interfaces such as MS-EFSRPC (PetitPotam) and MS-RPRN (the printer bug) can be called to force a machine account to authenticate to an attacker, feeding an NTLM relay against AD CS or LDAP. The coercion rides the same RPC plumbing that 135 fronts.
• Remote code execution. The RPC runtime itself has been remotely exploitable (CVE-2022-26809, wormable), and legacy RPCSS/DCOM overflows (the Blaster family) gave unauthenticated RCE straight off port 135.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect the service

nmap -sV -p 135 --script=msrpc-enum <target>

Dump the endpoint map with Impacket

rpcdump.py <target>

List listening RPC interfaces

rpcmap.py 'ncacn_ip_tcp:<target>[135]'

Enumerate with Metasploit

msfconsole -q
use auxiliary/scanner/dcerpc/endpoint_mapper
set RHOSTS <target>
run

Authenticated RPC access and remote exec

rpcclient -U '<user>' <target>
wmiexec.py '<domain>/<user>:<password>@<target>'

The endpoint-map dump is the payload here — note every interface it returns (Exchange, the DC replication service, the spooler) and the dynamic ports behind them, and put that map in the pentest report so the pivot path is documented, not lost in scrollback.

What to Look For

Known CVEs and Exploits

• CVE-2022-26809 — A remote code execution flaw in the Windows RPC runtime, reachable over TCP 135 (endpoint mapper) and 445 (RPC over SMB). No authentication or user interaction, code runs at the privilege of the RPC server, and Microsoft rated it wormable — CVSS 9.8. Patched in the April 2022 updates; hundreds of thousands of hosts sat exposed after release.
• CVE-2003-0352 — The DCOM/RPC buffer overflow behind the Blaster (MSBlast/Nachi) worm, MS03-026. A malformed activation message to the RPCSS interface on port 135 gave remote code execution on Windows NT 4.0/2000/XP/2003.
• CVE-2003-0715 — The MS03-039 follow-up: a heap overflow in the same RPCSS DCOM interface via a crafted DCERPC object-activation packet with modified length fields. CVSS 10.0, and distinct from the Blaster bug — proof the DCOM activation path was rotten in more than one place.

Mitigation

• Never expose 135 to the internet or untrusted segments. Microsoft’s own guidance is to block TCP 135 (and 445) at the perimeter. Restrict it to management ranges with a host firewall — this is the single highest-impact fix.
• Patch the RPC runtime. The April 2022 update closes CVE-2022-26809; keep hosts current so the wormable path stays shut.
• Constrain the dynamic port range and apply RPC filters or IPsec so only authorized clients can reach the services the endpoint mapper points at.
• Harden DCOM. Enable the DCOM authentication hardening (the CVE-2021-26414 enforcement) and disable DCOM/WMI remoting where nothing needs it.
• Blunt coercion and relay. Enforce SMB signing and Extended Protection for Authentication so a machine account coerced over RPC can’t be relayed into AD.
• Segment, don’t delete. Inside AD you can’t remove 135, so put domain controllers and servers behind segmentation and watch the endpoint mapper for enumeration from unexpected hosts.

Real-World Example

In August 2003 the Blaster worm spread by firing the CVE-2003-0352 DCOM overflow at port 135 across the internet. It needed no user interaction — just an open 135 — and infected millions of Windows machines within days, crashing systems into reboot loops with the RPCSS service and launching a SYN flood against windowsupdate.com. The cleanup, and the Nachi/Welchia “helper” worm that piled in behind it, made Blaster the textbook case for why an internet-facing RPC endpoint mapper is indefensible. Nearly two decades later CVE-2022-26809 put the same unauthenticated-RCE-over-135 risk back on the table, which is why the port is still one of the first things flagged on an external scan.

FAQ

What service runs on port 135?

The Microsoft RPC Endpoint Mapper (EPMAP), also called the RPC locator. It’s a directory service: RPC and DCOM programs register with it, and clients query port 135 to find out which dynamic port (49152–65535) a given service is currently using before connecting to it.

Is port 135 dangerous?

Exposed to an untrusted network, yes. Even without a vulnerability, querying it reveals the host’s RPC service map and fingerprints the machine. With credentials it enables WMI/DCOM lateral movement to SYSTEM, and unpatched RPC runtimes are directly exploitable (CVE-2022-26809). Internally it’s a normal, necessary port; internet-facing it’s a serious finding.

Why is port 135 open in Active Directory, and can I close it?

Domain controllers and member servers use RPC over 135 for replication, DCOM, WMI, and management, so you can’t disable it inside AD without breaking things. The fix isn’t to close it on the host — it’s to make sure 135 is never reachable from the internet or untrusted VLANs, and to segment and monitor it internally.

Is port 135 the same as port 445?

They’re related but distinct. Both carry RPC: 135 is the endpoint mapper that locates services, while 445 (SMB) is a named-pipe transport RPC can also ride. Modern lateral-movement tooling increasingly reaches services through 135 and a dynamic RPC port instead of 445, which is where the “135 is the new 445” line comes from.

TL;DR

• Service: Microsoft RPC Endpoint Mapper (EPMAP / rpcss)
• Default port: 135/TCP (services pivot to dynamic ports 49152–65535)
• Biggest risk: endpoint-map enumeration, WMI/DCOM lateral movement, and RPC-runtime RCE (CVE-2022-26809)
• Mitigation: never expose 135 externally, patch the RPC runtime, harden DCOM, and segment it inside AD