Security News Kaspersky researchers discover PhantomRPC, a new Windows privilege escalation technique exploiting RPC architectural weaknesses.

[Khushal]

Content source

https://securelist.com/phantomrpc-rpc-vulnerability/119428/

Windows Interprocess Communication (IPC) is one of the most complex technologies within the Windows operating system. At the core of this ecosystem is the Remote Procedure Call (RPC) mechanism, which can function as a standalone communication channel or as the underlying transport layer for more advanced interprocess communication technologies. Because of its complexity and widespread use, RPC has historically been a rich source of security issues. Over the years, researchers have identified numerous vulnerabilities in services that rely on RPC, ranging from local privilege escalation to full remote code execution.

Disclosing PhantomRPC – a privilege escalation vulnerability in RPC

Kaspersky researcher discovered a vulnerability in RPC architecture that enables an attacker to create a fake RPC server and escalate their privileges.

securelist.com

Enables escalation from service accounts to SYSTEM across all Windows versions without requiring patches.

Technical details:
• Targets RPC calls to unavailable servers (TermService, DHCP Client, W32Time) with high impersonation levels
• Attack deploys malicious RPC server mimicking legitimate endpoints like ncalrpc:[TermSrvApi] or \PIPE\W32TIME
• Requires SeImpersonatePrivilege but works from Network Service/Local Service contexts (T1134.001)
• Five exploitation paths identified: gpupdate coercion, Edge startup, WDI background service, ipconfig execution, w32tm.exe timing

Attack methodology:
• Attacker compromises service running under Network/Local Service account
• Deploys fake RPC server with same UUID/endpoint as legitimate disabled service
• Legitimate high-privilege process makes RPC call expecting real server
• Malicious server calls RpcImpersonateClient() to assume SYSTEM/Admin context
• ETW monitoring reveals pattern: Event ID 1 with RPC_S_SERVER_UNAVAILABLE (0x800706BA)

 

[Bot]

This is a real security topic, but one important correction is needed: the claim that it works “across all Windows versions without requiring patches” should not be treated as universally confirmed unless you are relying on the vendor’s own research and testing. I cannot independently verify every affected build from the quoted text alone.

What the article is describing

This appears to be an RPC impersonation/coercion-style privilege escalation scenario where:

• A low-privileged service context such as Network Service or Local Service already exists on the machine
• The attacker has SeImpersonatePrivilege
• A legitimate privileged client attempts to contact an RPC endpoint that is unavailable
• A malicious local RPC server is placed in its place and handles that call
• The fake server then uses client impersonation to obtain a higher-privilege token, potentially SYSTEM

So this is not a “drive-by” issue by itself. It is more accurately a post-compromise local privilege escalation technique that can turn a service-account foothold into full system compromise.

Why this matters

If the reported behavior is accurate, the practical impact is significant because many real-world intrusions begin with code execution inside a constrained service account rather than as a standard user or administrator.

That means:

• Sandbox or service escapes become easier
• Defense tools running under service identities may become a stepping stone
• Attack chains that previously stopped at Network Service could continue to SYSTEM

What stands out technically

The most notable part is not just “RPC is vulnerable,” but the combination of:

• Unavailable or disabled RPC-backed services
• Predictable endpoint names such as ncalrpc:[TermSrvApi] or named pipes
• Privileged clients still attempting to connect
• Impersonation being allowed at a sufficiently high level

That is a dangerous pattern. In general, whenever a privileged process connects outward to an endpoint it assumes is trustworthy, there is risk if endpoint ownership is not strongly validated.

Important limitations

Based on the quoted description, this does not mean every system is instantly exploitable in the same way.

Practical success likely depends on:

• The exact Windows version and build
• Which services are disabled, unavailable, or reachable
• Whether the attacker already has code execution in a service context
• Whether protections or service-hardening changes block specific paths
• Timing and endpoint registration conditions

So forum readers should avoid turning this into “all Windows boxes are trivially broken.” The safer interpretation is: this is a serious local escalation technique with broad potential impact, pending confirmation of exact affected scenarios.

Defensive view

If you are assessing risk in an enterprise or lab, the useful response is to focus on detection and exposure reduction:

• Treat Network Service and Local Service compromise as potentially one step away from SYSTEM
• Review services that run with SeImpersonatePrivilege
• Monitor for suspicious local RPC server registration, especially on well-known endpoints
• Look for failed RPC connection attempts followed by unusual endpoint creation
• Use ETW/Sysmon/EDR telemetry to correlate service-account processes with named pipe or ALPC endpoint abuse

The ETW note in the quote is especially useful. Repeated RPC_S_SERVER_UNAVAILABLE events before successful impersonation activity could be a meaningful hunting lead, although it is not a standalone indicator.

Mitigation ideas

Without speculating beyond what is publicly documented, the lower-risk actions are:

• Avoid disabling core services unless there is a documented security reason and the operational effect is understood
• Reduce unnecessary service-account exposure on endpoints
• Harden applications and services that run as Network Service or Local Service
• Apply any Microsoft guidance or future fixes once officially published
• Use EDR rules to flag suspicious creation of RPC/named-pipe endpoints matching legitimate service names

There is usually no clean “user-side patch” for this kind of issue unless Microsoft changes RPC client/server trust behavior or hardens the affected services.

Bottom line

If the Securelist analysis is accurate, this is best understood as a high-value local privilege escalation primitive, not a universal remote compromise bug. The key risk is that service-account compromise may no longer remain contained.

Sources

• Disclosing PhantomRPC – a privilege escalation vulnerability in RPC