TCP port 135 is a Windows networking port associated with RPC endpoint mapping and related remote communication functions. In security terms, it matters because it can support remote execution paths and should not be treated as harmless simply because another port, such as 445, has already been restricted.
What TCP port 135 does in Windows networking
TCP port 135 is the RPC endpoint mapper for Windows hosts. It helps clients find the right remote procedure call service before a later connection is made, so it is a coordination point rather than the payload channel itself. That makes it part of the trust path for remote management and remote execution workflows.
Because it brokers service discovery for RPC, port 135 should be treated as an entry point with security significance even when another port is already blocked. If it remains reachable where it is not needed, it can still help an attacker enumerate services, map the host, or reach follow-on management functions.
Why port 135 matters in exposure planning
Security teams often focus on the better-known service ports that appear after RPC negotiation, but the endpoint mapper can still reveal that a Windows system is present and listening for remote requests. That matters because exposure assessment should include the discovery surface, not only the final service ports that users think of as the “real” target.
In practice, the most important question is whether the host actually needs remote RPC reachability from that network segment. If the answer is no, port 135 belongs in the same exposure review as other remote administration ports, because it can preserve a path to later remote communication even when the environment appears partially hardened.
Network Ports and Protocols Security Guide is the most direct navigation point for understanding why port 135 belongs in broader port-hardening work.
How attackers and worms use RPC exposure
Port 135 is dangerous when it remains reachable because it can sit at the front of a remote service chain. Attackers do not need it to be the final exploit destination; they need it to expose enough RPC structure to support enumeration, remote invocation, or movement toward a service that accepts more powerful actions.
This is one reason Windows worm paths and remote-service abuse discussions often include RPC-related exposure alongside SMB and other lateral-movement channels. The practical issue is not the port in isolation, but the combination of service discovery, remote reachability, and any downstream service that trusts that path too much.
Computer Worms Guide helps explain how remote-service exposure can support propagation and lateral movement.
Hardening and validation for port 135
Port 135 should be validated in the context of real business need, network boundaries, and host role. If the system does not require inbound RPC mapping from untrusted or broad internal networks, the preferred control is to block it at the perimeter of that trust zone, not merely to assume the later RPC ports are the only concern.
Where RPC is required, limit exposure to the smallest set of sources that truly need it, and verify that adjacent Windows remote-management paths are not left open by exception. The goal is to reduce unnecessary remote discovery and make sure the endpoint mapper is not acting as an overlooked doorway into administrative services.
SMB Protocol Security and Signing Guide is useful adjacent reading because Windows lateral-movement exposure is often assessed as a connected set of remote protocols rather than a single port.
NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary practitioners usually apply when deciding how to restrict remote access paths and reduce unnecessary exposure.
Detection and post-exposure review
Monitoring should look for unexpected RPC endpoint mapping, unusual source networks, and remote service enumeration that precedes later movement. Port 135 activity is often most valuable as an early signal, because it can show that a host is being probed for reachable services before a more obvious action occurs.
After remediation, review whether the host was ever contacted from an untrusted segment, whether remote administration occurred through the path, and whether any service accounts or privileged sessions were used through the exposed RPC channel. If the port was abused, the response should include a broader review of remote management activity, not just a firewall change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Port 135 is an externally reachable remote access path that boundary controls should restrict. |
| AC-4 — Information Flow Enforcement | Filtering RPC discovery traffic is an information-flow decision across trust boundaries. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | RPC enumeration and remote-service access require reviewable logs for detection and response. | |
| Recommendation — Restrict RPC endpoint mapper exposure with boundary controls and approved allowlists. Enforce network flow rules that block unsolicited RPC mapping traffic. Review logs for unexpected RPC endpoint mapper use and related remote access activity. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Port exposure and firewalling are core network management safeguards for remote services. |
| Recommendation — Harden network boundaries and remove unnecessary RPC exposure from host networks. | ||
| MITRE ATT&CK | T1021 — Remote Services | TCP 135 supports remote service discovery and can enable follow-on remote access abuse. |
| Recommendation — Map RPC exposure to remote-services activity and hunt for downstream lateral movement. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org