PhantomRPC: Windows Has a Privilege Escalation Problem Microsoft Won't Fix

Last week at Black Hat Asia in Singapore, a Kaspersky researcher publicly demonstrated PhantomRPC: five separate ways to take any standard Windows service account straight to full SYSTEM access, confirmed working on fully patched Windows Server 2022 and Windows Server 2025. Microsoft already knew. They received the ten-page technical report months ago, called it moderate severity, assigned no CVE, and closed the case. There is no patch.

RPC stands for Remote Procedure Call, and it is the system that Windows services use to send requests to each other directly in the background. When one service needs something from another, it sends a request through RPC. This happens constantly, hundreds of times per minute, completely invisible to whoever is sitting at the machine.

The problem is what happens when a service sends a request to another service that is disabled or offline. A core Windows library called rpcrt4.dll handles all RPC communication, and that library does not verify whether whoever responds to that request is actually the legitimate service, so if an attacker has already set up a fake server at that empty endpoint, the connection goes straight to them instead.

Then they use a Windows feature called RpcImpersonateClient, which lets a server process temporarily take on the identity of whoever called it, so if the caller was running as SYSTEM, the highest privilege level on any Windows machine, the attacker walks away with complete control over the entire system.

This is not a bug in one piece of code that gets fixed by patching a single file. The flaw is in the design of how rpcrt4.dll handles connections to unavailable servers, which means every version of Windows that uses this library carries it. And since RPC is woven into the operating system at a fundamental level, it has been there from the beginning.

Haidar Kabibo, an application security specialist at Kaspersky, found this while researching how Windows services communicate through RPC internally. The first attack scenario he identified was purely theoretical at that point. He had a hunch that the RPC runtime would not verify the legitimacy of a responding server if the original target was unavailable, but he had not tested it yet. So he built a fake RPC server, positioned it at the endpoint, and triggered the call. Windows allowed the fake server to register without any issue, the connection came in, the impersonation worked, and he escalated straight to SYSTEM on the first attempt, because the flaw is not in a specific implementation but in the design itself, and that design behaves the same way across every Windows version that runs RPC.

What I love about this kind of research is that the question was not complicated. He just wondered whether Windows actually checks who answers when the intended server is offline. Nobody had formally asked that before, and the answer was no.

Kabibo mapped out five concrete exploitation paths, each one abusing a different Windows process as the unwitting caller.

• → gpupdate.exe and Group Policy: Running gpupdate /force causes the Group Policy Client service to make an RPC call to Terminal Services. The Group Policy Client service runs as SYSTEM. Terminal Services itself runs as Network Service and is disabled by default on many systems. If an attacker sets up a fake server at that endpoint, the Group Policy Client sends its SYSTEM-level call straight there, and the attacker catches it.
• → Microsoft Edge at startup: When Edge launches, it automatically makes an RPC call to Terminal Services with a high impersonation level. No coercion required, no social engineering, nothing unusual. The browser opens and makes the call on its own. An attacker running as Network Service catches it and moves up to Administrator.
• → The WDI background service, and this one just waits: The Windows Diagnostic Infrastructure System Host runs as SYSTEM and polls Terminal Services automatically every five to fifteen minutes with zero user interaction. The attacker sets the fake server up and does nothing. Windows delivers the privileged call on its own schedule.
• → ipconfig.exe and DHCP Client: Running ipconfig triggers an internal RPC call to the DHCP Client service. Disable DHCP Client, put a fake server in its place, and a Local Service account escalates to Administrator.
• → w32tm.exe and Windows Time: The Windows Time executable first looks for a named pipe called \PIPE\W32TIME. An attacker can expose that endpoint without touching the legitimate Windows Time service at all, which makes this path particularly quiet.

Terminal Services showing up in three of those five paths is not a coincidence. During the research, Kabibo found that many Windows services internally try to reach TermService through RPC, and most of those calls originate from a Windows library called winsta.dll, which acts as the RPC client that dozens of system processes use to communicate with Terminal Services. That means the actual number of processes that could trigger a PhantomRPC escalation through that endpoint is much larger than the three documented paths suggest.

All five were tested and confirmed working on Windows Server 2022 and Windows Server 2025 with every available update applied at the time of submission. The researchers stated that other Windows versions are almost certainly affected as well, because the weakness is in the architecture and not tied to a specific release.

The full report was submitted to Microsoft’s Security Response Center back in September 2025 as Case 101749, and when Microsoft responded twenty days later their reasoning for not patching was that the attack requires a privilege called SeImpersonatePrivilege, which the attacker would already need to have.

SeImpersonatePrivilege is a Windows permission that lets a process temporarily act on behalf of another account. Certain services need this to do their job, like a service that handles work on behalf of whoever is connecting to it. Windows grants this permission by default to Network Service and Local Service, the accounts that IIS, SQL Server, and most web-facing Windows services run under.

That is where Microsoft’s reasoning falls apart. Any attacker who lands a webshell on a standard IIS server starts as Network Service, and Network Service has SeImpersonatePrivilege by default, so saying the attacker already has the prerequisite does not make this less serious. It means PhantomRPC works on the most common Windows service account in corporate environments, right out of the box.

Microsoft assigned no CVE and closed the case without scheduling a fix.

Picture a standard corporate web server running IIS, which is Microsoft’s built-in web server software and the backbone of a huge number of business applications. IIS runs under an account called Network Service by default, and Network Service has SeImpersonatePrivilege enabled by default. An attacker who finds a vulnerability in the web application and gets code execution on that server lands as Network Service. They run whoami /priv, see SeImpersonatePrivilege is Enabled, deploy a fake RPC server at the TermService endpoint, and wait. Within fifteen minutes, the Windows Diagnostic Infrastructure System Host automatically polls that endpoint as part of its normal background routine, the fake server catches the call, runs RpcImpersonateClient, and the attacker is operating as SYSTEM with nothing more than a fake server and patience.

People familiar with Windows privilege escalation will recognize the family this belongs to: RottenPotato, JuicyPotato, SweetPotato, GodPotato. Every one of them uses SeImpersonatePrivilege and tricks a SYSTEM service into authenticating to a fake endpoint, and while the core idea is the same, where PhantomRPC differs is the communication channel it uses to get there.

Potato exploits work through COM, the Component Object Model, which is a separate mechanism Windows uses for inter-process communication. Microsoft hardened against JuicyPotato in Windows 10 version 1809 and Windows Server 2019 by closing the specific COM pathways those exploits relied on, which made the whole Potato family much harder to pull off on modern systems.

PhantomRPC does not use COM at all, it works directly through RPC, which means the mitigations Microsoft put in place against the Potato family do not apply here, and on a fully patched Windows Server 2025 with every Potato mitigation already in place, PhantomRPC still works. Kabibo wrote in the research paper that the attack vectors are architecturally unlimited, meaning every piece of software that introduces a new RPC-dependent service is a potential new escalation path that nobody has found yet. The five paths presented at Black Hat Asia are a starting point, not a complete list. Kabibo published proof-of-concept code for security researchers alongside the research, with the note that detailed instructions enabling mass exploitation were deliberately left out.

The first thing worth checking is whether SeImpersonatePrivilege is active on the accounts running services on your systems. On any account running system services, it almost certainly is, but running this confirms it:

1

whoami /priv

Look for SeImpersonatePrivilege in the output. If it shows as Enabled, that account has the privilege PhantomRPC needs to work.

To detect RPC calls going to unavailable servers, Windows has a built-in tracing tool that needs nothing external installed:

1
2

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

That produces an ETL file. To actually read it, convert it to JSON first using Microsoft’s own Etw2Json tool:

1

Etw2Json.exe "PhantomRPC_Check.etl" --output="PhantomRPC_Check.json"

Then run the Python enricher from Kabibo’s research repository against the JSON output to filter and map the relevant events:

1

python enricher.py "PhantomRPC_Check.json"

Look for Event ID 1 from the RPC provider combined with high impersonation levels from privileged system processes. That combination is the signature of a PhantomRPC-style call going to an empty endpoint.

There is no patch and no CVE coming through Windows Update, so these are the steps that actually reduce the risk.

• → Keep services like Terminal Services and DHCP Client running and active on systems where they belong. An attacker needs an empty endpoint to put a fake server on, so keeping the legitimate service running blocks that opening.
• → Monitor ETW output for Event ID 1 from the RPC provider combined with high impersonation levels from privileged processes like the svchost.exe instance running Group Policy Client or WdiSystemHost. That combination means something is calling an empty endpoint with high privileges, which is exactly what a PhantomRPC attack looks like.
• → Go through which accounts and processes on your systems actually need SeImpersonatePrivilege and remove it from anything that does not strictly require it. The more accounts have it without a good reason, the more potential starting points an attacker has.
• → On systems running IIS or similar service accounts that have SeImpersonatePrivilege by default, assume that any code execution on those accounts is one waiting step away from SYSTEM and set up monitoring accordingly.

Kabibo presented all of this last week at Black Hat Asia, and the proof-of-concept code has been public ever since.

PhantomRPC has been in Windows since RPC was first built into the operating system. Nobody looked for it until now. The five paths Kabibo documented are the ones a single researcher found during one research project. The RPC stack in Windows is enormous, with hundreds of interfaces, thousands of registered endpoints, and decades of services built on top of it. If one researcher found five working escalation paths by asking a question nobody had asked before, the question worth sitting with is how many more are still in there, in software that processes use every day, waiting for someone to ask the same kind of question next time.

The concepts behind what Kabibo found, privilege escalation, moving from a basic service account to full SYSTEM access, post-exploitation, and understanding how Windows handles authentication internally, are exactly what my ethical hacking course covers step by step:

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: Haidar Kabibo — Disclosing PhantomRPC · PhantomRPC — GitHub