Windows RPC endpoint poisoning exposes machine-account authentication

At a glance

What this is: This research shows that Windows RPC endpoint mapper poisoning can let an unprivileged process impersonate a trusted service and trigger machine-account authentication to an attacker-controlled endpoint.

Why it matters: It matters because identity and access controls only work if the client can verify the server it is talking to, a gap that affects workload identity, service trust, and privileged inter-process communication.

Context

Windows RPC uses interface UUIDs and an endpoint mapper to connect clients to servers, but that lookup model assumes the first registered endpoint is trustworthy. In this case, that assumption was exploitable because an unprivileged process could register a built-in interface before the real service and receive client connections.

For identity teams, the security issue is not classic authentication failure at login time. It is trust in a local service endpoint before the authentication exchange even reaches policy, which turns inter-process communication into an identity boundary that is easy to misread.

The article's core point is that delayed service start and endpoint registration order can create a race condition in which the wrong process becomes the trusted endpoint. That is atypical in normal operating assumptions, but it is exactly what made this attack feasible.

Key questions

Q: What fails when a low-privilege process can register a trusted RPC interface first?

A: The trust model fails because the client accepts the first registered endpoint as if it were the legitimate service. That lets an unprivileged local process impersonate a built-in RPC server, intercept service calls, and steer protected clients into authenticating to the wrong peer.

Q: Why does RPC endpoint poisoning create machine-account exposure risk?

A: Because the client is not leaking a stored secret, it is being tricked into authenticating to an attacker-controlled server. Once a protected process or system service performs that authentication, the attacker can capture machine-account material such as an NTLM hash and use it for broader abuse.

Q: Why do delayed-start services increase RPC endpoint hijack risk?

A: Delayed-start services create a time window in which an attacker can register a matching interface before the real service appears. That matters because the endpoint mapper uses the first valid registration, so the attacker can become the trusted responder long before the intended service is online.

Q: How should teams govern local RPC trust paths in Windows?

A: Treat local RPC connections as privileged trust paths whenever protected processes or system services are involved. Govern interface registration, endpoint ownership, and server identity verification with the same seriousness you would apply to remote authentication boundaries.

Technical breakdown

How RPC endpoint mapping becomes a trust decision

Windows RPC clients that know only an interface UUID rely on the Endpoint Mapper to resolve that UUID to a live endpoint. If the client does not pin a server identity, the mapper becomes a trust broker: the first registered endpoint wins, and later registrations do not displace it. That means a local attacker who can register the same interface early in boot can intercept calls intended for a built-in service. The weakness is not RPC itself, but the absence of server identity verification at the time the client resolves the endpoint.

Practical implication: treat endpoint resolution as an identity control and test whether clients verify the server they reached, not just the interface they requested.

Why low-privilege interface registration is the critical entry condition

The attack works because the vulnerable registration path allowed a medium-integrity process to register known interfaces without being the legitimate service. Once that registration succeeded, the attacker did not need to break authentication in the usual sense. The attacker only needed to win the boot-time race and present a believable RPC surface before the genuine service came online. In effect, the security boundary was pushed from authorization into service startup sequencing, which is a much weaker control point.

Practical implication: audit which RPC services can be pre-registered by non-service processes and remove any startup path that lets untrusted code claim a trusted interface.

Machine-account authentication exposure through spoofed RPC servers

Once clients connected to the rogue endpoint, the attacker could coerce protected processes to authenticate to the attacker-controlled server and expose the machine account NTLM hash. That is different from ordinary credential theft because the credentials were not harvested from storage; they were elicited through protocol trust. The result is that machine identity becomes reachable through an inter-process trust failure, and the impact can extend to privileged services such as update components or other protected processes that assume the endpoint is genuine.

Practical implication: monitor for unexpected RPC registrations and authentication attempts to unknown endpoints, especially where protected processes or system services are the client.

Threat narrative

Attacker objective: The attacker aims to obtain machine-account authentication material from trusted Windows services by making them talk to a malicious RPC endpoint.

1. Entry occurs when an unprivileged local process registers a built-in RPC interface before the legitimate service during boot.
2. Credential access follows when protected processes connect to the spoofed endpoint and authenticate to it as the machine account.
3. Impact occurs when the attacker captures the machine account NTLM hash and can use that trust boundary breach for further abuse.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Endpoint mapping is an identity decision, not a routing detail: The Windows RPC Endpoint Mapper effectively decides which server a client trusts when the client knows only a UUID. That makes endpoint registration part of the identity plane, even though many programmes still treat it as a transport concern. The failure here is not simply a missing hardening step. It is a misplaced assumption that a resolved endpoint is inherently the right endpoint. Practitioners should treat service registration order and server identity verification as governance issues, not just protocol mechanics.

The broken assumption is that a trusted interface implies a trusted server: That assumption was designed for environments where the legitimate service arrives first and remains authoritative. It fails when an unprivileged actor can register the same interface before the real service, because the client cannot distinguish intent from impersonation. The implication is that inter-process trust must be explicit and verifiable, not inferred from interface ownership alone. Practitioners should rethink where trust is anchored inside Windows service communication.

Machine identity can be exposed without any direct secret-store compromise: This attack shows that identity material can be elicited through protocol behavior rather than stolen from a vault or disk. That matters for NHI governance because the machine account was not over-permissioned in the conventional sense; it was made available by a trust failure in the communication path. The practical takeaway is that credential exposure controls must extend into service discovery, not stop at secret storage.

Boot-time race conditions create an identity blast radius: When delayed-start services and dynamic endpoint registration collide, the attack surface expands to whatever privileged client trusts the first responder. That means a single weak registration point can affect multiple downstream services, including protected process light clients. For practitioners, the real control question is not whether the service is authenticated at rest, but whether any client can be forced into authenticating the wrong peer at runtime.

RPC client trust needs the same scrutiny as remote authentication: Identity programmes often model authentication as a user or workload reaching a login boundary, yet this research shows that client-side trust in local RPC can produce the same consequence. The boundary between service and caller becomes an identity control surface when protected processes will speak to whatever endpoint the mapper returns. Practitioners should classify these local RPC relationships as privileged trust paths and govern them accordingly.

What this signals

Endpoint registration order is now an identity governance concern: The attack works because the mapper trusts the first registered endpoint, which means runtime identity can be decided before policy has any say. Programmes that only review accounts and secrets miss this class of service-to-service trust failure. The control question is whether a client can prove who owns the endpoint it reached, not whether the interface name looked legitimate.

Local service impersonation collapses the boundary between workload identity and privilege: When a medium-integrity process can present itself as a built-in RPC service, the resulting trust relationship is stronger than many workload controls expect. That should push practitioners toward closer review of service startup sequencing, protected-process client assumptions, and server identity binding. The practical effect is broader than one Windows bug because the pattern can recur anywhere endpoint discovery and trust are separated.

Boot sequencing is part of security design: Delayed-start services are operationally convenient, but they also widen the window in which a fake endpoint can win. Security teams should treat that window as measurable exposure, especially where the client is a high-integrity or protected process. The lesson is simple: if the wrong process can speak first, the identity programme does not actually control who gets trusted.

For practitioners

• Audit RPC interface registration paths Identify built-in interfaces that unprivileged processes can register through the Endpoint Mapper, then remove or constrain any path that lets non-service code claim a trusted interface.
• Pin server identity where possible Where clients depend on UUID-based resolution, require server identity checks or equivalent binding validation so the client does not trust the first endpoint returned by the mapper.
• Prioritise delayed-start services for review Focus on services that register late in boot, because they are the easiest to beat in an endpoint race and the most likely to be hijacked by a local spoofing process.
• Monitor RPC registration anomalies Alert on unknown processes calling RpcEpRegister for known interfaces and on protected services making RPC connections to endpoints that are not owned by the expected service binary.
• Validate protected-process client behaviour Test whether protected process light clients and high-integrity services will authenticate to a spoofed endpoint before you assume local RPC trust is safe.

Key takeaways

• Windows RPC endpoint poisoning shows that trusted service discovery can become a credential exposure path even when no password or vault is compromised.
• The article demonstrates that low-privilege code can win the registration race, hijack built-in interfaces, and trigger machine-account authentication from privileged Windows clients.
• The limiting control is endpoint identity verification and tighter control over registration timing, especially for delayed-start services and protected-process clients.

Key terms

• Endpoint Mapper Poisoning: An attack in which a client is redirected to a rogue RPC endpoint because the mapper accepts an attacker-controlled registration. The security issue is not the protocol name itself but the assumption that registration order or interface naming proves responder legitimacy.
• RPC endpoint poisoning: A trust manipulation technique in which an attacker registers or wins ownership of an RPC endpoint before the legitimate service does. The result is that clients connect to the attacker-controlled endpoint and may authenticate to the wrong server.
• Protected Process Light: A Windows protection level that restricts how other processes can interact with a sensitive service or component. In this research, the important point is that even protected processes can still become trust targets if the endpoint identity behind their RPC connection is not verified.
• Machine account hash: A cryptographic credential associated with a Windows machine account, often usable in authentication flows. If exposed, it can become a durable NHI secret because it represents system-level identity rather than a human login.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.