Unmasking Lateral Movement: Why You Should Stop Ignoring MS-RPC Traffic

TLDR: Microsoft Remote Procedure Call (MS-RPC) is a goldmine for attackers performing lateral movement, yet it remains largely invisible to standard network monitoring tools. By leveraging Event Tracing for Windows (ETW), researchers can now correlate RPC events with network connection data to detect techniques like PsExec, DCSync, and PetitPotam. This post explores how to use the new RPC Visibility tool to map these interactions and why Windows Firewall RPC filters are your best bet for blocking unauthorized service creation.

Security researchers often focus on the flashy, high-impact vulnerabilities that make headlines, but the real work of a red team engagement happens in the quiet, overlooked corners of the Windows operating system. MS-RPC is one of those corners. It has been around since the nineties, and it is still the backbone of how Windows services talk to each other. Because it is so deeply integrated into the OS, it is also the primary mechanism for lateral movement. If you are not monitoring RPC, you are missing the vast majority of what an attacker does once they land on a machine.

The Visibility Gap in RPC Traffic

Traditional network security tools rely on deep packet inspection to understand what is happening on the wire. The problem is that RPC is an encapsulation nightmare. It is a layer on top of a layer, and by the time you peel back the transport protocols like SMB or TCP, the actual data—the specific function being called—is often lost or too expensive to parse in real-time. Most network defense tools just see connection metadata, which tells you that two machines are talking, but not what they are saying.

This is where Event Tracing for Windows (ETW) changes the game. ETW is a high-performance, built-in logging mechanism that sits right in the kernel. Instead of trying to sniff the network, you can tap into the RPC provider directly on the host. By subscribing to the RPC ETW provider, you get a front-row seat to every interface call, including the specific operation being requested.

Mapping Attacks with RPC Visibility

During a recent research project, the team at Akamai developed a tool called RPC Visibility to bridge the gap between network logs and host-based events. The tool uses a Python script to hook into pywintrace, subscribe to SMB, TCP, and RPC providers, and then push that data into Neo4j.

The power of this approach is in the correlation. When an attacker uses PsExec to move laterally, they copy a binary to an admin share and then use the Service Control Manager (SCM) to start it. Standard logs might show the file copy, but they often fail to link that action to the subsequent service creation. With RPC Visibility, you can see the exact sequence:

# Example of identifying an RPC call via the provider
# The tool maps the Opnum to the specific function
# RCreateServiceW is a common target for lateral movement

By querying the graph database, you can filter for specific interfaces like svcctl or drsuapi. If you see an unknown source machine calling RCreateServiceW on a domain controller, you are not looking at a theoretical risk; you are looking at a live lateral movement attempt.

Real-World Impact for Pentesters

On an engagement, you will encounter these techniques constantly. DCSync is a classic example. An attacker pretends to be a domain controller and requests a replication of the credential database using the DRSGetNCChanges function. Because this is an RPC call, it is often missed by EDR solutions that are focused on process execution or file system changes.

Similarly, PetitPotam exploits the Encrypting File System Remote Protocol (MS-EFSR) to coerce a machine into authenticating against an attacker-controlled server. By monitoring for these specific RPC calls, you can identify the coercion attempt before the NTLM relay even happens. This is the difference between a successful compromise and a caught engagement.

Defensive Mitigation: The Power of RPC Filters

If you are working with a blue team, the most effective way to stop this is not just detection, but active filtering. Windows has a built-in, yet underutilized, feature called RPC Filters within the Windows Firewall.

You can define rules that block specific RPC interfaces or even specific operations based on the user token or the source IP. For example, if your environment does not require remote service creation, you can create an "anti-PsExec" rule that blocks the RCreateServiceW operation across your fleet.

# Example of using netsh to add an RPC filter
netsh advfirewall set rpc-filter add rule name="BlockRemoteServiceCreation" 
interface=svcctl opnum=0x0c action=block

This is not about blocking all RPC traffic, which would break your network. It is about surgical precision. You identify the interfaces that attackers abuse—like the SCM or the Directory Replication Service—and you restrict them to only the machines that actually need them.

The era of relying solely on network-level perimeter defense is over. Attackers have moved into the application layer, and they are using the very protocols that keep your network running to tear it down. If you want to stay ahead, you need to start looking at the RPC calls happening on your endpoints. Start by deploying the RPC Visibility tool in your lab, map out the normal traffic patterns in your environment, and then start building your filters. The fog of war is only as thick as you let it be.