When Legitimate Windows Functions Become Attack Tools

In Part 1, we looked at how RPC works, the different interfaces Windows exposes, and why so much of Windows administration depends on it.

Now let’s look at what happens when those same interfaces are used by someone who shouldn’t be using them.

The interesting thing about RPC attacks is that they don’t always require a vulnerability. Sometimes the attacker is simply asking Windows to do something it was designed to do. Create a service, install a printer driver, authenticate to another machine. All perfectly legitimate operations under the right circumstances.

Surprise surprise, attackers aren’t particularly concerned with the right circumstances.

We’re going to look at PsExec-style remote execution, PetitPotam, and two attacks involving the Windows Print Spooler: PrinterBug and PrintNightmare. We’ll also look at what they leave behind in Windows logs and how filtering RPC can help prevent them.

Attack 1: Remote Execution with PsExec

If you’ve administered Windows machines for any length of time, you’ve probably used PsExec. It’s part of Microsoft’s Sysinternals suite and allows you to execute commands on remote systems.

It’s also something attackers have been using for years.

PsExec-style execution relies on the Service Control Manager Remote Protocol (MS-SCMR).

Remember the \pipe\svcctl named pipe from Part 1? That’s one of the ways Windows exposes this functionality.

With appropriate administrative credentials, a remote client can connect to the Service Control Manager, create a service, and start it.

Two RPC methods are particularly important here:

• RCreateServiceW creates the service.
• RStartServiceW starts it.

A typical PsExec-style tool copies an executable to the target, registers it as a service, and starts it. Depending on how the service is configured, the resulting process may run as NT AUTHORITY\SYSTEM.

For our example, imagine an attacker has obtained administrative credentials and wants to execute commands on FS01 at 10.0.0.30.

An example might look something like this:

[*] Connecting to 10.0.0.30
[*] Found writable ADMIN$ share
[*] Connecting to \pipe\svcctl
[*] Creating remote service
[*] Starting remote service
[*] Remote shell established

C:\Windows\system32> whoami
nt authority\system

Nothing particularly exotic happened. Windows accepted the credentials, allowed the service to be created, and started it.

The attacker just happened to be the administrator this time.

What Shows Up in the Logs?

Windows provides some useful evidence when this happens.

The first thing I’d look for is Event ID 7045 in the System log. This records when a new Windows service is installed, including the service name, executable path and account.

A service appearing unexpectedly on a file server deserves some attention, particularly when its executable lives in an unusual location.

You can check recent service installations with PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 7045
} -MaxEvents 20

I’d also look for Security Event ID 4624 with Logon Type 3, which indicates a network logon. It can help identify the account and source machine involved.

Security Event ID 5145 can provide additional information about access to SMB resources, including named pipes, when Detailed File Share auditing is enabled.

None of these events alone proves an attack occurred. Administrators install services remotely all the time.

But a service appearing on FS01 immediately after a network logon from an unfamiliar workstation is certainly worth investigating.

How Do We Stop It?

The SCMR interface has a UUID of:

367abb81-9844-35f1-ad32-98f038001003

Rather than allowing every workstation to reach this interface, we can restrict remote service management to approved administrative systems.

Even if an attacker has administrative credentials, they still need a way to communicate with the service.

And that’s where RPC filtering becomes useful.

Attack 2: PetitPotam and Forced Authentication

PetitPotam is a different kind of attack.

Instead of executing commands directly on the target, the attacker tries to make the target authenticate to another machine.

This is known as an authentication coercion attack.

The technique abuses functionality exposed through the Encrypting File System Remote Protocol (MS-EFSR).

One of its methods, EfsRpcOpenFileRaw, accepts a file path. Under certain conditions, supplying a network path can cause the target to attempt to access a remote system.

Imagine an attacker can reach the EFSRPC interface on DC01.

They supply a path pointing to their own machine at 10.0.0.99.

Instead of simply rejecting the request, a vulnerable configuration may cause the domain controller to initiate an outbound authentication attempt.

An example might look something like this:

Attacker: 10.0.0.99
Target:   DC01 / 10.0.0.10

[*] Connecting to EFSRPC interface
[*] Requesting remote file access
[*] Target attempting outbound authentication

Listener:
[*] Incoming SMB connection from 10.0.0.10
[*] NTLM authentication observed: DC01$

Notice what happened. The attacker didn’t necessarily need to compromise an administrator account on the domain controller.

They convinced the domain controller to authenticate somewhere it shouldn’t.

That’s an important distinction.

The attacker doesn’t receive the computer account’s plaintext password. What they may obtain is an NTLM authentication exchange that could potentially be relayed to another service.

One of the more concerning historical scenarios involved relaying that authentication to Active Directory Certificate Services (AD CS), particularly when vulnerable certificate enrollment endpoints were available.

Microsoft published KB5005413 specifically addressing NTLM relay attacks against AD CS.

The coercion by itself doesn’t mean the domain is compromised. The attacker still needs a suitable destination and conditions that allow the authentication to be abused.

What Shows Up in the Logs?

This one can be harder to identify from standard Windows event logs.

The most interesting activity may actually be the outbound authentication rather than the initial RPC request.

If a domain controller suddenly initiates SMB or NTLM authentication to an unfamiliar workstation, I’d want to know why.

With the appropriate auditing enabled, Security Event ID 5145 may show access to named pipes such as lsarpc or efsrpc, but it won’t tell you which EFSRPC method was called.

That’s the limitation of relying on normal SMB and Windows authentication logs. You might see the connection without seeing the RPC operation responsible for it.

How Do We Stop It?

EFSRPC is associated with interface UUIDs including:

c681d488-d850-11d0-8c52-00c04fd90f7e
df1941c5-fe89-4e79-bf10-463657acf44d

If a system doesn’t need to provide remote EFS functionality, blocking access to these interfaces can remove that attack path.

We should also address the authentication side by following Microsoft’s guidance for NTLM relay protection, particularly for AD CS.

Blocking one coercion technique doesn’t automatically prevent every other way an attacker might force authentication.

Attack 3: PrinterBug and PrintNightmare

The Windows Print Spooler has had its share of security problems.

Two examples are PrinterBug and PrintNightmare. They involve the same general area of Windows functionality but accomplish different things.

Both are associated with the Print System Remote Protocol (MS-RPRN), commonly accessible over \pipe\spoolss.

PrinterBug

PrinterBug is another authentication coercion technique.

It abuses a printer notification function called RpcRemoteFindFirstPrinterChangeNotificationEx.

Normally, this functionality allows a system to receive notifications about changes to printers or print jobs.

Unfortunately, it can also be used to make a target initiate a connection to another host.

Sound familiar?

It’s a similar concept to PetitPotam, except we’re using the Print Spooler instead of EFSRPC.

The goal is to get the target to authenticate outward, potentially giving the attacker an opportunity to relay that authentication.

PrintNightmare

PrintNightmare is a different problem.

The vulnerabilities publicly disclosed in 2021 involved Windows Print Spooler functionality that could allow remote code execution or privilege escalation under vulnerable conditions.

One relevant RPC method is RpcAddPrinterDriverEx.

As the name suggests, it allows printer drivers to be installed on a print server.

That sounds harmless enough until you remember that a printer driver can contain executable code.

Under vulnerable configurations, an attacker could abuse driver installation to execute code with elevated privileges, potentially as SYSTEM.

Modern patched Windows installations have additional restrictions on printer driver installation. PrintNightmare shouldn’t be treated as a universal privilege-escalation method against fully updated systems.

Still, it’s a good example of how a legitimate administrative function can become an attack path when permissions or validation aren’t handled properly.

What Should We Look For?

For PrinterBug, I’d investigate unusual outbound authentication from systems running the Print Spooler.

For suspicious driver installations, the Microsoft-Windows-PrintService/Admin and Microsoft-Windows-PrintService/Operational logs are useful places to start.

Unexpected printer driver installation activity, especially involving unfamiliar files or remote paths, deserves investigation.

You can also check whether the Print Spooler is running:

Get-Service -Name Spooler

On a domain controller or server that has absolutely no reason to provide printing services, I’d question why it’s running in the first place.

How Do We Stop It?

The MS-RPRN interface UUID is:

12345678-1234-abcd-ef00-0123456789ab

We can restrict which machines are allowed to communicate with that interface.

However, RPC filtering shouldn’t replace Microsoft’s Print Spooler security updates or driver-installation restrictions.

For systems that don’t require printing, disabling the Print Spooler is generally the simpler solution.

For systems that do, restrict remote access, keep them patched and enforce appropriate printer driver installation policies.

Filtering RPC Instead of Just Blocking Ports

Now we get to the part I find particularly interesting.

All these attacks involve RPC interfaces, but traditional network filtering generally focuses on IP addresses and ports.

TCP 445 is a good example.

You may allow workstations to connect to a file server because they need access to shared folders.

But SMB can also transport RPC over named pipes.

That doesn’t mean every workstation can automatically execute remote administrative functions. Windows permissions still apply.

It does mean that allowing SMB doesn’t necessarily distinguish ordinary file access from RPC-based remote administration.

There are a couple of ways to address that.

Windows Built-in RPC Filtering

Windows has its own RPC filtering functionality, accessible through netsh rpc filter.

It can filter RPC communication based on interface UUIDs and other supported conditions.

For example, the following commands demonstrate a rule that blocks the SCMR interface:

netsh rpc filter add rule layer=um actiontype=block
netsh rpc filter add condition field=if_uuid matchtype=equal data=367abb81-9844-35f1-ad32-98f038001003
netsh rpc filter add filter

Don’t run that blindly on a production server. Blocking SCMR can interfere with legitimate remote management, including some administrative tools.

There’s another limitation worth understanding.

Windows’ native RPC filters have limitations when identifying the original source IP for RPC transported over SMB named pipes. That makes source-based filtering more complicated than simply building an IP allowlist.

The built-in filtering engine is useful, but there are situations where we need more visibility and control.

Zero Networks RPC Firewall

Zero Networks maintains an open-source RPC Firewall project that provides more granular control over Windows RPC activity.

Unlike traditional filtering based only on an interface UUID, RPC Firewall can inspect individual RPC operations.

Each operation has an identifier called an opnum, which tells the RPC server which method the client wants to execute.

For example, MS-SCMR exposes multiple operations. Some query information about services, while others create, modify or start them.

Instead of blocking the entire interface, you may want to prevent specific operations while allowing others.

RPC Firewall supports rules using interface UUIDs, opnums, source addresses and security identifiers.

It can also log RPC activity to Windows Event Viewer, providing information that typically isn’t available through ordinary network or SMB logging.

This is particularly useful when you’re trying to understand which interfaces are actually being used on your network.

A host accessing TCP 445 isn’t especially interesting by itself.

A workstation calling a remote service-creation function on a server it has no reason to administer is a different story.

The project includes a management tool, RpcFwManager.exe, and configuration examples for both RPC Firewall and native Windows RPC filtering.

For example:

RpcFwManager.exe /status

This displays the current deployment status.

The project’s GitHub documentation covers installation, configuration and logging.

One thing I would strongly recommend is starting with auditing rather than blocking.

Windows uses RPC for an enormous amount of legitimate functionality. Start denying interfaces without understanding those dependencies and you’ll probably discover some of them the hard way.

Where Microsegmentation Fits In

RPC filtering gives us control over individual interfaces and, depending on the tool, individual operations.

Microsegmentation addresses a different part of the problem.

If a workstation has no reason to connect to a server over SMB, why allow the connection at all?

We can restrict connectivity between systems based on their actual application and administrative requirements.

For example, ordinary workstations may need SMB access to a file server, but they probably don’t need SMB access to every other workstation on the network.

Likewise, domain controllers need to communicate with each other for Active Directory replication, but that doesn’t mean every system should have unrestricted access to their RPC services.

There’s a meaningful difference between allowing the traffic an application needs and allowing every possible operation over that connection.

Ideally, we’d use microsegmentation to limit which systems can communicate, RPC filtering to control what they’re allowed to request, and the normal Windows security controls to determine whether those requests are authorized.

That’s a much better approach than assuming that an authenticated connection must be a legitimate one.