If you are unfamiliar with RPC communication, or the RPC Firewall itself and how it can be a Ransomware auto-blocker, I do suggest reading our previous blog post to get a better understanding.
RPC is the underlying mechanism for many forms of attacks and lateral-movement techniques. Some of these are: DCSync attack, WMIC, SharpHound, PetitPotam, PsExec, and many more…
Some of these attacks can be mitigated using the native Windows RPC Filters, while others can be stopped with our own RPC Firewall. RPC Firewall version 2.0 enables users to customize their RPC protection to comprise of the native RPC Filters, RPC Firewall, or both, according to need.
Terminology
Before diving into more details, it is important to get our terms straight. Throughout this document, we will use the following:
- RPC Firewall: Refers to the actual RpcFirewall.dll, which is loaded into various RPC servers to protect them.
- RPC Filters: Refers to the native Windows RPC filtering mechanism.
- RPCFW Configuration: Refers to the RpcFw.conf file, which is used to control how the RPC Firewall and RPC Filters behave.
- RPCFW Manager: The command line interface, which gives users access to both RPC Firewall and RPC Filters.
- OpNum: a number, representing a specific function of an RPC interface.
RPC Filters Use Cases
RPC Filters are very good at creating deny-lists, blocking entire RPC interfaces for anyone, or based on the user’s identity.
As an example, let’s consider PsExec, as a method for lateral movement. To eliminate PsExec within your organization, we need to block the MS-SCMR, which is the underlying mechanism used by PsExec to create and run remote services. This could be achieved via the following RPCFW configuration line:
flt: action:block audit:true uuid: 367ABB81-9844-35F1-AD32-98F038001003
Another example of a protocol that you wish to avoid is the MS-EFSRPC, which can enable the PetitPotam attack, which can also be blocked using a similar method:
flt: action:block audit:true uuid: df1941c5-fe89-4e79-bf10-463657acf44d
flt: action:block audit:true uuid: c681d488-d850-11d0-8c52-00c04fd90f7e
RPC Firewall (Ransomware Auto-Blocker) Use Cases
The RPC Firewall allows us to be more granular about the specific OpNums we wish to block and the source addresses from which we allow RPC calls.
For example, to protect against the DC replication attack, you need to only allow the OpNum 3 function (DRSGetNCChanges of MS-DRSR) exclusively for specific source hosts (aka, other DCs). Other functions in the same interface can be enabled. This could be achieved using the following configuration:
fw: uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 opnum:3 action:allow addr:
fw: uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 opnum:3 action:allow addr:
fw: uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 opnum:3 action:block
fw: uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 action:allow
RPC Filters VS RPC Firewall: Configuration Templates
As we saw in previous examples, there are use cases where RPC filters are more appropriate, and other cases where the RPC Firewall comes in handy. To make things simpler for most users, we compiled several configuration templates. These templates can be used as a starting point for protecting servers via the RPC Firewall, RPC Filters or both.
Readers who want to better understand the differences between these two defense modes can use the following table:
Improvements in Version 2.0
There are many improvements and new features in version 2.0. These include:
- RPCFW Configuration supports both RPC Firewall and RPC Filters
- RPC Firewall installation is persistent via a Windows service
- Protecting newly created RPC servers
- Detailed status reporting
- Improved source host and port resolution
Creating RPC Firewall Policies
Firewall rules should always be prefixed with a “fw:” in the configuration file. Other than that, firewall rules are the same as they were in the previous version with the addition of a new “prot:” filter, which can be used to filter specific RPC protocols detailed here.
To apply these rules to processes, first the RPC Firewall needs to be installed and then started:
RpcFwManager.exe /install fw
RpcFwManager.exe /start fw
This will persist the RPC Firewall configuration across reboots and will also monitor for newly created RPC servers to apply these policies to them.
To stop the RPC Firewall from protecting existing or newly create RPC services, simply issue the following command:
RpcFwManager.exe /stop fw
Creating RPC Filtering Policies
RPC Filter rules should be prefixed with “flt:”. They support the following parameters:
- uuid: which UUID this rule applies to (same as for RPC Firewall)
- action: should this call be allowed or blocked (same as for RPC Firewall)
- prot: same as for RPC Firewall
- audit: should this call be audited in the security event log #5712
- sid: a security identifier of the entity making the RPC call (can be for a user, a group, or a well-known SID)
Similarly to the RPC Firewall, the RPC filters first need to be installed and then started:
RpcFwManager.exe /install flt
RpcFwManager.exe /start flt
This creates a special filtering provider that associates all filtering rules with our own custom provider. This ensures that the generated filters can be easily tracked and won’t affect other RPC filters created via other means.
To stop the protection of the filters, simply issue the following command:
RpcFwManager.exe /stop flt
Identifying the Remote RPC Source Host
When an RPC connection is made, an internal object of the RPC runtime, called OSF_SCALL, is used to try and retrieve the source host address and port. This is done via a call to an internal function in the object called TCP_QueryClientIpAddress. This function does not exist for OSF_SCALL objects created for named pipe communication. Therefore, when auditing and filtering RPC calls over named pipes, the source port and address are always 0:
The RPC Firewall can retrieve the remote IP address of RPC calls over named pipes using the RpcBindingServerFromClient function, which eventually calls an internal function with the indicative name: NMP_ConnectionQueryClientAddress.
Using this mechanism, the RPC Firewall can identify the remote host over RPC calls made over named pipes:
Checking the Status
Another important new feature which was added to this version allows users to check the deployment status of their RPC protections. This is a good command to run before making any changes to the deployment state. Status is printed once the “/status” parameter is used.
As seen above, detailed deployment information is printed for both the RPC Firewall and the RPC Filters.
Let’s Get Started
Want to get started? For more details, downloads, and installation guides, please take a look at our git repository.