NTLM relay explained: coercion, signing, and the fixes that hold

NTLM relay does not crack a password. It borrows a live authentication and forwards it to somewhere that will accept it. Combined with a coercion trick, it is a reliable path to privilege in many AD environments.

How the attack works

The attacker first coerces a machine, often a domain controller, into authenticating to a machine they control, using a vector like PetitPotam or the printer bug. That inbound NTLM authentication is then relayed to a target that does not enforce signing or channel binding, such as LDAP or the AD CS web enrollment endpoint. The relayed authentication is used to make a change, for example configuring resource-based constrained delegation (RBCD) on a computer object, or obtaining a certificate, which the attacker turns into privileged access. In ATT&CK terms this is T1557, Adversary-in-the-Middle, paired with T1187, Forced Authentication.

Why it works

The target accepts a relayed authentication because it does not require the session to be signed or bound to the channel. Coercion supplies the authentication on demand, so the attacker does not have to wait for one.

How to fix it

Enforce SMB signing, and require LDAP signing plus LDAP channel binding on domain controllers. Turn on Extended Protection for Authentication on AD CS web enrollment and other HTTP endpoints. Disable NTLM where you can, and audit where it is still used before you do. Patch the known coercion vectors. Each control removes a different leg of the attack, so apply them together.

Practice it

We built an NTLM relay scenario in GraphLattice Range so administrators see coercion, relay, and the RBCD takeover, then apply the signing and EPA fixes that stop it.