PetitPotam (MS-EFSR Abuse)

How PetitPotam Works as an Authentication Coercion Technique

PetitPotam abuses the Microsoft Encrypting File System Remote Protocol to make a target system initiate authentication to a chosen listener. That matters because the attacker is not breaking cryptography here, they are manipulating a legitimate trust path to create a credential relay opportunity.

The technique is most dangerous when the coerced authentication can be captured and forwarded into a second protocol or service that still accepts NTLM-based trust. In practice, the attack chain turns a forced outbound authentication into a stepping stone for escalation, certificate abuse, or broader lateral movement.

Why Forced Authentication Is Valuable to Attackers

Coercion techniques are attractive because they can convert a reachable Windows system into an authentication source without needing the user to click anything. That makes them useful in environments where NTLM remains enabled, where inbound restrictions are weak, or where internal systems can reach attacker-controlled or compromised listeners.

PetitPotam is especially effective when paired with relay-friendly services and misconfigured enterprise certificate services. For readers mapping the downstream abuse path, NHIMG’s AD CS Security Guide explains how certificate services become a high-value target once authentication is relayed into enrollment or mapping abuse.

The same pattern also sits naturally alongside lateral movement tradecraft. NHIMG’s Lateral Movement Guide covers NTLM relay and the adjacent Windows movement techniques that often appear once an attacker has coerced a machine to authenticate outward.

How Organizations Check Exposure and Reduce the Attack Surface

Exposure review starts with knowing where the protocol is reachable, which systems can initiate outbound authentication, and which internal services still accept relayable authentication flows. That usually means pairing asset inventory with segmentation review, outbound traffic visibility, and a hard look at systems that expose coercion-prone Windows interfaces.

Defenders should also check vendor guidance for the relevant Windows components and any hardening changes that affect NTLM, certificate enrollment, and remote procedure call exposure. The practical question is not just whether the vulnerability exists in theory, but whether the environment still permits the trust path the attacker needs.

At a control level, reducing standing trust and tightening network paths matter more than relying on a single detection rule. NIST’s NIST SP 800-207 Zero Trust Architecture is useful here because its least-privilege and segmentation model directly supports reducing reachable coercion paths.

For broader control mapping, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control vocabulary for authentication, logging, configuration management, and access restriction around the systems most likely to be abused.

Detection, Remediation, and Post-Exploitation Review

Detection should focus on unusual outbound authentication from servers or high-value endpoints, especially when the destination host is unexpected, newly observed, or outside normal administrative workflows. Alerting becomes more useful when it is correlated with NTLM usage, unusual certificate enrollment, or subsequent privilege changes.

When exploitation is suspected, response is not only about blocking the original coercion path. Teams should review whether relay succeeded, whether certificates or mapped identities were issued, and whether the attacker obtained durable access through a newly trusted authentication channel.

Because relay often creates identity impact, the post-incident review should include credentials, sessions, keys, and service accounts associated with the affected path. The relevant work is often to identify what the attacker could reuse after the initial coercion, not just to close the initial protocol exposure.

Risk and Threat Considerations

PetitPotam is risky because it turns a legitimate Windows authentication mechanism into an attacker-controlled relay opportunity. The main exposure is not the coercion itself, but the trust abuse that follows when a forced authentication is accepted by another service that still treats the session as credible.

Failure mechanism: A system is induced to authenticate to a listener the attacker controls, and that authentication is relayed into a second service or workflow that accepts it as proof of trust, enabling escalation or certificate abuse.

Impact: Attackers can gain elevated access, forge a stronger identity posture through abused certificate services, or pivot into broader lateral movement if relay succeeds and the resulting access is not detected.

Practitioner Guidance

What to watch for: Treat unexpected outbound authentication from servers as a high-signal event, especially when the destination is internal but unusual, or when the source host is not expected to initiate that kind of trust relationship. That signal is stronger when it appears near certificate enrollment, NTLM relay indicators, or privilege changes.

Governance implication: Ownership should span Windows hardening, network segmentation, and identity operations, because the attack path crosses all three. The useful decision is not “patch or not,” but whether the environment still allows coercion paths that can be relayed into trusted authentication.

Practitioner takeaway: Reduce relayability, not just exposure to the original trigger, because the attacker’s value comes from what the coerced authentication can become next.

Related resources from NHI Mgmt Group

• What are the signs that an environment is exposed to PetitPotam-style abuse?
• What should security teams do first when Follina-style ms-msdt abuse is suspected on Windows endpoints?
• DFSCoerce (MS-DFSNM Abuse)
• What is privilege inheritance abuse in Agentic AI?