Remote Procedure Call (RPC)

Severity: High

Likelihood: Medium (varies by environment; higher in legacy systems, flat networks, or improperly segmented environments)

General Guidance

Restrict RPC access to trusted systems and networks, and enforce proper network segmentation. Disable unnecessary RPC services and ensure strong authentication and patching practices are in place.

What is the concern?

RPC enables systems to execute functions remotely, often underpinning critical services like Windows networking, authentication, and management (e.g., MSRPC). When exposed or improperly secured, RPC services can allow attackers to execute code remotely, enumerate systems, or exploit known vulnerabilities. Many RPC services are complex and historically prone to critical flaws.

Business Impact

• Remote code execution on critical systems

• Full system compromise or domain takeover (in Windows environments)

• Rapid lateral movement across the network

• Data exfiltration or destruction

• Service outages impacting business operations

How can this be resolved?

• Block RPC exposure from untrusted networks (especially internet-facing)

• Implement strict network segmentation (limit RPC to necessary hosts)

• Patch systems regularly to address known RPC vulnerabilities

• Disable unnecessary RPC services and legacy protocols

• Use host-based firewalls to restrict RPC port ranges (e.g., TCP 135 + dynamic ports)

• Monitor and restrict administrative access pathways (e.g., SMB, WMI)

RPC services should instead be hidden behind a firewall and/or VPN, or similar action taken, to prevent any unwanted access or intrusion which could later be used to access the internal network via any connecting devices or accidental connection onto the core network. If placing these services behind a firewall/VPN, only a narrow set of allow-listed services should be permitted to connect. If you do this, KYND will mark the issue as resolved.

If this isn’t possible, you should take alternative steps to mitigate the issue.

This could include adding extra layers of authentication, including MFA or PKI certificates to ensure that only authenticated users and services are able to connect.

If none of these are possible, then these services should be entirely separated from the rest of your organization's infrastructure, ensuring that there is no way an attacker could traverse from an attack on this service to gain access to sensitive data, services, networks or infrastructure.

Real-World Example

• WannaCry (2017): Exploited the SMB protocol (closely tied to RPC mechanisms in Windows) using the EternalBlue exploit. This allowed unauthenticated remote code execution and led to widespread ransomware infections across global organizations, including healthcare and logistics.

• Blaster Worm (2003): Directly exploited a vulnerability in the Windows RPC service (DCOM). It spread rapidly across networks by scanning for exposed RPC endpoints, causing widespread system crashes and network disruption.

• Modern lateral movement: Threat actors frequently use RPC-based tools (e.g., WMI over RPC) post-compromise to move laterally and execute commands across Windows environments without dropping malware.

Detection Opportunities

• Network monitoring:

  • Unusual traffic on TCP port 135 and high-numbered dynamic RPC ports

  • Lateral movement patterns between internal hosts

• Endpoint monitoring:

  • Suspicious use of WMI, PsExec, or remote service execution

• Log analysis:

  • Windows Event Logs (e.g., Event ID 4688 for process creation via remote execution)

  • RPC and DCOM-related logs where available

• Threat hunting:

  • Indicators of known exploits targeting RPC services

  • Abnormal administrative behavior across multiple systems

• Vulnerability scanning:

  • Identify unpatched systems vulnerable to known RPC exploits