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.
The open-source RPC Firewall has two main functions:
- Detect Remote RPC Attacks
- Prevent 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.
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.
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.
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 /installFor the RPC Firewall, it configures the Event Log, drops relevant DLL files into the
%SystemRoot%\System32folder, and configures the
RPCFWapplication 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
RpcFwManager.exe /startThis 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 /uninstallThis command removes the RPC Firewall.
RpcFwManager.exe /statusThis 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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 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
The logs from the RPC Filter are written to the
Security log in the Event Viewer.
- Open the Event Viewer (eventvwr).
Windows Logsand select the
- Filter the log on Event ID
The logs from the RPC Firewall have their own log name in the Event Viewer.
- Open the Event Viewer (eventvwr).
Application and Services Logsand select the
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.
- To prevent the AV/EDR from blocking the RPC Firewall process, I configured the files
RpcMessages.dllto be explicitly allowed through the
Indicatorsin Microsoft Defender.
- 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.
- When I got a little more comfortable with the RPC Firewall, I installed it on all Windows Servers in
Auditmode to get more insight into which RPC calls are being used on the servers.
- I led the RPC Firewall in auditing mode on the Windows Servers for 1 month.
- I started with configuring the RPC Firewall in the ‘Protected’ mode in the following sequence:
- Domain Controllers
- Print Servers
- Database Servers
- Application Servers
- Other Servers
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.
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.
1 2 3 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 /statusmust 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?
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:
1 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:
1 2 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.
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.