RPC Firewall by Zero Networks

As a Cybersecurity Consultant on the blue side of the Cybersecurity spectrum, I know the importance of the security hardening of the IT network. My specialty is to secure Windows networks against adversaries. I mainly use Microsoft Defender products or products from WithSecure (formerly known as F-Secure). But, both of these products are not very strong in detecting RPC-based attacks. A significant portion of a Windows domain environment is Remote Procedure Call (RPC). It’s literally everywhere in the Windows operating system. An antivirus application can detect known malware, and an EDR solution can recognize attack patterns, but none of these protect the RPC from malicious activity. Indeed, even the best antivirus products have great difficulty securing RPC. This is where the RPC Firewall comes in…

The RPC Firewall by Zero Networks

RPC (Remote Procedure Call) is a cliet-server communication mechanism that allows a computer program to request a service from another program located on a different server. Protecting RPC calls is important because they can be exploited by attackers to gain unauthorized access to sensitive information or to launch further attacks on the system. Here is a short list of some attacks and tools that rely on Remote RPC:

• Remote Scheduled Task for lateral movement and RCE
• Remote Service Creation for lateral movement and RCE (used by PsExec.exe for example)
• Remote Registry Modification for lateral movement and RCE
• Remote WMI via WMIC.exe for lateral movement and RCE
• Remote DCOM for lateral movement and RCE
• SharpHound for internal reconnaissance
• CornerShot for internal reconnaissance
• PrintNightmare vulnerability which allows RCE
• ZeroLogon vulnerability which allows privilege elevation
• PetitPotam attack which can facilitate various relay attacks

To protect against these types of attacks, you can do the following:

• Implement proper authentication and authorization controls (least privilege access) to ensure that only authorized users are able to access the RPC services.
• Keep the operatingsystems and software applications up to date with the latest security patches to address any known vulnerabilities.
• Segment the network, to limit the potential attack surface of the system by isolating core components of a network in their own isolated environment.

But still, it’s hard to protect RPC calls going back and forth between servers within an isolated network. Especially when you’re in a Windows environment because RPC is literally everywhere in a Windows network! And, from this point I see the added value of the open-source RPC Firewall created by Sagie Dulce, VP Researcher of the Cybersecurity company Zero Networks.

Functionality of the RPC Firewall

The open-source RPC Firewall has two main functions:

• Detect Remote RPC Attacks
• Prevent Remote RPC Attacks

Detect Remote RPC Attacks

When the RPC Filters in the configuration are being set to audit, the events records to Event ID 5712 in de Security log of the Windows Event Log. RPC Firewall events has his own source in the Event Log on the location Applications and Services Logs -> RPCFW. This source wil be created upon the installation of the RPC Firewall.

Prevent Remote RPC Attacks

The RPC Filter and RPC Firewall rules cannot only be configured to audit RPC calls but also to Block mode, to block local or remote incoming RPC calls. It’s also possible to configure both the Audit & Block mode at the same time.

In the Block mode any malicous RPC calls are being blocked for execution. By logging the log sources from the Windows Event Log into your SIEM solution, such as Microsoft Sentinel, you can alert the SOC so they can immediately start an investigation into the incident.

Core Components of the RPC Firewall

The RPC Firewall consists of several components:

• RpcFwManager.exe - Acts as a standalone command line management tool for RPC Filters and Firewall deployment. It also acts as the installed service for deploying the RPC Firewall.
• RpcFirewall.dll - Injected DLL that performs the audit & filtering of RPC calls.
• RpcMessages.dll - A common library for sharing functions, and logic that writes data into Windows Event Viewer.

How does the RPC Firewall work?

For a detailed description of all the functionalities and parameters of the RPC Firewall, I refer you to the GitHub page of the RPC Firewall. The parameters listed below are the only parameters I needed.

• RpcFwManager.exe /install For the RPC Firewall, it configures the Event Log, drops relevant DLL files into the %SystemRoot%\System32 folder, and configures the RPCFW application log for the Event Viewer. It also installs the “RPC Firewall” service in the Windows Services used for persistence. For the RPC Filters, it’s enables the security audit of RPC events. These could be found under the Securit log, with event ID 5712.
• RpcFwManager.exe /start This command starts the RPC Firewall service and creates the RPC Filters. After the execution of this command, the configuration is loaded in the memory, and the RPC Firewall is actively protecting RPC.
• RpcFwManager.exe /uninstall This command removes the RPC Firewall.
• RpcFwManager.exe /status This command will show the status of the RPC Firewall and the RPC Filters. The output shows detailed information about the deployment status of the RPC Firewall.

It is essential to understand how the rules are applied in the configuration of the RPC Firewall. The RPC Firewall rules are being applied in a later stage. So, a block in the RPC Filter will not propagate later to the RPC Firewall rules. That means that the RPC Filter takes the presence over the RPC Firewall rules. Example, if you want to completely block a specific RPC UUID. Then it is recommended to configure it to block in the RPC Filter and not configure it explicitly in an RPC Firewall rule.

Another example, in the configuration snippet below the UUID f5cc59b4-4264-101a-8c59-08002b2f8426 will be blocked. Because, the last fw block rule will override the first flt allow rule. If we remove the fw rule the traffic will be allowed. If we want to allow the RPC traffic that’s using UUID f5cc59b4-4264-101a-8c59-08002b2f8426, it’s recommended to allow this explicitly in the RPC Filters and remove any existing of this UUID from the RPC Firewall rules.

The third example, in the configuration snippet below the UUID a8e0653c-2744-4389-a61d-7373df8b2292 is allowed, while this UUID is configured to block in the RPC Filters. Because, the RPC Firewall kicks in a later stage and allows the traffic.

RPC Filter rules
----------------------------------------------------------------------------------------
flt:action:block audit:true uuid:a8e0653c-2744-4389-a61d-7373df8b2292
flt:action:allow audit:true uuid:4fc742e0-4a10-11cf-8273-00aa004ae673
flt:action:allow audit:true uuid:51b836e8-484d-4d03-b0fc-22e265cb3f7b
flt:action:allow audit:true uuid:e1af8308-5d1f-11c9-91a4-08002b14a0fa
flt:action:allow audit:true uuid:50abc2a4-574d-40b3-9d66-ee4fd5fba076
flt:action:allow audit:true uuid:f5cc59b4-4264-101a-8c59-08002b2f8426

RPC Firewall rules
----------------------------------------------------------------------------------------
fw:action:allow audit:true uuid:a8e0653c-2744-4389-a61d-7373df8b2292
fw:action:allow audit:true uuid:4fc742e0-4a10-11cf-8273-00aa004ae673
fw:action:allow audit:true uuid:51b836e8-484d-4d03-b0fc-22e265cb3f7b
fw:action:allow audit:true uuid:e1af8308-5d1f-11c9-91a4-08002b14a0fa
fw:action:allow audit:true uuid:50abc2a4-574d-40b3-9d66-ee4fd5fba076
fw:action:block audit:true uuid:f5cc59b4-4264-101a-8c59-08002b2f8426


Default block:
-----------------------------------------------
fw:action:block audit:true

View the logs

RPC Filters

The logs from the RPC Filter are written to the Security log in the Event Viewer.

1. Open the Event Viewer (eventvwr).
2. Expand Windows Logs and select the Security log.
3. Filter the log on Event ID 5712.

RPC Filter log in Event Viewer

RPC Firewall

The logs from the RPC Firewall have their own log name in the Event Viewer.

1. Open the Event Viewer (eventvwr).
2. Expand Application and Services Logs and select the RPCFW log.

RPC Firewall log in Event Viewer

Implementing the RPC Firewall

Plan Of Approach

I used this approach when implementing the RPC Firewall. You can, of course, deviate from my approach. But you could use this approach as a starting point.

1. To prevent the AV/EDR from blocking the RPC Firewall process, I configured the files RpcFwManager.exe, RpcFirewall.dll, and RpcMessages.dll to be explicitly allowed through the Indicators in Microsoft Defender.
2. I first installed the RPC Firewall on the management servers used by the IT Administrators. These are usually not critical servers. At this step, I made particular care to become comfortable with how the RPC Firewall works.
3. When I got a little more comfortable with the RPC Firewall, I installed it on all Windows Servers in Audit mode to get more insight into which RPC calls are being used on the servers.
4. I led the RPC Firewall in auditing mode on the Windows Servers for 1 month.
5. I started with configuring the RPC Firewall in the ‘Protected’ mode in the following sequence:
   1. Domain Controllers
   2. Print Servers
   3. Database Servers
   4. Application Servers
   5. Other Servers

Domain Controllers

If you have configured the LSASS process as a protected process on your Domain Controllers, the RPC Firewall cannot protect your DC against DCsync attacks. The DCsync magic happens in the LSASS process. As this process is running in protected mode, the RpcFwManager.exe cannot read this process anymore.

DCsync protection

The configuration snippet below protect a Domain Controller from a DCSync attack using the RPC Firewall. It does so by enabling the “dangerous” opnum 3 DRSGetNCChanges of the MS-DRSR UUID only from other Domain Controllers.

fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:<dc_addr1> opnum:3 action:allow
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:<dc_addr2> opnum:3 action:allow
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 opnum:3 action:block

Some core components of the Domain Controller functionality rely on RPC. After configuring the RPC Firewall in protected mode make sure to test the functionalities below:

• Are the Domain Controllers still in sync with eachother? (The result of the command repadmin /status must not contain errors)
• Is the Active Directory Users and Computers still working?
• Can you make modifications to the Active Directory without receiving RPC errors?
• Can you still open the DNS Management Console?
• Can you still open the Group Policy Management Console?

Management Servers

DNS Management Console

The IT Administrators never have log into the Domain Controllers (You did implement the least privilege model, right?) and manage the Active Directory, DNS/DHCP management, and GPOs from the Management Servers.

To allow the DNS Management Console to connect from the Management Servers to the DNS Server on the Domain Controllers you have to add the following RPC UUID to RPC configuration on the Domain Controllers:

fw:uuid:50abc2a4-574d-40b3-9d66-ee4fd5fba076 addr:<mgmt_addr1>> action:allow audit:true

To allow the DHCP Management Console to connect from the Management Servers to the DNS Server on the Domain Controllers you have to add the following RPC UUID to RPC configuration on the Domain Controllers:

fw:uuid:5b821720-f63b-11d0-aad2-00c04fc324db addr:<mgmt_addr1> action:allow audit:true
fw:uuid:6bffd098-a112-3610-9833-46c3f874532d addr:<mgmt_addr1> action:allow audit:true

If you have multiple management servers running in your network, you can duplicate the rule and add the IP address of the second management server, duplicate it again for the third management server, and so on.

Microsoft Sentinel

Note that Microsoft charge you for ingesting security logging to your Log Analytics Workspace. To keep the logging minimal, it is recommended to send only the logging of RPC traffic to Sentinel which the Analytic Rules are looking at.

A major advantage of the RPC Firewall is that the logging is stored in the Event Viewer which in turn can be sent to Microsoft Sentinel (or any other SIEM solution). Analytic rules can then be configured in Microsoft Sentinel to alert the SOC when specific RPC traffic is detected.

There are various Sigma rules you can implement in your SIEM solution that uses the logging from the RPC Firewall to inform your SOC team.

References

• How RPC works?
• RPC Firewall on GitHub
• Stopping Lateral Movement via the RPC Firewall