Windows RPC endpoint poisoning exposes machine-account authentication

At a glance

What this is: This is a Windows RPC research post showing how endpoint mapper poisoning can redirect protected clients to a rogue server and leak machine-account authentication material.

Why it matters: It matters because identity controls cannot rely on service naming or registration order alone when privileged processes may trust an endpoint before its identity is verified.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read SafeBreach's analysis of RPC endpoint mapper poisoning in Windows

Context

Windows RPC is the inter-process communication layer that lets services and clients discover and talk to each other by interface UUID and endpoint. In this research, the core problem is not traditional malware execution but trust in a registered endpoint before the client has verified that the server behind it is the real one.

For identity teams, that matters because the machine account, service context, and protected process all become part of the security boundary. If a client accepts the first matching endpoint from the mapper, the identity decision has already been made too early for ordinary access governance to correct it.

The article is therefore about a governance gap inside a foundational operating-system identity path, not just a bug in one service. The starting point is atypical in one respect, but the control failure it exposes is a familiar one: trust established by order of registration rather than by cryptographic or policy verification.

Key questions

Q: What breaks when a Windows RPC client trusts the first endpoint it receives?

A: The client can connect to a rogue server that only looks legitimate because it registered first. That breaks endpoint identity, not just availability, and can expose authentication context from protected processes. In practical terms, trust has been delegated to registration order instead of verified server identity, which is unsafe for any privileged RPC path.

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 do security teams know if RPC interface registration is being abused?

A: Look for unexpected processes calling RpcEpRegister for interfaces that belong to built-in Windows services, especially during boot. Pair that with event tracing and process lineage so you can see when a low-privilege process is standing in for a system component and receiving client connections.

Q: Who is accountable when a protected process authenticates to a fake RPC server?

A: Accountability sits with the operating-system trust boundary and the teams that own service identity, client verification, and hardening of privileged IPC paths. If a protected process can authenticate to an unverified endpoint, then the governance failure is in the control design, not only in the attacker technique.

Technical breakdown

How RPC endpoint mapper poisoning works

Windows RPC uses an endpoint mapper to resolve an interface UUID to the endpoint a server registered. If a client asks for a UUID without an explicit endpoint, the mapper returns the first matching registration, which becomes the trust anchor for that connection. The research shows that an unprivileged process could register a known built-in interface early enough in boot to win that race. Once that happens, clients connect to the attacker-controlled server even though the interface name and UUID look legitimate.

Practical implication: any client path that trusts first registration without verifying server identity needs specific review.

Why service timing and delayed start create exposure

The attack depended on startup timing because delayed-start services register after the attacker can race the mapper. That means the weakness is not only in interface lookup but in the assumption that system services will always register before anything else can claim their identity. In RPC, this is especially dangerous for services that are expected to support protected processes or system components, because the trust decision can happen before higher-integrity code has a chance to validate the responder.

Practical implication: review delayed-start RPC services as identity exposure windows, not just reliability choices.

Protected process trust and NTLM disclosure

Once a protected process connected to the rogue server, the attacker could coerce authentication and, in the successful path described, obtain the machine account NTLM hash. That moves the issue from spoofing to credential exposure, because the machine account is a durable identity that can be reused elsewhere if not contained. The important technical point is that the protocol allowed a low-privilege process to present as a trusted service early enough to influence a privileged client.

Practical implication: treat machine-account authentication paths as sensitive NHI trust boundaries, not as routine IPC traffic.

Threat narrative

Attacker objective: The attacker wants to impersonate a trusted RPC service long enough to coerce authentication from protected Windows clients and capture reusable machine-account credentials.

1. Entry occurred when a low-privilege process registered a trusted Windows RPC interface with the endpoint mapper before the legitimate service did.
2. Escalation occurred when protected and high-integrity clients connected to the rogue endpoint and exposed authentication context to the attacker-controlled server.
3. Impact occurred when the attacker forced machine-account authentication and disclosed the NTLM hash, creating potential for broader privilege abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Endpoint registration order is not an identity control. This research shows that the endpoint mapper accepted the first matching registration, even when the responder was not the legitimate built-in service. That is a structural failure in protocol trust, not just a hardening gap. For identity programmes, the lesson is that naming and registration are not proof of authority.

Protected-process trust should be treated as an NHI governance problem. The moment a protected process authenticates to an unverified endpoint, the machine account becomes part of the attack surface. This is the same governance problem practitioners already face with service accounts and workload identities: identity reuse without responder verification creates a credential-exposure path. The implication is that IPC trust must be governed like any other non-human identity boundary.

Identity blast radius is created before privilege escalation begins. The attacker did not need admin rights to win the mapper race, only timing and protocol knowledge. That means the initial control failure was upstream of privilege escalation, in the trust decision that allowed an unknown process to stand in for a system service. Practitioners should read this as a reminder that blast radius starts at discovery and registration, not at the final credential theft step.

Delay-start services create a runtime governance gap. Services that register late expand the window in which a hostile process can claim their interface and shape downstream trust. That timing window is an operational assumption, not a security guarantee. The practical conclusion is that service launch order, registration behaviour, and client-side verification all belong in the same governance conversation.

Windows RPC shows why NHI identity controls must cover internal service-to-service trust. This attack did not rely on an external login prompt or a human click. It succeeded by abusing machine-to-machine identity resolution inside the operating system, which is exactly where many identity programmes still have the least visibility. The field should treat internal protocol identity as first-class NHI governance, not as an implementation detail.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and sometimes within 9 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• The NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding reduce the identity windows that endpoint-poisoning attacks exploit.

What this signals

Endpoint identity now needs to be treated as part of NHI governance, not just protocol hardening. The practical change for security teams is that service registration, client verification, and machine-account authentication all need the same lifecycle discipline used for other non-human identities. When an internal protocol can be poisoned, the control gap is not visibility alone, but the assumption that identity proves itself through registration order.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is moving toward controls that track machine trust boundaries more explicitly. This kind of RPC abuse reinforces why internal service identity, not just external secrets, belongs in the NHI roadmap.

Identity blast radius will increasingly include internal operating-system paths. The next maturity step is to tie lifecycle management to service launch timing, privileged IPC monitoring, and responder verification so that a trusted interface cannot be impersonated before the real service arrives.

For practitioners

• Map RPC interfaces that register late in boot Inventory services that depend on delayed start and note which interfaces are claimed only after core system startup. Those are the windows where endpoint mapper races are most plausible and where unknown processes can win registration before the legitimate service appears.
• Verify server identity before accepting RPC endpoints Review client paths that trust a UUID-to-endpoint resolution without an explicit server-authentication check. Where possible, require stronger identity validation than first registration order, especially for system services that receive authentication material or run in protected contexts.
• Monitor for unexpected RpcEpRegister activity Detect non-standard processes calling RpcEpRegister for known built-in interfaces and correlate that activity with boot timing, service creation, and subsequent client connections. Unknown registration of trusted interfaces is the earliest practical sign of endpoint poisoning.
• Contain machine-account credential exposure paths Treat any RPC flow that can coerce machine-account authentication as sensitive NHI infrastructure. Reduce downstream reuse, isolate the account where possible, and validate whether protected processes ever send authentication to endpoints that were not cryptographically or policy verified.

Key takeaways

• Windows RPC endpoint poisoning shows that a trusted interface name is not the same as a trusted server identity.
• The research demonstrates that a low-privilege process can win the registration race, coerce protected clients, and expose machine-account authentication material.
• Verified responder identity and tighter control of delayed-start services are the controls that would have narrowed this attack path.

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.
• 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 NTLM Hash: A reusable authentication artifact tied to a Windows machine identity. If disclosed, it can enable downstream abuse of that device or service identity, which is why coercing machine-account authentication is a serious non-human identity exposure.

What's in the full report

SafeBreach's full research covers the operational detail this post intentionally leaves for the source:

• The step-by-step EPM poisoning technique and how the race against built-in services was won in practice.
• The exact RPC interfaces and service behaviours that were observed to be vulnerable during boot.
• The detection methods using ETW and RpcEpRegister monitoring that help distinguish legitimate from rogue registrations.
• The patch response and the residual exposure in other RPC clients and interfaces that may still be reachable.

👉 The full SafeBreach post covers the exploit path, detection ideas, and patch context in detail.

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 building or maturing an identity security programme, it is worth exploring.