You snooze you lose: RPC Racer winning RPC endpoints against services

You Snooze You Lose: RPC Racer — Winning RPC Endpoints Against Services

Speakers: Ron Ben Yizhak

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=vBz8TBVxwk4

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Ron%20Ben%20Yizhak%20-%20You%20Snooze%20You%20Lose%20RPC-Racer%20Winning%20RPC%20Endpoints%20Against%20Services.pdf

Overview

The Windows Remote Procedure Call (RPC) protocol is the backbone of interprocess communication on Windows systems, used by virtually every service in the OS and by countless enterprise applications. At DEF CON 33 — his fourth consecutive year speaking at the conference — Ron Ben Yizhak from SafeBreach presented the results of deep research into the Windows RPC endpoint registration model, revealing a class of vulnerabilities he termed RPC endpoint squatting. The attack allows a low-privileged process to register itself as the handler for an RPC interface that a privileged service expects to own, then exploit the protocol's authentication mechanisms to force the privileged service to authenticate back to the attacker's process, disclosing the machine account's NTLMv2 hash.

The research introduces RPC-Racer, a tool that systematically identifies RPC endpoints vulnerable to squatting and automates the exploitation workflow — racing against the target service to win the endpoint registration before the legitimate service can claim it. The disclosed NTLMv2 machine account hash can then be used for relay attacks, credential cracking, or lateral movement within a domain.

Background

▶ Watch: I also like playing music and going to concerts. (0:32)

RPC Architecture on Windows

Remote Procedure Call (RPC) enables a process (client) to invoke functions in another process (server) as if they were local function calls. On Windows, RPC is pervasive: services like Task Scheduler, Print Spooler, the Certificate Authority service, LSASS, and hundreds of others expose their functionality via RPC interfaces.

Key concepts:

Interface Definition Language (IDL): Both client and server reference an IDL file that defines the interface's data types, function signatures, and — most importantly — a UUID (Universally Unique Identifier) that uniquely identifies the interface.

Binding Handle: Before a client can call an RPC server, it must obtain a binding handle that identifies where the server is listening. A binding handle has three components:

• Protocol sequence: The transport protocol — TCP (ncacn_ip_tcp), Named Pipes over SMB (ncacn_np), or ALPC (Advanced Local Procedure Call, ncalrpc — for local IPC, efficient and secure).
• Network address: The host or endpoint address.
• Endpoint: The specific port or pipe name on which the server listens.

RPC Endpoint Mapper (EPMAP): For dynamic endpoints, servers register their UUID and endpoint with the Endpoint Mapper service (running on port 135). Clients query the Endpoint Mapper to discover where a given UUID is currently listening. For static (well-known) endpoints (e.g., a named pipe with a fixed name), no Endpoint Mapper lookup is needed — the client connects directly.

RPC Runtime Registration: When an RPC server starts, it calls RpcServerUseProtseq (or variants) to declare what protocol sequences it will use, then RpcServerRegisterIf to register its interface UUID, and finally RpcServerListen to begin accepting calls. The endpoint is "owned" by the first process to successfully register the interface and endpoint combination with the Windows RPC runtime.

The Squatting Problem

Ben Yizhak identified that several Windows services register their RPC endpoints lazily — only at first use or upon a specific trigger, rather than at service startup. During the window between OS boot (or service restart) and the moment the legitimate service claims its endpoint, a low-privileged attacker can preemptively register the same endpoint and UUID combination. If the attacker's process wins the race and owns the registration, incoming calls intended for the privileged service will instead reach the attacker's mock server.

This is RPC endpoint squatting — analogous to domain squatting but for Windows IPC endpoints.

Key Findings

▶ Watch: Apparently MSRPC is broken but not that bro (15:21)

1. Multiple Windows services use lazy RPC endpoint registration, creating a race-condition window during which a low-privileged process can claim the endpoint.

1. An attacker-controlled mock RPC server can impersonate the legitimate service's interface, receiving connections from high-privileged callers.

1. RPC's authentication mechanism can be turned against the caller: the attacker's mock server can request NTLM authentication from the connecting privileged service, causing it to send its NTLMv2 hash (the machine account hash in service-to-service scenarios).

1. The machine account NTLMv2 hash is an extremely valuable credential: it can be used for NTLM relay attacks to authenticate to other services in the domain without cracking the hash.

1. RPC-Racer, the released tool, automates both the discovery (identifying which endpoints are squattable) and exploitation (winning the race and capturing the hash) phases.

1. Microsoft was notified and has issued fixes for the specifically reported vulnerabilities; however, the class of issue (lazy endpoint registration) potentially affects third-party software as well.

Technical Deep Dive

▶ Watch: Looking through my vulnerable interfaces list, I found a storage service. (20:48)

Protocol Sequence Deep Dive

Ben Yizhak focused his research on the ALPC (Advanced Local Procedure Call) protocol sequence (ncalrpc), which is the dominant transport for local interprocess RPC on modern Windows. ALPC superseded the older LPC mechanism and provides:

• Kernel-mediated message passing with security descriptor enforcement.
• Support for large messages via shared-memory sections.
• Built-in access control via kernel security objects.

For ALPC-based RPC, the "endpoint" is an ALPC port object in the Windows kernel namespace, typically located at \RPC Control\<endpoint_name>. The port name follows a naming convention (often including the service name or a UUID-derived suffix).

The race condition: ALPC port names in \RPC Control\ are created by the first caller to do so. A low-privileged process that calls NtAlpcCreatePort with the correct port name before the legitimate service does will own the ALPC port, and subsequent connections (including those from the privileged service itself when it attempts to register) may be directed to the attacker's port.

Discovering Squattable Endpoints

RPC-Racer's discovery phase:

1. Enumerates running RPC servers via the RPC Endpoint Mapper and via direct scanning of \RPC Control\ named objects.
2. Monitors which services have registered which UUIDs and under which endpoint names.
3. Restarts or induces service restarts to identify endpoints that are not registered immediately at service startup (lazy endpoints).
4. Cross-references timing data: if an endpoint goes from unregistered to registered only after a specific trigger (e.g., a COM activation, a scheduled task, a client connection attempt), it is a candidate for squatting.

The Authentication Extraction Technique

Once the attacker's mock server owns an RPC endpoint, the exploitation workflow proceeds as follows:

Step 1: Client connects. A Windows service (running as NETWORK SERVICE, LOCAL SERVICE, or as a domain machine account) makes an RPC call to what it believes is the legitimate server at the squatted endpoint.

Step 2: Mock server requests authentication. The attacker's mock server, instead of servicing the RPC call, challenges the client with an NTLM authentication request. Per the RPC protocol, clients that use security-aware binding (which many Windows services do) will automatically respond to the server's authentication challenge using their service account credentials.

Step 3: NTLM response capture. The client sends an NTLMv2 challenge response containing the NTLMv2 hash of the connecting process's account. For services running as the machine account (DOMAIN\COMPUTERNAME$), this is the machine account hash.

Step 4: Hash usage. The captured NTLMv2 hash can be:

• Relayed (via a tool like Responder or ntlmrelayx) to another service — e.g., SMB on another machine in the domain — to authenticate as the machine account. Machine accounts typically have domain-level privileges sufficient for lateral movement.
• Cracked offline (though machine account passwords are 120+ random characters, making cracking impractical).
• Used in a Pass-the-Hash attack if the hash can be used directly (NTLMv2 hashes cannot be used in pass-the-hash directly, but an NTLMv1 downgrade may be possible in some configurations).

RPC Endpoint Mapper Behavior

Ben Yizhak also examined the Endpoint Mapper itself as a potential target. The Endpoint Mapper maintains a table of registered interfaces and their endpoints. He investigated whether the table could be manipulated to redirect clients to an attacker-controlled server without winning the race at the ALPC layer. This line of research identified additional configuration considerations in how services register dynamic endpoints, though the primary disclosed attack path remained the ALPC squatting route.

Scope: Service Accounts and Machine Accounts

The most impactful scenario involves services running as the machine account (COMPUTERNAME$) or a domain service account. When these accounts authenticate to the attacker's mock server, the captured credential has domain scope:

• Machine accounts can write to their own AD object, read many domain objects, and in some configurations execute DCSync.
• Domain service accounts may have delegated permissions (constrained or unconstrained delegation) that enable additional attacks.

Services running as LOCAL SYSTEM do not have network credentials in the traditional sense, but their network representation is the machine account — so the same impact applies.

Demo / Proof of Concept

▶ Watch: escalation by leveraging the active directory certificate service or ADCS. (32:36)

The talk included step-by-step walkthroughs with tooling output:

1. Discovery phase: RPC-Racer scans the local system and identifies a Windows service with a lazy RPC endpoint registration, showing the timing window between boot and registration.

1. Squatting phase: RPC-Racer pre-registers the ALPC port at \RPC Control\<target_endpoint>. The tool displays confirmation that the port is now owned by the attacker's process.

1. Trigger: The legitimate service is triggered (via a standard mechanism, such as calling a COM method that causes the service to activate its RPC component).

1. Connection capture: The service attempts to register its RPC endpoint — or a client attempts to call it — and instead connects to the mock server.

1. Hash capture: The NTLMv2 challenge-response exchange is shown, with the machine account hash displayed in NTLMv2 format.

1. Relay: The hash is relayed (conceptually — the demo showed the hash being passed to a relay tool) to an SMB service on a second machine, demonstrating successful authentication as the machine account.

Defensive Implications

▶ Watch: This means that if we can point it to a direct directory w (41:36)

Mitigation

• Apply Microsoft patches: The specific vulnerabilities reported by Ben Yizhak have been fixed. Organizations should ensure their Windows Update cadence is current.
• NTLM restrictions: Where possible, configure Windows services to require Kerberos for service-to-service authentication. Kerberos is not susceptible to this relay attack because the attacker's mock server cannot produce a valid Kerberos service ticket.
• Enable Extended Protection for Authentication (EPA): For services that support it, EPA binds authentication to the TLS channel, preventing simple relay of captured credentials.
• Restrict machine account authentication: Configure LDAP signing and channel binding. This limits what an attacker can do with a relayed machine account hash.

Detection

• Monitor \RPC Control\ object creation: Tools with Windows kernel event tracing (ETW) capability can log creation of ALPC port objects. Unexpected ports appearing in \RPC Control\ — especially matching names of known Windows services — should trigger investigation.
• Alert on RPC endpoint registration from unexpected processes: If an ALPC port matching a well-known service endpoint is owned by a process other than that service's executable, this is a strong indicator of squatting.
• Detect NTLM authentication from service accounts to unexpected targets: NTLM authentication from machine accounts (logged in the domain controller security event log) to hosts other than known servers is anomalous and should be alerted on.

Vendor Guidance

Third-party software developers who expose RPC interfaces should:

• Register endpoints eagerly at service startup, not lazily.
• Use unique, non-guessable endpoint names derived from a runtime secret rather than static or predictable names.
• Enforce Kerberos-only authentication for privileged service interfaces.

Key Takeaways

• RPC endpoint squatting is a race-condition vulnerability class in Windows IPC: a low-privileged process can claim an RPC endpoint before the legitimate owner, receiving privileged service connections.
• The attack forces high-privileged services to authenticate against the attacker's mock server, disclosing NTLMv2 machine account hashes.
• Machine account hashes enable NTLM relay against other domain resources — a high-impact lateral movement primitive.
• RPC-Racer automates both discovery of squattable endpoints and exploitation, making the research immediately actionable.
• Kerberos enforcement and NTLM restrictions are the highest-impact mitigations; patching alone addresses the disclosed specific endpoints but the class of issue may persist in third-party software.
• This is Ron Ben Yizhak's fourth consecutive DEF CON talk — an indication of sustained productivity in Windows RPC and authentication research.

About the Speaker

Ron Ben Yizhak is a vulnerability researcher at SafeBreach, specializing in Windows internals, authentication protocols, and privilege escalation techniques. He has presented at DEF CON for four consecutive years, building a research portfolio around deep-dive analysis of Windows's IPC and authentication mechanisms. Outside of research, he is a musician and concert-goer. His work on RPC security has produced multiple CVE disclosures and shaped defensive guidance around Windows service authentication hardening.