RPC over TCP

What RPC over TCP Does

RPC over TCP is a transport choice, not a different RPC model. It places remote procedure call traffic on top of TCP so the client and server can communicate across a network with ordered delivery and connection state, rather than relying on a local inter-process channel. That makes it suitable when the caller needs a stable network path to a remote service.

The important security point is that the protocol boundary shifts from a local machine assumption to a networked trust boundary. Once calls cross TCP, exposure depends on how the endpoint is addressed, who can reach it, and whether the application layer adds authentication, authorization, and message integrity controls.

Why RPC over TCP Is Used

Teams use RPC over TCP when they want the convenience of procedure-style calls without giving up network reachability. TCP is often chosen because it handles retransmission, ordering, and session continuity, which can be useful for stateful request and response patterns or for services that expect reliable delivery.

In practice, the transport choice is usually driven by interoperability and deployment constraints. A service may need to talk to remote hosts across routed networks, traverse firewalls or internal segments, or integrate with software that already expects TCP-based communication. The transport itself does not provide trust, it only provides carriage.

Security and Trust Boundary Implications

RPC over TCP inherits the same exposure patterns as any TCP-reachable service. If a listening port is exposed too broadly, the RPC endpoint becomes discoverable to unintended clients, and if the application layer is weak, an attacker may be able to invoke sensitive functions, enumerate services, or abuse unauthenticated request paths.

Because TCP is connection-oriented, defenders sometimes assume that a reachable session is implicitly trustworthy. That assumption is dangerous: network reachability does not equal authorization, and a valid connection still needs strong caller verification, request validation, and least-privilege function design.

Where RPC carries administrative or operational actions, the business impact can be severe. A misused procedure call can expose configuration, trigger privileged operations, or move laterally into adjacent systems if the RPC interface is trusted more than the caller should be.

Operational Considerations for Implementers

RPC over TCP is often a dependable choice, but it demands careful interface design. The service should expose only the procedures that are genuinely required, bind only to the network locations that need access, and treat every remote caller as untrusted until it is authenticated and authorized at the application layer.

Network controls should support that design rather than substitute for it. Segmentation, host-based allowlisting, service exposure review, and encryption in transit all help reduce risk, but they do not remove the need to control which methods exist and who can call them. For environment-specific hardening guidance, the Printer and Print Spooler Security Guide is a useful example of how RPC-based services should be constrained and hardened at the transport and service layers.

Risk and Threat Considerations

RPC over TCP becomes risky when a network-reachable procedure interface is treated as if it were private or implicitly trusted. The main failure modes are exposed management functions, weak caller validation, and overbroad exposure of a service endpoint that can be probed or abused from other hosts.

Failure mechanism: An attacker or unintended client reaches the TCP listener, discovers callable procedures, and exploits missing authentication, excessive privilege, or unsafe function handling to execute actions the service should not permit.

Impact: The result can include unauthorized actions, service disruption, lateral movement, and compromise of the underlying system or any downstream resource the RPC service can access.

Practitioner Guidance

Why practitioners should care: RPC over TCP is common in internal systems, so it is easy to underappreciate its exposure until a service is reachable outside the intended trust zone. The practical question is not whether TCP works, but whether the exposed RPC surface is actually fit for remote use.

What to watch for: Review any RPC service that is bound to broad interfaces, lacks strong authentication, or exposes privileged methods over a routable network path. If the service can perform administrative work, assume the transport alone is insufficient protection.

Practitioner takeaway: Treat RPC over TCP as a remote attack surface, not a convenience layer, and design the service contract, network exposure, and caller controls together.

Related resources from NHI Mgmt Group

• What is the difference between SMB over NetBIOS on port 139 and SMB directly over TCP/IP on port 445?
• How do attackers use TCP RPC Scan?
• How can security teams detect TCP RPC scans?
• What mitigations reduce the risk of a TCP RPC scan?