NTLM relay is one of the most powerful techniques on an internal network, and coercion is what makes it reliable. Together they let you take an authentication that belongs to someone else — often a domain controller's own machine account — and use it against a service that will honour it. This page explains the whole chain: how authentication is captured or forced, how it is relayed, and why the defences are exactly the three controls they are.
Why relay works at all
NTLM is a challenge-response protocol. When a client authenticates, it proves knowledge of its NT hash by answering a server-issued challenge — it never sends anything you can simply replay. But it also has no inherent binding between the authentication and the specific connection it was meant for. So if you can get in the middle, you can take the client's response to your challenge and present it to a different server, authenticating as the client there.
That is relaying. You are not cracking anything and not replaying a static credential — you are a live man-in-the-middle forwarding a valid authentication to a target of your choosing, while it is still fresh.
Getting the victim to authenticate
Relaying needs a victim to authenticate to you in the first place. There are two ways to arrange that: wait for it (poisoning) or force it (coercion).
Poisoning — LLMNR/NBT-NS
When a Windows host fails to resolve a name over DNS, it broadcasts the query to
the local segment over LLMNR, NBT-NS, or mDNS: "does anyone know where
FILESERVR is?" (note the typo — mistyped and stale names are constant).
Responder answers "yes, it's me", the victim connects
and authenticates, and you have its NetNTLM. This is opportunistic — you catch
whatever mistakes happen on the wire.
Coercion — forcing the callback
Coercion is deterministic. Certain RPC methods, by design, make a target connect to a path you specify — and when it connects, it authenticates, as its machine account. You do not wait for a mistake; you call the method and the target authenticates on command.
| Method | Protocol |
|---|---|
| PrinterBug | MS-RPRN — the print spooler's change-notification RPC |
| PetitPotam | MS-EFSRPC — the Encrypting File System remote protocol |
| DFSCoerce | MS-DFSNM — DFS namespace management |
| ShadowCoerce | MS-FSRVP — the File Server VSS agent |
Coercer automates all of these, firing every known method so that one missing patch or hardening is enough. Coercing a domain controller is the prize, because a DC's machine account is a high-value identity to relay.
Where you relay to
Relaying only succeeds where a specific protection is missing on the target. This is the whole game — enumerate the missing protections first, then relay to those.
| Relay target | Requires | Yields |
|---|---|---|
| SMB | SMB signing NOT required on the target | SAM/LSA dump, command execution |
| LDAP / LDAPS | Channel binding / signing off | RBCD setup, Shadow Credentials, DCSync rights |
| AD CS web enrolment (ESC8) | EPA not enforced on the CA web endpoint | A certificate as the victim → a TGT |
| HTTP (other) | Varies by endpoint | Application-specific access |
You cannot relay an authentication back to the host it came from — that was fixed long ago. The whole point is to relay elsewhere: coerce host A, relay its auth to host or service B.
The two highest-impact chains
ESC8 — DC to AD CS to domain compromise
The current king of relay chains. Coerce a domain controller into authenticating to you, relay that machine-account authentication to the AD CS web enrolment endpoint, and request a certificate as the DC. A certificate can be used for Kerberos PKINIT, so you turn it into a TGT for the DC — and a DC's TGT is effectively the domain.
RBCD via LDAP
Relay a machine account's authentication to LDAP and configure resource-based constrained delegation so that a computer account you control is allowed to impersonate any user to the coerced machine. Then request a service ticket as Administrator and walk in. See Delegation for the RBCD mechanism.
Both chains, with the exact ntlmrelayx / coercion / Certipy commands, are documented in the Vulns & Misconfigs section under NTLM Relay (and the target-side misconfigurations SMB Signing Not Required and LLMNR / NBT-NS Poisoning). This page is the mechanism they exploit.
Capture versus relay
When you poison with Responder, you choose one of two modes. In capture mode, Responder's own SMB/HTTP servers accept the authentication and log the NetNTLM hash for offline cracking. In relay mode, you turn Responder's SMB and HTTP servers off so ntlmrelayx can take the authentication and forward it live. Capture is for crackable passwords; relay is for when the hash is uncrackable but the identity is useful.
Detection and defence
| Control | What it stops |
|---|---|
| Require SMB signing | Breaks SMB relay outright — the single most important control |
| Enforce LDAP channel binding & signing | Closes the RBCD and Shadow Credential relay paths |
| Enable EPA on AD CS web enrolment | Kills the ESC8 chain |
| Disable the Print Spooler on DCs | Removes the PrinterBug coercion vector |
| Disable LLMNR / NBT-NS | Removes the poisoning opportunity Responder relies on |
| Patch coercion methods | Reduces the set of RPC methods Coercer can fire — though new ones keep appearing |
The takeaway
The chain is always the same shape: make someone authenticate to you (poison or coerce), then forward that authentication to a service missing its relay protection. Coercing a domain controller and relaying to AD CS is the headline path because it converts a machine account's authentication into a domain-controlling certificate. Every defence maps to one link in the chain — signing, channel binding, EPA, spooler, LLMNR. The tools live in the Toolkit Vulns & Misconfigs (Responder, Coercer, ntlmrelayx, krbrelayx); the protocol background is on the NTLM and AD CS pages.