PhantomRPC: The Unpatched Windows Privilege Escalation Microsoft Won’t Fix

Most Windows privilege-escalation stories end with a CVE and a patch. PhantomRPC, disclosed at Black Hat Asia last week by Kaspersky researcher Haidar Kabibo, ends differently: an architectural flaw in the Windows RPC runtime, five working exploitation paths, every supported version of Windows affected – and a Microsoft response that boils down to “moderate severity, no CVE, no fix scheduled”.

For anyone defending Windows endpoints, that combination is worth a closer look. Not because PhantomRPC is the most dangerous LPE this year – April’s 93 EoP fixes made that competition fierce – but because it is the kind of bug that quietly sits in your environment forever.

What PhantomRPC actually does

The flaw lives in rpcrt4.dll, the Windows RPC runtime that nearly every Microsoft service relies on. The mechanics are simple, which is part of what makes the response so striking:

1. A highly privileged process – a Windows service running as SYSTEM, for example – tries to make an RPC call to another service.
2. That target service is offline or disabled (either deliberately, by accident, or because no one ever started it).
3. The RPC runtime does not verify that the responding server is the legitimate one. Whoever has registered for that RPC endpoint first gets the call.
4. An attacker running as a low-privileged service account stands up a malicious RPC server impersonating the missing one.
5. When the privileged client connects, the malicious server calls RpcImpersonateClient and assumes the caller’s security context. Game over.

The end state is SYSTEM, from a starting point of any account that holds SeImpersonatePrivilege. That includes Network Service and Local Service by default – the security contexts that an enormous amount of compromised software runs under.

Why “moderate severity” understates the problem

Microsoft’s argument, as reported, is that the attack requires SeImpersonatePrivilege, which is held by service accounts by design. From a model-of-the-system perspective, that is technically true. From an operational perspective, it sidesteps a real risk:

• Service-context compromise is everyday work for attackers. Compromised IIS workers, vulnerable third-party services, exploited installers and malicious update payloads all routinely run as Network Service or Local Service. PhantomRPC turns that foothold into SYSTEM.
• The vulnerable surface is huge. Any disabled or unstarted RPC service is a potential phantom endpoint. The list of services that are commonly disabled in hardened environments – including TermService, several optional Windows services, and a long tail of third-party add-ons – is exactly where an attacker can plant their fake server.
• There are five exploitation paths, not one. Even if you close the obvious holes, the architectural shape of the flaw means new variants will keep appearing.
• It will not be fixed. No CVE, no patch, no Patch Tuesday line item. PhantomRPC is part of your environment until Microsoft changes its mind, and you should plan accordingly.

That last point is the one most worth dwelling on. Most Windows defenders are used to a rhythm of “disclosure, CVE, patch, move on”. PhantomRPC sits outside that loop entirely. It is the closest thing to a known-permanent privilege-escalation primitive Windows has had in some time.

Where this fits in the bigger picture

The interesting thing about PhantomRPC is not that it gives an attacker SYSTEM – plenty of bugs do that. It is what kind of attacker it gives SYSTEM to.

Most of the LPEs we have written about recently – BlueHammer, the AFD.sys family, the Windows Error Reporting bug, Azure Arc – start with “an attacker has code execution as a normal logged-on user”. PhantomRPC starts with “an attacker has code execution as a service account”. That is a different shape of compromise, but it is not a rare one.

Combine PhantomRPC with any of the dozens of bugs each year that get an attacker into a service context, and you have a reliable path to SYSTEM that Microsoft is not going to break for you. Combine it with permanent local admin rights elsewhere in your estate, and you have a path that an attacker can pivot through almost effortlessly once they land.

That is the connective tissue with the rest of this story. Breakout time is in minutes now. Every additional layer of friction matters. PhantomRPC is one fewer layer.

What defenders can do without a patch

Kaspersky’s write-up suggests several practical mitigations, and they are worth taking seriously:

• Enable ETW-based RPC monitoring. Look for RPC_S_SERVER_UNAVAILABLE errors combined with high impersonation levels from privileged processes. That is the behavioural fingerprint of someone hunting for a phantom endpoint to take over.
• Start, do not disable, optional RPC services where feasible. If a service like TermService is running – even idle – the endpoint is occupied and cannot be hijacked. Disabling it is what creates the phantom in the first place.
• Restrict SeImpersonatePrivilege. Audit which accounts and services hold it. Remove it from anything that does not strictly need it. This is the gating privilege that makes PhantomRPC useful at all.
• Tighten what runs as a service account in the first place. The fewer compromisable Network Service / Local Service workloads you expose, the less PhantomRPC matters in practice.
• Keep your users standard. PhantomRPC is a service-context bug, but most service-context compromises ride in on the back of a user-context one. A standard user is harder to leverage into anything – including the foothold an attacker would use to plant a phantom server.

The pattern, again

BlueHammer was “Microsoft is slow to patch”. PhantomRPC is “Microsoft has decided not to patch”. Different shapes, same conclusion: your endpoint security model cannot rely on Microsoft fixing every privilege-escalation primitive that gets disclosed.

The defenders who weather these well are the ones who already have their local admin footprint under control, their service-account sprawl audited, and their elevation paths constrained to a known list. The ones who struggle are the ones who treat least privilege as a nice-to-have they will get to once the next big migration is done.

Running Legacy Apps That Still Need Elevation?

If the only thing keeping your users in the local Administrators group is a handful of legacy or specialist applications that break without elevated permissions, that is exactly the problem Elevator is designed to solve.

Elevator is a lightweight Windows utility that elevates just the applications you approve – automatically and silently – while keeping your users as standard users everywhere else. No more “they need local admin for that one app.” No more shared admin passwords. And when the next PhantomRPC-style architectural surprise lands, your blast radius is already smaller.

Try Elevator free → or get pricing and deployment guidance.

Related reading

• April 2026 Patch Tuesday: 93 Elevation-of-Privilege Bugs & The Local Admin Multiplier
• BlueHammer: The Unpatched Windows Zero-Day That Makes Every Local Admin a Higher-Value Target
• You Don’t Have an Hour Anymore: Why Least Privilege Matters When Breakout Time Is Minutes
• The Local Admin Retirement Checklist