PhantomRPC: Windows RPC Endpoint Spoofing Leads to SYSTEM Privilege Escalation

Windows RPC has long been one of the most security-sensitive subsystems in the operating system, but the newly disclosed PhantomRPC research suggests that the real risk is not just in individual bugs, but in the way Windows lets unrelated processes reach for the same privileged RPC endpoints. In the Securelist write-up, Kaspersky describes a local privilege escalation technique that can turn processes with SeImpersonatePrivilege into full SYSTEM compromise by abusing RPC clients that expect a service to be present but never verify whether the server is genuine. The result is less a single exploit than an architectural trap: if an attacker can stand up a fake RPC server under the right service identity, Windows may happily connect the victim client to it. That makes PhantomRPC a textbook example of why endpoint trust, impersonation semantics, and service availability matter just as much as memory safety.

Background​

Windows interprocess communication is built on layers of abstractions that were designed to make complex software distributed, modular, and efficient. Remote Procedure Call (RPC) sits at the center of that model, letting one process invoke functionality that lives in another process, often without the caller needing to know anything about transport details or service internals. Securelist’s research highlights that RPC can ride over TCP, named pipes, or ALPC on the local machine, and Microsoft’s documentation confirms that ncalrpc is the local RPC protocol sequence used for same-host communication.
That flexibility is a strength, but it is also a recurring security problem. The same abstraction that makes Windows services easy to compose can also blur the boundary between a “real” server and a process that merely impersonates one. Microsoft’s own documentation on endpoint registration explains that RPC endpoints may be well-known, dynamic, or registered through interface metadata, while the runtime does not inherently bind an interface to a single trusted process. In practice, that means endpoint names and protocol sequences can become attack surface when code assumes the target server is always the expected one.
PhantomRPC lands in that gap. The Securelist analysis describes a situation in which a client expects to contact a service such as TermService, but if that service is unavailable, the client may still connect to an attacker-controlled server that exposes the same interface UUID and endpoint. Microsoft’s documentation on RPC impersonation makes clear why this matters: if a server can call RpcImpersonateClient and the client connection was made with a permissive impersonation level, the server can adopt the client’s security context.
The critical prerequisite is SeImpersonatePrivilege, or the “Impersonate a client after authentication” right. Microsoft notes that this privilege is intended specifically to prevent unauthorized servers from impersonating clients that connect through RPC or named pipes, and that it is commonly granted to service accounts such as Local Service and Network Service. That default makes service-to-service trust efficient, but it also creates a broad and attractive escalation path when one of those service contexts is already compromised.
From a defensive perspective, the novelty here is not that impersonation exists. It is that RPC clients may be coerced into talking to a malicious local server when the expected one is absent, and that the client’s own high-privilege context can be used as the stepping stone to elevation. That pattern is more systemic than a simple bug in one binary, which is why the report frames it as an architectural issue rather than a one-off exploit.

---

How PhantomRPC Works​

At a high level, PhantomRPC relies on a simple but dangerous sequence. A target application or service tries to connect to an RPC endpoint it expects to exist, but the legitimate server is disabled, unavailable, or not yet running. Instead of failing in a way that protects the client from deception, the Windows RPC runtime can still complete a local binding to a server that presents the same interface and endpoint shape.
The Securelist article shows this clearly in the TermService scenario. The Group Policy client path attempts to contact TermService over ncalrpc:[TermSrvApi] using a high impersonation level, and when the real service is absent the runtime returns an availability error. But if an attacker can already run code in a service account with impersonation rights, they can launch a fake RPC server that listens on the same local endpoint and expose the same interface UUID. That is enough to catch the client.

Why the endpoint matters​

RPC is not a magical “call this function by name” system. It depends on a binding between client and server that includes the protocol sequence, endpoint, interface UUID, and operation number. Microsoft’s endpoint documentation emphasizes that endpoint names are transport-specific, while the ncalrpc specification notes that the port name is simply the local communication port used by the client and server. Securelist’s proof-of-concept weaponizes that transport-layer trust by reproducing the exact endpoint the victim expects.

Why impersonation matters​

The attack only becomes useful when the client grants a permissive impersonation level. Microsoft explains that a client can choose the impersonation level for RPC and that SecurityImpersonation allows the server to impersonate the client on the local system. In the PhantomRPC examples, the clients are often high-value system processes or privileged user processes, so once the malicious server can impersonate them, the privilege jump is immediate.
A few details make the technique especially notable:

• The attacker does not need memory corruption.
• The attacker does not need to subvert the RPC runtime directly.
• The attacker does need a foothold in a service context that already has impersonation rights.
• The server can be “fake” so long as the client reaches it first.
• The result depends on the client’s trust assumptions, not a single application bug.

The bigger implication is that the exploit chain is highly reusable. Securelist argues that any Windows component that relies on RPC to reach a disabled or absent service may be a candidate, provided the attacker can predict the endpoint and satisfy the impersonation preconditions. That makes the technique feel less like a point exploit and more like a pattern for finding future ones.

---

The Group Policy to TermService Path​

One of the cleanest exploitation paths in the research begins with gpsvc, the Group Policy Client service. When an administrator runs gpupdate.exe /force, Windows refreshes policy state and, during that process, gpsvc attempts to communicate with TermService over RPC. Securelist reports that the client uses an impersonation level of Impersonate and expects the server to run under Network Service.
That expectation is what the attacker leverages. If TermService is disabled, unavailable, or simply not running, an attacker who already controls a Network Service process can register a fake RPC server that mimics the TermService interface and endpoint. When gpupdate forces the policy action, the SYSTEM-level client binds to the attacker’s endpoint instead of the real service. The server then calls RpcImpersonateClient, and the attack chain ends with SYSTEM context.

Why this is more than a “service spoof”​

The real lesson here is that Windows service dependencies are often implicit. The Group Policy service is not deliberately “calling into malware”; it is trying to resolve a normal system dependency. Yet because the runtime does not appear to validate server legitimacy in the way the researcher expected, the boundary between legitimate service discovery and malicious endpoint capture becomes very thin.
This also means the exploit is not limited to one machine state. The Securelist report notes that at least one group policy must be applied, but that is a modest condition in enterprise environments where policy refresh is routine. In other words, the attack is not a lab curiosity. It is tied to a common administrative workflow.

Operational implications​

This path is especially troubling for defenders because:

• The trigger is an ordinary administrative action.
• The victim process is SYSTEM.
• The malicious server can hide inside an already-privileged service account.
• The client behavior is normal and likely noisy only in traces.
• The abuse chain fits neatly into post-exploitation tradecraft.

The important takeaway is that policy refresh becomes a potential privilege boundary crossing when the service on the other end is missing. That is a subtle but powerful shift in how defenders need to think about “routine” Windows operations.

---

User Interaction: Edge to RDP​

The second path in the Securelist report moves from administrative coercion to user-driven execution. In that scenario, Microsoft Edge starts up and triggers an RPC call to TermService with a high impersonation level. Because Remote Desktop Services are disabled by default on many systems, the expected endpoint may not be present, and that gives the attacker room to insert a spoofed local server.
The significance of this path is that it requires no custom lure beyond normal usage. If an attacker already has code execution under Network Service, they can wait for a high-privileged user, such as an administrator, to open Edge. The browser’s startup sequence becomes the trigger that reaches the malicious RPC server, which can then impersonate the administrator-level client.

Why browser launch matters​

Browsers are prime candidates for trigger conditions because they are launched constantly and often with elevated user context in enterprise settings. The research’s broader message is that seemingly benign, everyday software can contain hidden RPC dependencies that only become visible when a backend service is absent. That means endpoint hardening cannot focus only on obvious admin tools.
This is also where the practical risk begins to outgrow the novelty of the technique. Browser launches are common, user expectations are low, and the attack does not need an obvious prompt. In other words, user interaction here is not a warning banner or a consent dialog; it is simply the act of opening a common application.

Enterprise versus consumer impact​

On consumer systems, the impact is still serious, but the attacker usually needs an initial foothold first. In enterprise environments, however, privilege boundaries are denser and service accounts are more common, so a Network Service foothold can be much more consequential. A browser-triggered impersonation chain can become a lateral movement accelerator when administrators share systems or perform routine tasks under elevated accounts.
The lesson is uncomfortable: the attack does not require the victim to do anything reckless. It only requires them to do something ordinary while a malicious server waits in the background. That is precisely the kind of operational asymmetry attackers look for.

---

Background Services: WDI to RDP​

The WdiSystemHost path is arguably the most elegant of the set because it eliminates user interaction altogether. Securelist says that the Diagnostic System Host service periodically performs RPC calls to TermService every five to fifteen minutes, and that these calls run under SYSTEM with a high impersonation level. In practice, that means the attacker can sit and wait for the system itself to walk into the trap.
This matters because it changes the attacker’s burden. Instead of coercing a service or relying on an administrator to open software, the attacker only needs the malicious RPC server to be available at the right time. When the periodic diagnostic call occurs, the server captures the SYSTEM client and impersonates it. That yields direct escalation to SYSTEM from a compromised service context.

Why periodic background tasks are dangerous​

Background services are often trusted more than interactive apps because they are assumed to be stable, predictable, and vendor-controlled. But periodic RPC activity is exactly the kind of automated behavior that attackers can monitor and exploit. If the dependency graph includes a disabled or missing service, the system itself can become the trigger.
A second concern is that defenders rarely notice these interactions during daily operations. A periodic internal RPC call does not look like suspicious network traffic, and when it fails, the error may be swallowed or logged only in developer-facing traces. That makes detection harder than it should be.

Why this path stands out​

This is the cleanest “wait for privilege” exploitation path in the report:

• Compromise a Network Service or similar impersonation-capable context.
• Deploy a fake TermService-compatible RPC endpoint.
• Wait for WDI to perform its periodic call.
• Impersonate the SYSTEM client.
• Spawn a SYSTEM shell or equivalent payload.

That makes the WDI path especially attractive from an attacker’s point of view because it removes timing pressure and user dependence. It is a reminder that automation is a double-edged sword when service-to-service trust is weak.

---

Local Service Abuse: ipconfig to DHCP​

The next scenario shifts the attacker’s foothold from Network Service to Local Service and targets the DHCP Client service. Securelist describes a case where ipconfig.exe triggers RPC communication with the DHCP Client service, and if that service is unavailable the client can be lured to an attacker-controlled server instead. Because the call uses a high impersonation level, the malicious server can impersonate the client and move from Local Service to Administrator.
This is important for two reasons. First, it shows that PhantomRPC is not limited to SYSTEM targets. Even an Administrator token is a major step up from Local Service, especially for post-exploitation staging. Second, it shows that basic network utilities can unexpectedly become security boundaries.

Why DHCP is a compelling target​

DHCP is deeply embedded in Windows networking workflows, so it is an easy place to hide trust assumptions. A user running ipconfig usually believes they are simply querying interface status, not invoking a privileged RPC pathway. But Windows often layers system DLLs behind these utilities, and those DLLs may depend on RPC under the hood.
That has broader implications for incident response. If investigators only inspect the visible executable, they may miss the hidden RPC dependency that actually created the escalation path. The attack surface is therefore not just in the named binary, but in the linked system components that service the call.

Defensive meaning​

From a defensive standpoint, this path is a strong argument for reducing unnecessary service rights. Microsoft’s documentation makes clear that SeImpersonatePrivilege is sensitive precisely because it enables servers to assume client identity. If a custom or third-party process does not truly need that privilege, granting it increases the value of any missed RPC trust boundary.
The practical takeaway is that Local Service is not a harmless sandbox. In a world of RPC endpoint spoofing, it can be the launch pad for far more powerful access if the right client can be coerced into connecting.

---

Abusing Time: W32Time and the Phantom Pipe​

The Windows Time service path is particularly interesting because Securelist says the legitimate service does not even need to be disabled. The executable w32tm.exe first attempts to connect to a nonexistent pipe, \PIPE\W32TIME, before talking to the actual endpoints exposed by W32Time. An attacker can expose that absent endpoint with a malicious RPC server, causing the client to connect to the fake server first.
That is a clever twist because it shows PhantomRPC can work even when the official service is present. The attack does not depend solely on service downtime; it can exploit alternate or preliminary endpoint logic in the client. In other words, the attacker only needs one reachable path the client is willing to try.

Why this is strategically important​

This is the scenario that most clearly demonstrates the depth of the design weakness. If the legitimate service is alive and well, defenders might assume the attack surface disappears. But the Securelist example shows that client behavior itself can introduce a phantom trust path through a nonexistent endpoint. That means availability of the real service is not always enough to eliminate risk.
It also broadens the research beyond the simple “service stopped” pattern. If clients probe multiple endpoints, or if one endpoint exists only for compatibility, an attacker can weaponize that compatibility layer. The real vulnerability is not just missing services; it is unexpected client willingness to talk to the wrong one.

Key observations​

• The legitimate W32Time service does not need to be disabled.
• The attack can target an alternate or probe-only endpoint.
• The attacker still relies on impersonation-capable service context.
• The client’s connection logic becomes part of the exploit chain.
• The technique scales to any similar “try this endpoint first” pattern.

This is one of the strongest arguments in the report that the problem is architectural. The exploit is not about one service failing to launch; it is about Windows clients accepting the first plausible local RPC endpoint that fits their expectation.

---

Detection Through ETW​

Securelist’s detection work is just as important as the exploitation narrative because it shows how defenders can begin mapping their own environments. The research uses Event Tracing for Windows (ETW) to monitor RPC activity and then filters the resulting data to identify failures where clients attempted to reach unavailable servers. Microsoft documents ETW as a built-in tracing framework, and the report leverages that visibility to avoid invasive instrumentation.
The key insight is that the research is not just looking for RPC events, but specifically for combinations of metadata that suggest danger: interface UUID, endpoint, OPNUM, impersonation level, client process name, and the status code indicating server unavailability. That gives defenders a data-driven way to reproduce the same kind of hunting logic in their own environments.

What to look for​

The Securelist workflow focuses on RPC_S_SERVER_UNAVAILABLE, because the missed connection is what creates the spoofing opportunity. The process is to capture ETW logs, convert them to JSON, and correlate a stop event with its corresponding start event to recover missing details like interface UUID and impersonation level. From there, the data can be matched against an RPC interface database to identify the underlying DLL and service.
That is valuable because defenders can answer questions such as:

• Which high-value processes are trying to talk to absent services?
• Which endpoints are being requested with Impersonate or higher?
• Which clients are quietly failing and retrying in the background?
• Which service dependencies are producing exploitable fallback behavior?
• Which systems are running with avoidable impersonation rights?

Why ETW is a good fit​

Microsoft’s RPC tracing and debugging documentation show that RPC state is rich enough to infer endpoint and transport behavior, and ETW gives defenders a practical route to observe that without modifying system binaries. Securelist’s approach is therefore attractive not just for reverse engineering, but for enterprise hunting where changing production behavior is undesirable.
The catch is that ETW alone is not a silver bullet. The data volume is large, the event structure is noisy, and the signal only appears when a relevant failure occurs. That means defenders need tooling, filtering logic, and a good model of which clients matter most.

---

Disclosure, Severity, and Microsoft’s Response​

The disclosure timeline is central to understanding the impact of the report. Securelist says Kaspersky submitted a 10-page technical report to MSRC on September 19, 2025, and Microsoft responded on October 10, 2025 that it considered the issue moderate severity, not eligible for a bounty, and not in need of immediate patching or a CVE. According to the report, Microsoft’s reasoning was that exploitation required the originating process to already have SeImpersonatePrivilege.
That position is defensible in one narrow sense and troubling in another. Microsoft is right that the privilege is not something a random unprivileged user normally has. But Microsoft’s own guidance also makes clear that the privilege is commonly present on service accounts and service-hosted code, which are exactly the kinds of contexts attackers frequently reach first. So the question is not whether the privilege exists, but how often a real intrusion chain can reach it.

Why the severity debate matters​

The disagreement reflects a classic tension in vulnerability assessment. Vendors often rate issues according to the direct prerequisites for exploitation, while researchers evaluate how those prerequisites are achieved in real-world attack chains. PhantomRPC sits right in that gap because the vulnerable behavior is not the initial foothold; it is the escalation step after compromise.
From an operational perspective, that makes the lack of a patch more consequential than it might appear on paper. Even if the issue is not exploitable from a clean desktop login, it may still be extremely relevant in post-exploitation scenarios, especially in environments where service accounts, desktop apps, and elevated utilities coexist on the same host.

The broader policy lesson​

The report also reinforces a difficult truth about coordinated disclosure: sometimes the most important flaws are the ones tied to design assumptions, not discrete memory corruption. Those are harder to assign to a single product team, and they are often slower to fix. That does not make them less dangerous; it just makes them harder to land inside traditional patch cycles.
For defenders, the lesson is to treat the absence of a CVE as not the same as the absence of risk. PhantomRPC appears to be exactly the kind of weakness that can linger because it is architectural, reproducible across versions, and buried inside normal operating behavior.

---

Strengths and Opportunities​

PhantomRPC is a useful piece of security research because it surfaces a class of abuse that is easy to miss in conventional patch management. It also gives defenders a rare combination of technical detail and hunting methodology, making it possible to look for the same pattern elsewhere in the environment. The research’s greatest value is that it reframes RPC not as a legacy transport, but as a living trust boundary that deserves active scrutiny.

• It exposes a repeatable escalation pattern rather than a single bug.
• It highlights the danger of service availability assumptions in Windows clients.
• It shows how SeImpersonatePrivilege can be abused in realistic post-exploitation chains.
• It provides a practical ETW-based detection workflow.
• It broadens defender attention from memory corruption to architectural trust failure.
• It maps multiple triggers, which helps organizations prioritize the most dangerous client paths.
• It reinforces the need for tighter control over service account privileges.

The broader opportunity is to use this research as a template. Security teams can audit their own RPC consumers, identify what they do when a target service is unavailable, and ask whether fallback behavior is safe or merely convenient. That kind of review may uncover problems long before an attacker does.

---

Risks and Concerns​

The biggest concern is that the flaw is not bounded to a single service or product family. Securelist’s analysis suggests that any Windows component using RPC in a similar way could become another escalation route, which means the attack surface is potentially much larger than the examples shown in the paper. That breadth is what makes an architectural issue so difficult to contain.

• Attackers can hide inside already-privileged service accounts.
• The victim process may be a routine Windows utility, not an obvious admin tool.
• The exploit can be triggered by background activity with no user interaction.
• Detection may miss the root cause if teams only watch the visible executable.
• The absence of a patch leaves defenders dependent on mitigation and monitoring.
• The same pattern may exist in third-party software that also uses RPC.
• Endpoint spoofing can remain effective even when the real service is present, depending on client behavior.

There is also a strategic concern for enterprises that rely heavily on service accounts. If SeImpersonatePrivilege is common in their environment, then the exploit preconditions may be easier for attackers to satisfy after a foothold is gained. That is why privilege minimization matters here as much as patching would.
Finally, there is the problem of visibility. RPC is often invisible to the user and only partially visible to administrators unless tracing is enabled. That means organizations may not even realize they have exposed endpoints or failing service dependencies until a compromise forces the issue.

---

Looking Ahead​

The most likely next step is that defenders will begin auditing their own environments for patterns similar to those described in PhantomRPC. That means watching for high-privilege clients that fail to reach expected RPC services, mapping which endpoints are actually used on each SKU, and confirming whether the corresponding services are always available when they should be. In a large Windows estate, that is a meaningful but necessary amount of work.
There is also a good chance that future research will uncover more variants. The Securelist paper already hints that the number of exploitation paths is effectively unlimited whenever a client assumes a service exists and the runtime does not guarantee the legitimacy of the server. That suggests the real story is still unfolding, not closing.

What defenders should watch next​

• New RPC client paths that hit unavailable services during boot or admin workflows.
• Background services that perform periodic impersonating calls.
• Any endpoint that can be spoofed with a matching UUID and local name.
• Systems where Local Service or Network Service holders can spawn arbitrary listeners.
• Opportunities to reduce or remove SeImpersonatePrivilege from custom services.
• Telemetry showing repeated RPC_S_SERVER_UNAVAILABLE failures for sensitive callers.

The long-term significance of PhantomRPC is that it pushes Windows defenders to think less like patch consumers and more like protocol auditors. If an endpoint can be impersonated, then the real question is not whether the server is running, but whether the client can prove it is talking to the right one. That is a harder question than a normal CVE, but it is increasingly the one modern Windows security depends on.

---

Source: Securelist Disclosing PhantomRPC – a privilege escalation vulnerability in RPC