No Patch, No Coercion: Abusing Windows Diagnostic Infrastructure for Silent SYSTEM Escalation

What PhantomRPC is and why it matters

PhantomRPC is not a single bug in one service binary. It is a Windows RPC behavior issue that lets a low-privileged service account catch a privileged connection intended for an offline or disabled endpoint, then impersonate that caller and climb to SYSTEM.

That distinction matters because it changes the defense story. If the weakness sits in the RPC runtime and the service setup around it, there is no one service you can patch and move on from. In the tested cases, the issue still worked on fully updated Windows Server 2022 and Windows Server 2025.

The practical impact is simple: if an attacker already has code execution under a common service account such as Network Service or Local Service, PhantomRPC can turn that foothold into full machine control without memory corruption or user interaction.

How Windows ends up impersonating the wrong caller

Windows services talk to each other over RPC constantly. Most of that traffic is invisible, which is fine until the target service is unavailable and the client library keeps walking anyway.

The role of rpcrt4.dll when a target service is offline

The RPC runtime in rpcrt4.dll handles the connection logic. The research showed that when a service tries to reach an endpoint whose real server is missing, Windows can accept a malicious listener at that spot. The caller does not get a reliable “this is the real service” guarantee just because the endpoint name matches.

That is the crack in the design: the client expected a trusted service, but the runtime only cared that something answered.

Why RpcImpersonateClient turns a bad connection into SYSTEM

Once the fake server receives the inbound call, it can use RpcImpersonateClient to take on the caller's identity for a moment. If the caller is a SYSTEM service, the attacker inherits SYSTEM-level context.

This follows the same broad shape as the Potato family, but it is not the same channel. PhantomRPC goes through RPC directly, not COM, which is why COM hardening did not shut it down.

The five tested escalation paths

Kaspersky's researcher mapped five working paths, and each one is useful because it shows how ordinary background activity becomes an escalation trigger.

gpupdate.exe and Group Policy

Running gpupdate /force makes the Group Policy Client talk to Terminal Services. If Terminal Services is offline and a fake RPC server is waiting, the call lands on the attacker instead of the real service.

In testing, that route gave a direct path to SYSTEM.

Microsoft Edge startup

Edge makes an RPC call to Terminal Services during startup with a high impersonation level. No coercion is needed; the browser does this on its own.

That makes it a good example of why “no user interaction” does not mean “no attack surface.”

WDI polling Terminal Services

The Windows Diagnostic Infrastructure System Host is more interesting because it waits for the attacker. It polls Terminal Services every 5 to 15 minutes as part of normal background behavior.

If the endpoint is empty, the fake server just waits and wins when the next poll arrives.

ipconfig.exe and DHCP Client

ipconfig.exe can trigger an RPC call to the DHCP Client service. Disable DHCP Client, plant a fake server, and the call can be coerced into a privilege jump.

This is a good reminder that local admin tools can become escalation triggers when they trust service endpoints too much.

w32tm.exe and \PIPE\W32TIME

w32tm.exe first looks for the named pipe \\PIPE\\W32TIME. That makes this path unusually quiet, because the attacker does not need to race a legitimate service instance directly.

Pipe-based abuse is easy to overlook during incident response because it looks like normal local service plumbing.

Why Microsoft's “needs SeImpersonatePrivilege” argument does not help

Microsoft's response was that the attack requires SeImpersonatePrivilege, so the attacker would already need meaningful privilege. That is technically true and operationally weak.

Default service accounts already have the privilege

Network Service and Local Service commonly have SeImpersonatePrivilege by default. Those are not exotic footholds. They are normal service accounts used by IIS, SQL Server, and other web-facing software.

So yes, the prerequisite exists. That is exactly why this matters.

Why this affects IIS-style footholds in practice

If you land code execution in a standard IIS app pool, you often start as Network Service. From there, whoami /priv shows SeImpersonatePrivilege enabled, and the attacker is already in the right starting position.

That is the real-world problem: the exploit chain fits a common web-server compromise, not a rare lab-only configuration.

How PhantomRPC differs from the Potato family

The Potato exploits all abuse impersonation, but they rely on COM-specific paths that Microsoft has already hardened in newer releases.

COM hardening does not stop direct RPC abuse

PhantomRPC avoids those COM paths entirely. The abuse is in the RPC client/server behavior itself, so the usual Potato mitigations do not apply.

That is why the technique still worked on patched modern servers where the classic Potato tricks are much less reliable.

Why the design issue remains across Windows versions

Kabibo's report frames the issue as architectural. That is the right mental model. As long as Windows continues to use the same RPC runtime behavior for offline endpoints, new services can expose new escalation paths.

The five paths are not the ceiling. They are evidence that the search space is bigger than most teams assume.

What to check on a real Windows host

If you are auditing a host, start with the boring checks. They are the ones that matter.

Confirming SeImpersonatePrivilege

whoami /priv

Look for SeImpersonatePrivilege and verify whether it is enabled for the service account that owns the foothold.

If it is enabled, treat the account as a potential launch point for impersonation-based escalation.

Looking for suspicious RPC traces and empty endpoints

A lightweight trace can show whether privileged processes are making calls to RPC endpoints that are not answering as they should.

logman create trace "PhantomRPC_Check" -p "{6ad52b32-d609-4be9-ae07-ce8dae937e39}" 0xFFFFFFFFFFFFFFFF 4 -o "C:\PhantomRPC_Check.etl"
logman start "PhantomRPC_Check"

What you want to correlate is Event ID 1 from the RPC provider with high-privilege system processes and impersonation behavior. That combination is the shape of this problem.

Practical defenses when there is no patch

You cannot patch your way out of this today, so reduce the conditions that make the exploit work.

Keep core services running when they are meant to be active

Do not leave services like Terminal Services or DHCP Client disabled on hosts where they should normally be up. An empty endpoint is what makes the fake listener possible.

Reduce service-account exposure and privilege spread

Review which service accounts truly need SeImpersonatePrivilege. Remove it where you can, and do not let unnecessary service sprawl create extra stepping stones.

Monitor for fake RPC listeners and unusual impersonation patterns

Watch for privileged services making RPC calls to endpoints that should have been handled by a legitimate service instance. In practice, that means looking for odd pairings: a normal process, a missing endpoint, and elevated impersonation behavior.

On IIS-style systems, assume a webshell on Network Service is already close to SYSTEM and treat that account as a high-risk foothold.

Closing notes on impact and scope

PhantomRPC is a good reminder that Windows privilege boundaries are often enforced by design assumptions, not just by code patches. When the assumption is wrong, the result is ugly: standard service access becomes SYSTEM without a memory bug or a user click.

The immediate lesson is not “RPC is broken everywhere.” It is narrower and more useful: if a service account can impersonate and the target endpoint can disappear, you need to treat that path as an escalation surface.

That is the kind of issue that hides in plain sight for years.