PhantomRPC: Architectural Flaw in Windows RPC Lets Any Service Account Reach SYSTEM, and Microsoft Will Not Patch It

Introduction

Kaspersky researcher Haidar Kabibo has disclosed PhantomRPC, an architectural weakness in the Windows Remote Procedure Call runtime that lets a low-privileged process impersonate a SYSTEM-level client and hijack its security context. The technique is not a single bug in a single component but a generic primitive that turns any local or service account holding SeImpersonatePrivilege into a candidate for SYSTEM. Microsoft was notified in September 2025, declined to issue a CVE, and closed the case as "moderate severity, by design" — meaning every supported Windows version remains exposed today.

What Happened

The Windows RPC runtime, implemented in rpcrt4.dll, lets one process invoke functions exposed by another. When a client tries to talk to an RPC server that is not currently running, the runtime does not strongly verify that whatever does answer is the legitimate endpoint. PhantomRPC weaponizes that gap: a low-privileged attacker can register a malicious RPC server on an interface that a higher-privileged process is about to call, wait for the privileged client to connect, and then call RpcImpersonateClient to assume the caller's token.

Kabibo demonstrated five distinct paths to SYSTEM:

  • Coercion via gpupdate.exe when a Group Policy is applied.
  • A startup-sequence path triggered by Microsoft Edge.
  • The Windows Diagnostic Infrastructure (WDI) service performing periodic RPC calls to the Terminal Service interface.
  • DHCP Client interactions driven by ipconfig.
  • The Windows Time service's named-pipe transport.

The catch is that the attacker needs SeImpersonatePrivilege to start. In practice that bar is low: it is held by IIS_IUSRS, by NETWORK SERVICE, by SQL Server service accounts, and by many third-party agents. From any of those contexts, PhantomRPC turns a lateral movement or web-shell foothold into full Domain-joinable SYSTEM, with no kernel exploit and no user interaction.

Microsoft's response, twenty days after the disclosure, was that the issue did not warrant immediate remediation because exploitation requires SeImpersonatePrivilege. No CVE was assigned, and no patch is in flight. Kabibo notes the underlying behavior is architectural, so closing it would require Microsoft to change how the RPC runtime validates server identity, not a one-line fix.

Why It Matters

The "Potato" exploit family — RottenPotato, JuicyPotato, RoguePotato, PrintSpoofer, and friends — has been the Windows pen-tester's go-to service-account-to-SYSTEM trick for years, and Microsoft has been chipping away at it endpoint by endpoint. PhantomRPC sidesteps that whack-a-mole entirely. It does not rely on a specific authentication coercion or a specific COM activation; any process that depends on RPC can become an escalation path, and new ones appear every time a third-party product registers an interface.

For defenders, this turns a lot of "low severity, you would already be on the box" findings into top-of-stack risks. Web shells in IIS, command execution in SQL Server xp_cmdshell, and any compromised service account with impersonation rights become functionally equivalent to local SYSTEM. Microsoft's "by design" stance also means standard patch hygiene will not save you — this has to be addressed through configuration, monitoring, and least privilege.

Who Is Affected

  • Every supported Windows desktop version, including Windows 10 21H2/22H2, Windows 11 23H2/24H2/25H2.
  • Every supported Windows Server release, including Server 2019, 2022, and 2025.
  • Any environment where service accounts hold SeImpersonatePrivilege, which is the default for IIS application pools, SQL Server, Exchange, and many third-party agents.
  • Multi-tenant Windows hosts (Citrix, RDS, jump boxes) where one tenant's compromised service can pivot to SYSTEM and from there to other tenants' sessions.

How to Protect Yourself

There is no patch, so the goal is to shrink the attack surface and detect abuse early.

Audit which accounts actually need impersonation rights, and revoke it everywhere else:

# enumerate principals holding SeImpersonatePrivilege on the local box
secedit /export /cfg C:\Windows\Temp\sec.cfg /quiet
Select-String -Path C:\Windows\Temp\sec.cfg -Pattern '^SeImpersonatePrivilege'
Remove-Item C:\Windows\Temp\sec.cfg

# domain-wide GPO inspection
Get-GPOReport -All -ReportType Xml | Select-String 'SeImpersonatePrivilege'

For service accounts you cannot strip the privilege from (IIS, SQL), make sure the legitimate RPC endpoint is actually running, so an attacker cannot squat on it. For example, the Terminal Services WDI path collapses if TermService is started:

Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService
Get-Service TermService | Select Status, StartType

Turn on ETW-based RPC monitoring and look for the smoking gun: a low-privileged process registering an RPC interface that a higher-privileged process then calls.

# subscribe to RPC ETW provider (Microsoft-Windows-RPC) and persist to an .etl
logman create trace rpc-watch -p "Microsoft-Windows-RPC" 0xffffffffffffffff 0xff -o C:\rpc-watch.etl -ets

# stop and convert later
logman stop rpc-watch -ets
tracerpt C:\rpc-watch.etl -o C:\rpc-watch.csv -of CSV

In your SIEM, alert on RPC_S_SERVER_UNAVAILABLE events from privileged processes immediately followed by RPC connections from non-privileged ones to the same interface UUID. That is the exact telltale pattern Kabibo's PoC produces.

If you run EDR with kernel-mode telemetry, build a rule that flags any non-system process calling RpcServerRegisterIf for well-known privileged interface UUIDs (the Securelist post lists them per scenario). And on multi-tenant hosts, run a periodic check that no unexpected user-owned process is hosting an RPC endpoint:

# list all RPC endpoints registered on the box and the owning PID
rpcdump.exe /s 127.0.0.1 /v | Select-String -Pattern 'ProcId|ObjUuid'
# cross-reference with running processes
Get-Process | Select Id, ProcessName, UserName, Path

Anything user-mode, owned by a non-system account, and exposing a UUID that matches a privileged service is worth investigating immediately.

Source