Hijacking Windows Services via EPM Poisoning

TLDR: A new research finding demonstrates how to hijack RPC endpoints by poisoning the Endpoint Mapper (EPM) before legitimate services start. By registering malicious interfaces during the boot process, an attacker can force privileged services to authenticate against a rogue server, leading to NTLM relay attacks or local privilege escalation. This technique, which does not require administrative privileges, highlights a critical gap in how Windows handles service registration and authentication.

Remote Procedure Call (RPC) is the backbone of Windows inter-process communication. Every time you interact with a system service, you are likely triggering an RPC call. For years, security researchers have focused on finding memory corruption bugs in these services to achieve code execution. However, the underlying mechanism that connects clients to these services—the Endpoint Mapper (EPM)—has remained largely overlooked as an attack surface. Recent research presented at DEF CON 2025 proves that you do not need to find a complex buffer overflow to compromise a system; you just need to beat the service to the punch.

The Mechanics of EPM Poisoning

The EPM acts like a DNS server for RPC. When a service starts, it registers its interface UUID with the EPM. When a client wants to communicate with that service, it queries the EPM for the corresponding endpoint. The EPM then returns the location of the service. The vulnerability lies in a simple, overlooked design choice: the EPM does not verify the identity of the process registering an interface. If an attacker can register an interface before the legitimate service does, the EPM will happily point all incoming client requests to the attacker’s process.

This is a classic race condition. Many Windows services are configured with a delayed startup to improve boot times. During this window, the service is not yet running, and its interface is not registered. An attacker can execute a script at logon to register the target interface UUID with the EPM. When a legitimate client—even one running as NT AUTHORITY\SYSTEM—attempts to connect to the service, the EPM directs it to the attacker’s rogue server.

Weaponizing the Connection

Once the client is connected to your rogue server, you have effectively performed a man-in-the-middle attack on the RPC communication. The goal is not just to intercept data, but to force the client to authenticate. By masquerading as the legitimate service, you can trigger authentication flows that would otherwise be protected.

The research highlights the use of RPC-Racer, a tool designed to automate this process. It scans for interfaces that are not yet mapped to an endpoint and registers them. Once a connection is established, the tool can be used to gather information about the client or, more dangerously, to force NTLM authentication.

If you target a service that interacts with network resources, you can force the client to authenticate against a rogue SMB server. This is where the impact scales. By using ntlmrelayx from the Impacket suite, you can relay that authentication to other network resources, potentially gaining access to sensitive shares or even domain controller credentials.

The Role of Impersonation and Security QOS

A common hurdle in RPC exploitation is the Security Quality of Service (QOS). When a client connects to an RPC server, it can specify an impersonation level. If the client requests SecurityIdentification, the server can see who the client is but cannot act on their behalf. This is a common defense mechanism that prevents a compromised service from simply impersonating its callers.

However, the research shows that even if you cannot directly impersonate the client, you can still leverage the connection. By forcing the client to authenticate against an external resource, you bypass the need for local impersonation entirely. The client does the heavy lifting of authentication for you. This is particularly effective against services like the Storage Service, which handles file system operations and often runs with high privileges.

Defensive Considerations

Defending against this requires a shift in how we view service registration. The EPM should ideally validate the identity of the process attempting to register an interface, ensuring it matches the expected service identity. Until such a change is implemented at the OS level, detection is the primary path forward.

Security teams should monitor for suspicious registrations to the EPM. Using Event Tracing for Windows (ETW), specifically the Microsoft-Windows-RPC provider, allows you to track which processes are registering which interfaces. Any process that registers an interface belonging to a core system service should be flagged immediately.

The vulnerability identified as CVE-2025-49760 serves as a reminder that even well-understood protocols like RPC have hidden depths. The patch for this issue forces the RPC client to verify the security context of the server, ensuring that only the legitimate service can handle the connection.

For those conducting penetration tests, this technique is a goldmine. It allows for a low-privilege user to escalate their standing on a machine by simply waiting for the right service to start. Start by using RPC-Recon to map the environment during a boot cycle. Look for services that are not registered immediately. These are your targets. The race is on, and if you are fast enough, you can own the machine before the user even reaches their desktop.