Detect it by watching for unusual MS-EFSRPC activity that coerces a target to authenticate to another host. Look for remote procedure calls from unexpected systems, followed by outbound SMB or NTLM authentication to an attacker-controlled listener. Correlate this with service and security logs on the source host, and block or alert on unexpected remote EFSRPC access.
What makes EFSRPC abuse visible on Windows?
The key signal is a workstation or server making unexpected MS-EFSRPC calls that trigger authentication to a different host. That pattern is unusual because the source should not normally be initiating EFSRPC in a way that causes outbound SMB or NTLM negotiation to an attacker listener. The goal is to spot the coercion chain, not just the individual RPC event.
Detection works best when you treat the RPC activity, the outbound authentication, and the source host logs as one sequence. A single event may look benign, but the combination of remote procedure calls from an unexpected system and a follow-on authentication attempt to an unusual destination is what makes the abuse stand out.
For defenders who need a broader Windows lateral-movement view, the Lateral Movement Guide is useful because it places PetitPotam-style coercion in the same detection family as SMB relay, remote service abuse, and NTLM-based movement paths.
Which logs and signals matter most?
Start with source-host telemetry that can confirm who initiated the RPC activity, when it happened, and whether the host then attempted outbound authentication. Security logs, service logs, and network telemetry should be correlated rather than reviewed separately, because the abuse often looks like ordinary Windows traffic until the authentication side effect is visible.
On the network side, watch for SMB sessions or NTLM handshakes to unexpected listeners, especially when the destination is not a normal file server, domain controller, or management host. If the listener is controlled by the attacker, the important question is whether the source host was induced to authenticate at all, not whether the authentication succeeded.
Because these coercion flows often feed credential abuse and relay, the detection logic should also account for how stolen or coerced authentication material may be reused after the initial event. The Cisco Active Directory credentials leak 2025 is a useful reminder that service and machine credentials are often high-value targets once authentication material is exposed, even when the initial weakness is not a traditional password leak.
How should teams respond when they see this pattern?
If the pattern is confirmed, treat it as a likely precursor to relay or authentication abuse and narrow the exposure window immediately. The most useful response is to validate whether the source host should have been allowed to make that remote EFSRPC request in the first place, then contain the destination listener path and inspect adjacent hosts for similar authentication attempts.
When patching or hardening cannot happen immediately, the practical fallback is to reduce exposure to remote EFSRPC from untrusted systems and block or alert on unexpected coercion behavior. That is more effective than waiting for a single perfect signature, because the abuse path can vary while the underlying abuse pattern, forced authentication from an unusual source, remains the same.
The AD CS Security Guide is relevant here because attackers frequently chain coerced authentication into broader Windows identity abuse, including certificate-based escalation paths, once they have a usable authentication event.
The Encryption Guide is also helpful in a defensive sense: if exposed systems contain sensitive data, the blast radius of a successful follow-on compromise is much lower when data is protected at rest and access paths are tightly bounded.
Risk and Threat Considerations
EFSRPC coercion is dangerous because it turns a remote procedure call into an authentication primitive. That means the weakness is not limited to the RPC service itself, it can become a doorway into NTLM relay, credential capture, or later movement if defenders only look for traditional logon failures.
Failure mechanism: A remote caller abuses MS-EFSRPC behavior to make a target authenticate outward to a chosen host, creating a trust abuse path that can be relayed or harvested.
Impact: The resulting authentication event can support relay, privilege escalation, service compromise, or broader lateral movement if the source host is trusted in the wrong place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021 — Remote Services | Covers remote service abuse and authentication-driven lateral movement seen in EFSRPC coercion. |
| T1134 — Access Token Manipulation | Relevant when coerced auth is reused to obtain or abuse access for movement or escalation. | |
| Recommendation — Map the event to remote-service lateral movement and hunt for follow-on authentication abuse. Correlate coerced authentication with privilege-changing activity and token abuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | EFSRPC abuse hinges on coerced authentication and trust abuse across Windows systems. |
| NHI-05 — Overprivileged NHI | Stolen or coerced Windows identities can be overprivileged and amplify lateral movement impact. | |
| Recommendation — Review authentication paths that can be coerced and restrict unexpected remote auth flows. Reduce privilege on service and machine identities that could be abused after coercion. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on correlating service, security, and network logs into one reviewable event chain. |
| AC-17 — Remote Access | Unexpected remote EFSRPC access is a remote-access control problem and should be constrained. | |
| Recommendation — Correlate audit records across host and network telemetry to validate the abuse sequence. Restrict remote access paths that can trigger coercive Windows authentication. | ||
Practitioner Guidance
What to verify: Confirm that the source host should ever be initiating that EFSRPC activity to the destination you observed. If the answer is no, treat the event as a malicious coercion attempt even if no downstream compromise is proven yet.
What to prioritize: Correlate RPC, SMB, and NTLM telemetry first, then move to host-level service and security logs. The correlation is what distinguishes a weird Windows event from an actionable abuse chain.
Common mistake: Teams often hunt only for the listener or only for the authentication event. For this technique, the sequence matters, and losing either side of the chain weakens detection quality.
Practitioner takeaway: The strongest detection is behavioral, not signature-only: catch unexpected MS-EFSRPC-triggered authentication from a source host, then decide quickly whether that host should have been able to make the request at all.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-32706 (Microsoft Windows Common Log File System (CLFS) Driver Heap-Based Buffer Overflow)?
- How do you patch or mitigate CVE-2025-32701 (Microsoft Windows Common Log File System (CLFS) Driver Use-After-Free)?
- How do you patch or mitigate CVE-2025-29824 (Microsoft Windows Common Log File System (CLFS) Driver Use-After-Free)?
- How do you patch or mitigate CVE-2024-49138 (Microsoft Windows Common Log File System (CLFS) Driver Heap-Based Buffer Overflow)?