TTechniqueActive Directory
Authentication Coercion
Authentication coercion forces a target machine to authenticate to an attacker on demand, rather than waiting for a victim to act. This lesson explains why the coercion works, what it gives the attacker when chained with relay or hash capture, and how to communicate the risk clearly in interviews, reports, and stakeholder conversations.
This lesson builds on
Why it matters
Most credential-capture techniques in AD are opportunistic: you poison name resolution and wait for some machine to make a mistake. Authentication coercion flips that. It lets the attacker decide exactly which machine authenticates, and when, including a domain controller, on demand.
That control is what makes coercion a building block for the most impactful AD attack chains. Combined with NTLM relay, a coerced domain controller can be relayed straight into a full domain takeover. In interviews and reports, the distinction between waiting for authentication and forcing it is exactly what separates a candidate who memorized "PetitPotam" from one who understands why coercion is dangerous.
Key Concepts
- Authentication coercion — forcing a remote machine to authenticate to an attacker-chosen host by invoking an RPC method that triggers an outbound connection; unlike poisoning, it does not wait for a user to act
- Machine account authentication — the coerced authentication comes from the computer account (e.g., DC01$), not a user; this matters because machine accounts can be powerful relay targets
- UNC path trigger — Windows automatically authenticates when accessing a UNC path like \\attacker\share; coercion tricks a service into resolving an attacker-controlled path
- Vulnerable RPC methods — functions in protocols like MS-RPRN (PrinterBug), MS-EFSR (PetitPotam), and MS-DFSNM (DFSCoerce) accept a path argument and connect to it, enabling coercion
- Capture vs relay — the coerced NTLM authentication can be captured for offline cracking or relayed in real time to a third system to gain access without ever knowing the password
- Target-centric, not opportunistic — coercion lets the attacker choose exactly which machine authenticates and when, instead of waiting for opportunistic poisoning to catch a victim
Theory
Preconditions
Coercion almost always requires some valid domain credentials, even a low-privilege user or a machine account is usually enough. The historical exception was the original PetitPotam, which before CVE-2021-36942 could coerce unauthenticated, including from domain controllers, but that path is largely closed on current systems.
The attacker needs network access to a vulnerable RPC service on the target machine, reachable over an SMB named pipe such as \PIPE\netdfs, \PIPE\efsrpc, or \PIPE\lsarpc. The attacker also needs a listener, either a hash-capture tool or an NTLM relay tool, positioned to receive the inbound authentication. To coerce HTTP authentication rather than SMB, the target must have the WebClient (WebDAV) service running, which an attacker can sometimes induce remotely.
Why it works
The root cause is a behavior that Windows treats as a feature: when a Windows machine is told to access a UNC path like \\attacker\share\file.txt, it automatically authenticates to that host. Coercion abuses RPC methods that take a file or server path as an argument and then dutifully connect to it.
The attacker calls one of these methods, for example RpcRemoteFindFirstPrinterChangeNotificationEx in the print spooler (PrinterBug); EfsRpcOpenFileRaw or EfsRpcEncryptFileSrv in the encrypting file system protocol (PetitPotam); or NetrDfsAddStdRoot / NetrDfsRemoveStdRoot in the DFS namespace protocol (DFSCoerce), and supplies an attacker-controlled host as the path. The service running on the target obeys, reaches out to the attacker's host, and authenticates with its own machine account along the way. The target never intended to connect to the attacker; it was tricked into it through a legitimate API. Because so many protocols expose path-accepting methods, this is a recurring design pattern rather than a single bug to patch. Tools like Coercer automate the abuse of many such methods at once. The coerced authentication frequently fires before the RPC call would have completed, so tools often print an error like RPC_S_ACCESS_DENIED or ERROR_BAD_NETPATH while the attack has already succeeded.
Once that authentication arrives, the attacker has two choices. They can capture the NTLMv2 response and crack it offline, or they can relay it in real time to a different system that accepts NTLM, authenticating as the coerced machine without ever learning its password.
Attacker gain
What the attacker gains depends on what they do with the coerced authentication and whose authentication it is. Coerced machine-account authentication is most valuable when relayed: relaying a domain controller's authentication to a service that does not enforce signing can yield extremely high-impact outcomes, up to and including domain compromise.
If the authentication is captured instead of relayed, the attacker gets an NTLMv2 hash for offline cracking. Machine account passwords are long and random, so cracking those is usually impractical, which is precisely why coercion is most often paired with relay rather than capture. The headline result is the same: coercion turns a reachable RPC service into attacker-controlled authentication from a machine of the attacker's choosing.
Where it fits
Coercion sits early in an AD attack chain, at the point where an attacker with a foothold wants to escalate by capturing or relaying authentication. It is the trigger that makes NTLM relay reliable: instead of hoping a victim connects, the attacker forces a chosen, often privileged, machine to connect on command.
In practice, coercion is the first move in chains that target Kerberos delegation or AD Certificate Services. The attacker coerces a domain controller, relays its authentication to a vulnerable certificate or delegation endpoint, and obtains credentials or a certificate that grants broad access. It pairs naturally with NTLM relay, AD CS abuse (ESC8), and Kerberos relaying. Understanding coercion as the on-demand trigger for relay is the key to seeing where it belongs in the larger attack.
Tools / examples
- printerbug.py / SpoolSample: abuse MS-RPRN (the print spooler) to coerce SMB or HTTP authentication from a target
- PetitPotam: abuses MS-EFSR (encrypting file system remote protocol); the original version could coerce unauthenticated before CVE-2021-36942
- PetitPotam.py: coerces via MS-EFSR methods; ly4k's fork adds methods beyond the patched ones
- dfscoerce.py: abuses MS-DFSNM
NetrDfsAddStdRoot/NetrDfsRemoveStdRootover the\PIPE\netdfsnamed pipe - Coercer: automates abuse across multiple RPC protocols and methods, with scan, coerce, and fuzz modes
- Responder: captures the coerced NTLMv2 hashes when relaying is not the goal
- ntlmrelayx: receives coerced authentication and relays it in real time to a chosen target
Defender view
- Patch consistently. Many coercion methods (PetitPotam's unauthenticated path, various spooler issues) are addressed by Microsoft patches, but patching only closes specific methods, not coercion as a class.
- Disable the Print Spooler service on machines that do not need it, especially domain controllers, to remove the PrinterBug vector.
- Enforce SMB signing and LDAP signing/channel binding domain-wide. This neutralizes the relay step, which is what makes coercion dangerous.
- Enable Extended Protection for Authentication (EPA) on web-facing services such as AD CS web enrollment to block HTTP relay.
- Restrict inbound RPC and SMB traffic between workstations and to domain controllers so attacker listeners cannot easily receive coerced authentication.
- Disable the WebClient (WebDAV) service where it is not required to remove the HTTP coercion path.
- Monitor for machine accounts authenticating to unexpected hosts and for anomalous RPC calls to the spooler, EFSR, and DFSNM interfaces. Coercion leaves this signature even when the triggering call returns an error.
Communication
Explain it to a stakeholder
Windows machines are designed to automatically prove their identity when they connect to another computer to access a file. Authentication coercion is a trick that forces one of our servers, potentially a critical one like a domain controller, to make that connection to a system the attacker controls, even though the server had no reason to.
The danger is that the attacker can then reuse that proof of identity to log in elsewhere as that server, without ever knowing its password. It turns a wait-and-see attack into a press-a-button attack: the attacker chooses which machine authenticates and when. On its own it is a stepping stone, but chained with other weaknesses it can lead to full control of the environment.
Report language
Finding: Domain Controller Authentication Coercion via MS-EFSR. During the assessment, the operator used valid low-privilege domain credentials to invoke the EfsRpcEncryptFileSrv method on DC01, supplying an attacker-controlled UNC path. This coerced the domain controller to authenticate to the operator's host using its machine account (DC01$). The coerced NTLM authentication was successfully relayed to the Active Directory Certificate Services web enrollment endpoint, which did not enforce Extended Protection for Authentication, yielding a certificate usable to authenticate as the domain controller.
Severity: Critical.
Recommendation: Apply current patches for the affected RPC protocols, enforce SMB and LDAP signing domain-wide, and enable Extended Protection for Authentication on AD CS web enrollment. Disable the Print Spooler service on domain controllers. Restrict inbound RPC/SMB to domain controllers to trusted management hosts.
Common weak answers
- Describing coercion as "the same as Responder poisoning." Poisoning is opportunistic and waits for a victim; coercion is target-centric and forces a chosen machine to authenticate on demand.
- Saying "you run PetitPotam and get Domain Admin" without explaining the relay step. Coercion only produces authentication; the impact comes from what you do with it, almost always relaying it.
- Claiming coercion always works unauthenticated. Only the original PetitPotam did, and that path is largely patched. Most coercion needs valid domain credentials.
- Forgetting that the captured authentication is a machine account. Machine account passwords are long and random, so capturing for offline cracking is usually a dead end. Relay is the point.
- Treating it as a single tool rather than a class of techniques across multiple RPC protocols (MS-RPRN, MS-EFSR, MS-DFSNM, and others).
- Assuming the printed error means failure. Tools routinely show
access deniedorbad netpathwhile the authentication still fired, because the auth happens before the call would complete.
Interview answer
Authentication coercion is a technique that forces a remote Windows machine to authenticate to a host of the attacker's choosing. It abuses RPC methods, in the print spooler, the encrypting file system protocol, the DFS namespace protocol, that take a path argument and then connect to it. The attacker supplies their own host as that path, and the target obeys, authenticating with its own machine account. The key difference from poisoning is control: instead of waiting for a victim, the attacker picks exactly which machine authenticates and when, including a domain controller.
On its own, that just gives you an authentication attempt. The power comes from what you do with it. You relay that authentication in real time to another system that accepts NTLM, like AD CS web enrollment or an LDAP endpoint without signing, and you authenticate as that coerced machine without ever knowing its password. That is why coercion is the trigger that makes NTLM relay reliable, and why coercing a domain controller can lead all the way to domain compromise.
Follow-up questions
- Why is coercion usually paired with relay rather than offline cracking?
- What is the difference between authentication coercion and LLMNR/NBT-NS poisoning?
- Which defenses stop the coercion itself versus which defenses stop the relay step?
- How does enforcing SMB signing change the impact of a coerced domain controller?
- What role does the WebClient (WebDAV) service play in coercing HTTP authentication, and why does that matter for relay?
- Why do coercion tools often report an error like access denied while the attack still succeeded?
