Authentication Coercion Brief
What It Is
Preconditions
Attacker Gain
Mental Model
Attack Workflow
- 1. Obtain valid domain credentials (even a low-privilege account)
- 2. Position a listener: Responder (capture) or ntlmrelayx (relay) on an attacker-controlled host
- 3. Identify the target machine and verify the vulnerable RPC service is reachable
- 4. Invoke the coercion: run PetitPotam, printerbug.py, dfscoerce.py, or Coercer against the target with the attacker's listener host as the path argument
- 5. Target machine authenticates to the listener as its machine account (e.g., DC01$)
- 6. Relay the authentication to a signing-disabled service (e.g., AD CS web enrollment via ntlmrelayx) to obtain a certificate or access token
Key Distinctions from Poisoning
- Trigger: coercion is active and on-demand; poisoning waits passively for a victim to make a name-resolution mistake
- Target selection: coercion lets the attacker choose exactly which machine authenticates, including a domain controller; poisoning captures whoever happens to broadcast
- Authentication source: coercion produces machine account authentication; poisoning typically captures user credentials
- Timing: coercion fires immediately on attacker command; poisoning depends on victim behavior
- Reliability: coercion makes NTLM relay reliable because the attacker forces a connection instead of hoping for one
Interview Answer
Authentication coercion 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 connect to it. The attacker supplies their own host as that path, and the target authenticates with its machine account. The key difference from poisoning is control: the attacker picks exactly which machine authenticates and when, including a domain controller.
On its own, coercion just produces an authentication attempt. The power is in relay: the attacker forwards that authentication in real time to a service that accepts NTLM, like AD CS web enrollment without EPA, or an LDAP endpoint without signing, and authenticates as the coerced machine without knowing its password. That is why coercion is the trigger that makes NTLM relay reliable and why a coerced domain controller can lead to domain compromise.
Stakeholder Explanation
Windows machines are designed to prove their identity automatically when they connect to another computer to access a file. Authentication coercion tricks one of our servers, potentially a critical one like a domain controller, into making 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. On its own it is a stepping stone, but chained with other weaknesses, particularly on services that do not enforce signing, 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 Pitfalls
- Describing coercion as 'the same as Responder poisoning': poisoning is opportunistic and passive; 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; impact comes from what you do with it
- Claiming coercion always works unauthenticated: the original PetitPotam unauthenticated path is largely patched; most coercion requires valid domain credentials
- Forgetting that the captured authentication is a machine account: passwords are long and random, so cracking is usually a dead end; relay is the point
- Treating coercion as a single tool or technique rather than a class across multiple RPC protocols (MS-RPRN, MS-EFSR, MS-DFSNM, and others)
Quality Bar for This Technique
- Explain why coercion works (RPC methods that take path arguments; Windows auto-authenticates to UNC paths)
- State the preconditions accurately (low-privilege domain credentials in most cases; network access to the RPC service; a listener ready to receive)
- Distinguish capture from relay, and explain why relay is almost always the goal for machine account authentication
- Name at least two distinct coercion methods and their underlying protocols
- Explain which defenses target the coercion step versus the relay step, and why signing controls matter most