Using RPC Filters to Protect Against Coercion Attacks

Author

Isaac Trzeb
February 25, 2025

Table of Contents

Coercion attacks have been around for a long time. They allow an unauthenticated attacker with network access to cause the vulnerable host to send an authentication request to an arbitrary host of the attackers choosing. This is often chained with other vulnerabilities in the environment.

I almost didn’t want to write on this subject since it already has significant coverage, however, even with so much coverage, I seldom have a client that has already remediated let alone successfully alerts on coercion attacks. After sitting down and implementing and testing remediations myself, I can see why. There isn’t exactly a simple out of the box fix without its considerable downsides.

Additionally, focus is often on remediating a portion of the chained attack and that’s usually ADCS or NTLMv1 Downgrading, both of which are important and do reduce the risk of Coercion attacks like PetitPotam but what happens when other attack chains are discovered. That never happens in our industry :). To add to the reasoning, when looking up remediation for coercion attacks, you often end up looking at EPA or the KB5005413 page talking about mitigating NTLM Relay to AD CS.

The goal of the post is to hopefully help reduce the friction to remediating common coercion vulnerabilities and shed some light on detections using built in functionality.

For context, here is an example attack path.

I have been using coercion attacks on engagements for the last 5 years. In more environments than not, this results in an attack chain that allows me to elevate my privileges from either unauthenticated or a low privilege user directly to Domain Administrator. In several cases I return to test a client a year later and although they may have remediated misconfigurations in ADCS or NTLMv1 support, coercion vulnerabilities often remain. So I decided to try and help reduce the friction to remediation with a little PowerShell script.

Script -help

Now I know this isn't the most elaborate tool or cool leet thing, but I think it helps streamline a step of the remediation process. RPC filters are built into Windows and although they lack a lot a features, they do get the job done. Even if this helps someone out there remediate some of these attacks, I’ll consider it a win.  

Currently, here are the well-known vulnerabilities / endpoints that are commonly abused with off the shelf tooling.

12345678-1234-abcd-ef00-0123456789ab (MS-RPRN - Printer Bug)
c681d488-d850-11d0-8c52-00c04fd90f7e (MS-EFSRPC - Petitpotam)
df1941c5-fe89-4e79-bf10-463657acf44d (MS-EFSRPC - Petitpotam)
a8e0653c-2744-4389-a61d-7373df8b2292 (MS-FSRVP - Shadow Coerce)
4fc742e0-4a10-11cf-8273-00aa004ae673 (MS-DFSNM  - DFS Coerce)
82273fdc-e32a-18c3-3f78-827929dc23ea (MS-EVEN - Cheese Ounce)

Not all the above are remediated in the same means. And it should be obvious, but any remediation should be tested and validated before implementation in production. Let’s dig a little deeper into each one.

Printer Bug 

Microsoft’s print spooler service exposes an RPC service that allows low privilege users to call the RpcRemoteFindFirstPrinterChangeNotification(Ex) functions. This function can be supplied with an IP address in the pszLocalMachine field to initiate a call back.  

Remediation for this vulnerability should start with evaluating where you need the print server spooler service running. In most cases I have come across, clients do not need their Domain Controllers running as a print server.  

In my limited testing, an RPC filter did not prove to work against this specific endpoint. RPC access was denied but some tools failed, and others continued to initiate a successful call back. I may research this further but at this point I would not leverage an RPC filter to block Printer Bug as it can be bypassed.

Event Generated

PetitPotam

“The Encrypting File System Remote (EFSRPC) Protocol is used for performing maintenance and management operations on encrypted data that is stored remotely and accessed over a network.” - Microsoft

This RPC endpoint has multiple functions that allow a user to cause coercion. A single method EfsRpcOpenFileRaw was abusable from an unauthenticated perspective. This has been patched by Microsoft. However, six additional methods are still abusable by an authenticated user.  

Example of Event ID Generated from Activity

In order to block these end points you can use the provided PowerShell script. To block these endpoints use the -b and -i followed by MS-EFSRPC-1 and -2. 

PS> .\Coercion-Protection.ps1 -b -i MS-EFSRPC-1

Blocking interface:
    - MS-EFSRPC-1 (PetitPotam)
    - UUID: c681d488-d850-11d0-8c52-00c04fd90f7e

Successfully blocked RPC interface(s).


PS> .\Coercion-Protection.ps1 -b -i MS-EFSRPC-2

Blocking interface:
    - MS-EFSRPC-2 (PetitPotam)
    - UUID: df1941c5-fe89-4e79-bf10-463657acf44d

Successfully blocked RPC interface(s).

Shadow Coerce

“used for creating shadow copies of file shares on a remote computer, and for facilitating backup applications in performing application-consistent backup and restore of data on SMB2 shares.” - Microsoft

More specifically this endpoint is exposed when the “File Server VSS Agent Service” role is added. I do not recommend using an RPC filter to solve this problem as the good ole ensure your machine is updated remediation will work since Microsoft has issued a patch that addressed this vulnerability. KB5015527 I rarely come across this, however it does still happen.  

DFS Coerce

An RPC service, MS-DFSNM, implemented for managing DFS (Distributed File System). The specific methods called are NetrDfsRemoveStdRoot and NetrDfsAddStdRoot.

This attack can also be blocked similar to the PetitPotam endpoints. 

PS> .\Coercion-Protection.ps1 -b -i MS-DFSNM

Blocking interface:
    - MS-DFSNM (DFS Coerce)
    - UUID: 4fc742e0-4a10-11cf-8273-00aa004ae673

Successfully blocked RPC interface(s).

Attack Failing Due to RPC UUID Being Blocked

Event Generated Regardless of Block in Place

Cheese Ounce

This attack was one of the last to be discovered. MS-EVEN and more specifically the function ElfrOpenBELW allows you to supply an endpoint in the BackupFileName parameter. This is exposed when you enable Remove Event Log Management in the firewall.

Features Exposing MS-EVEN

Example of Attack

Generated Event During Attack

Again, simply supply -b -i MS-EVEN and this attack will be blocked. 

PS> .\Coercion-Protection.ps1 -b -i MS-EVEN

Blocking interface:
    - MS-EVEN (Cheese Ounce)
    - UUID: 82273fdc-e32a-18c3-3f78-827929dc23ea

Successfully blocked RPC interface(s).

Event IDs Worth Noting

My experience with trying to successfully detect this activity was eye opening to say the least. Event IDs generated appear to be lacking and unfortunately more useful Event IDs would only be generated under specific conditions.  

5712 - A Remote Procedure Call (RPC) was attempted.

That is a great start…. When manually creating RPC filters, documentation states that the audit flag may only be applied to rules with the action set to permit. That helps us if you know you can't block an endpoint, but ideally, I would like to block the end point and also alert when someone tries to access the UUID. Bummer. 

Additionally, when testing a permit rule for each UUID in this article, only two successfully generated 5712 events.

  • MS-EVEN (82273fdc-e32a-18c3-3f78-827929dc23ea)

  • MS-EFSRPC (c681d488-d850-11d0-8c52-00c04fd90f7e)

5145 A network share object was checked to see whether client can be granted desired access.

This appeared to be the only other event ID that seemed to be consistently generated with the attacks. Additionally, it did successfully trigger regardless of it a RPC filter was in place.

PrinterBug Attack Generating a 5145 Event

Conclusion and TLDR

MS-FSRVP (DFSCoerce) and MS-PAR (Print Nightmare) should simply be patched through windows updates. Look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Name, netdfs.

MS-RPRN (Printer Bug), don’t use your DCs as a print server and use an RPC filter at your discretion as this was bypassed during testing. Look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Name, spoolss.

MS-EFSRPC (PetitPotam) can be blocked using -b -i MS-EFSRPC1 and -b -i MS-EFSRPC2 After blocking, look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Names, lsarpc, efsrpc, samr, netlogon, and lsass.

MS-DFSNM (DFSCoerce) and MS-EVEN (CheeseOunce) can be blocked using the script or you can evaluate the option of removing and not exposing these services. Look for Event ID 5145. Consider alerting on low privilege users accessing the share name \*\IPC$ with the following Relative Target Name, eventlog.

References