Topic starter
02/08/2026 12:32 pm
TL;DR: An RPC endpoint mapper weakness let a low-privilege process race built-in Windows services, masquerade as a trusted RPC server, and force protected processes to authenticate to an attacker-controlled endpoint, exposing the machine account NTLM hash, according to SafeBreach. The finding shows that client-side trust assumptions in inter-process identity can be abused long before conventional access controls have a chance to respond.
Editorial analysis by NHI Mgmt Group, based on content published by SafeBreach: “You Snooze You Lose: RPC-Racer Winning RPC Endpoints Against Services”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Windows RPC endpoint poisoning shows that trusted service discovery can become a credential exposure path even when no password or vault is compromised.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:29 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Windows RPC endpoint poisoning exposes machine-account authentication