A Definitive Guide to the Remote Procedure Call (RPC) Filter

Simply filtering traffic, however, isn’t always enough. Often, monitoring is also needed — both for security reasons (to see what unwanted operations are attempted in the network and blocked), and to see if filter rules are operating correctly. Luckily, WFP contains built-in capabilities to create audits of both successful and failed connections, and this extends to RPC traffic and filters as well. Once auditing is configured, RPC events will be written to the Security Event Log.

Under the hood, RPC filter auditing is achieved with a special sublayer named FWPM_SUBLAYER_RPC_AUDIT, which filters the need to specify for their events to be logged. See the sections below on adding filter auditing when using netsh or the Windows API.

RPC auditing isn’t enabled by default. To enable it, you can use the following command:

There are two ways to access the RPC filter. Network administrators will most likely use netsh to manage their filters, as it is a relatively simple command-line utility. The RPC filter is also exposed through the Windows Filtering Platform (WFP) API, to allow developers to integrate RPC filtering functionality to their applications.

There are two ways to access the RPC filter. Network administrators will most likely use netsh to manage their filters, as it is a relatively simple command-line utility. The RPC filter is also exposed through the Windows Filtering Platform (WFP) API, to allow developers to integrate RPC filtering functionality to their applications.

Network administrators can add, list, and remove RPC filters using netsh. The RPC filter is a netsh context that is implemented in a helper DLL named rpcnsh.dll. To enter the RPC filter context, simply run netsh from an elevated prompt and then execute rpc filter.

The process of adding filters through netsh is as follows:

1. Add a rule

2. Add at least one condition to the rule

3. Add the rule (along with its conditions) to a filter

Note: In WFP, filters are created and assigned to a certain layer, and conditions are then added to those filters; netsh adds the concept of rules to this hierarchy, which is somewhat unnecessary as only one rule can be attached to a filter. 

Let’s continue with the command syntax for every step.

When adding a rule, the following parameters can be specified:

• layer — the WFP layer to which the rule (=filter) should be added

• actiontype — block, permit, or continue

• persistence — whether or not the rule is persistent across reboots

• filterkey — set a custom UUID for the RPC filter (if not specified, one is created randomly)

• audit — set the rule to be an audit rule (see the “Auditing with netsh” section)

When adding a condition, the following parameters can be specified:

• field — the data field on which comparison is performed; fields are specified in our table as well as in the WFP documentation

• matchtype — the matching operation (equal, greater, less, etc.)

• data — the value to associate with the field

When adding a rule to a filter, one simply needs to execute add filter and the current rule (along with its conditions) will be added to the filter. This command takes no parameters.

The general netsh chain of commands would look like this:

These commands result in the creation of an RPC filter that blocks remote connections to the RPC endpoint with the specified UUID, which happens to be the RPC interface endpoint of the Windows Event Log.

RPC filter auditing is supported on netsh, though only with permit rules. To add auditing, simply add the flag audit=enable to the rule creation command. According to MSDN, auditing can be applied to all layers except for FWPM_LAYER_RPC_EP_ADD.

As the RPC filter is implemented in Windows Filtering Platform (WFP), it can be managed through the WFP API that is exported by FWPUCLNT.DLL and declared in fwpmu.h. This can be useful for developers who wish to build their own defense tools and mechanisms. The general process of adding filters through the WinAPI is as follows:

1. Create a session and get a handle to FwpmEngine with FwpmEngineOpen0

2. Populate the filter struct FWPM_FILTER0 with the data needed for the filter (layer, action and conditions)

3. Call FwpmFilterAdd0 to register the filter

4. Close the handle to the FwpmEngine with FwpmEngineClose0

All the structures and functions are documented in MSDN, and are pretty straightforward to find. Nonetheless, we provide a detailed walk-through of the API in the section below.

To make the rules audit to the Event Log, two things need to happen:

1. The filter should populate the sublayer struct member with FWPM_SUBLAYER_RPC_AUDIT, thus registering to the auditing sublayer.

2. The rawContext member of the filter struct should be set to 1. We haven’t found the documentation supporting this, but we have found it necessary to do so to set the auditing. Netsh is doing the same thing behind the scenes when setting auditing for filters.

We’ve gone through all the theory of creating RPC filters both using netsh and the Windows API, but nothing beats hands-on experience. For this purpose, we’re including a short tutorial session using Windows Event Log’s RPC endpoint, whose UUID is F6BEAFF7-1E19-4FBB-9F8F-B89E2018337C. For your convenience, we have also opened a GitHub repository with all the code and scripts from this tutorial.

To block all remote RPC connections to the Event Log, you can use the netsh commands listed in Using netsh to create RPC filters. To pass this as a script to netsh, simply call it with the -f flag:

Jonathan Johnson from Red Canary published a GitHub repository with multiple RPC filter scripts, each tailored to a specific potentially exploitable service.

For brevity, we will not include the full source code in this guide, but only parts of it. The full code can be found in our repo.

To get started, simply include the header fwpmu.h and point the linker to the DLL’s lib file (we did it simply with #pragma comment(lib, "Fwpuclnt.lib")). 

To get a handle to the firewall engine, create the session struct FWPM_SESSION0, zero it out and fill some of its fields. You really only need to set the kernelMode boolean to FALSE, but we also set the dynamic session flag to not have to deal with cleanup. The filter will disappear automatically once the session closes (which happens automatically upon process termination). Pass the session pointer to FwpmEngineOpen0.

Conditions are specified in the FWPM_FILTER0 struct under the member filterCondition. They come as an array of the struct FWPM_FILTER_CONDITION0, where each array member is a different condition. Conditions in the array are matched using logical AND.

MSDN lists filtering conditions per each layer and provides details for each filter. We created our own table aggregating this information with our own insights and observations.

The condition struct FWPM_FILTER_CONDITION0 is fairly straightforward; simply specify the field identifier (e.g., FWPM_CONDITION_RPC_IF_UUID), the value which you want to match (e.g., 338CD001-2244-31F1-AAAA-900038001003), and how to match it (equals, contains, greater, etc.). The API doesn’t accept a string UUID but a struct instead. You can use UuidFromString to achieve this translation. 

Pass the filtering condition to the filter struct with action BLOCK:

Once all the necessary struct members have been set, a simple call to FwpmFilterAdd0 with the engine handle, and a pointer to the filter struct will register it in the WFP and will get it to work.

To view your existing RPC filter, simply use netsh’s show filter command, inside the RPC filter context.

To trigger a RPC call to the Event Log, which can be caught by RPC filters, you can use the following command:

wevtutil /r:127.0.0.1 qe System /c:1

This would try to access the Event Log over RPC, over the network, even though it is confined to the localhost. With the RPC filter we described above in place, which blocks RPC connections from remote computers on the interface UUID, the call gets denied:

To delete filters, if you haven’t used the dynamic flag in their creation (if created with WinAPI), you can use netsh’s delete filter command. You can put a specific filter key instead of all.

This section is a deep dive into RPC filter internals. It describes the flow that takes place internally, from the moment a rule is created until a packet is blocked. This knowledge can be of use for both security researchers and red-teamers seeking to find vulnerabilities in the implementation or bypasses of the filter.

The following are the processes and libraries that are involved in RPC filtering.

When a new rule is created, the helper DLL for the RPC filter (rpcnsh.dll) invokes WFP functionality from fwpuclnt.dll. This results in RPC requests to an interface that is exported by the Base Filtering Engine, a service that manages firewall policies and implements user-mode filtering.

Consequently, a WNF state named WNF_RPCF_FWMAN_RUNNING is changed. The RPC runtime subscribes to this state, such that whenever it changes, the RPC runtime loads the extension DLL that filters packets.

An RPC packet’s journey includes parts in the kernel space as well as the transition from kernel to userland. We will skip these parts, and focus only on the parts of the journey that are relevant to the RPC filtering. There are two parts for this: what happens in the context of the receiving process, and what happens in the Windows Firewall itself, namely the Base Filtering Engine. Standing between the two parts is the extension DLL RpcRtRemote.dll, with its FwFilter function.

First, the receiving process. Once the RPC packet has passed the OS’s processing, and is associated with the relevant process and identified as an RPC packet, it arrives at the RPC runtime — RpcRT4.dll (RPCRT4!CO_ConnectionThreadPoolCallback).

The RPC runtime begins parsing the received packet, and eventually checks if the connection is allowed, with an AccessCheck (RPCRT4!OSF_SCALL::DoSecurityCallbackAndAccessCheck); this matches other Windows API naming conventions — for example, object access rights are also verified with a function called AccessCheck.

The AccessCheck doesn’t do much. It checks if filtering is needed by determining whether the client is local or remote (RPC filters only apply to remote clients):

If filtering is required, the RPC runtime attempts to load the extension DLL if it isn’t already loaded, and then calls RPCRT4!OSF_SCALL::FwFilter. The RPC runtime FWFilter function collects some information on the remote client (e.g., its IP address) and passes the ball to the extension DLL’s FwFilter function (RpcRtRemote!FwFilter). 

What the extensions DLL’s FwFilter does is fairly similar to what the runtime did. It collects more information on the connection (e.g., the security descriptor of the connecting user), and then uses the actual Windows Firewall client DLL fwpuclnt.dll, with a call to the internal function FwpsClassifyUser0. This is the last part in the function call chain that occurs in the context of the process hosting the RPC server. From there, a local RPC request is made to the Base Filtering Engine, which is what is actually responsible for deciding whether the connection should be allowed or blocked.

RPC filters are a powerful utility that comes with Windows Firewall. They open the door for various defense and segmentation capabilities that aren’t easily accessible using traditional security tools, like segmenting randomly assigned ephemeral ports or specific users. 

In this guide, we explained what RPC filters are in the Windows Firewall, how they can be utilized, and their possible use cases. We included guides on their usage, both for power users using netsh, and for developers using Windows API. We also added a short tutorial for creating a filter, shared a GitHub repository with code examples, and researched the inner workings of packet filtering.

We wrote this guide in the hope that the security community can build atop it various tools and capabilities that better defend against emerging threats. We also hope that our work will pave the way for further OS internal research to ensure the security and reliability of this and other protection mechanisms.