Authentication coercion and NTLM relay: understanding the risk and reducing it
Among the weaknesses we see most often in Active Directory audits, the "coercion plus NTLM relay" family remains one of the most concerning. It does not rest on a single flaw but on a chain of legacy behaviours and default configurations. That is also why it is addressed through several complementary measures rather than a single fix.
The principle, without the offensive detail
The risk combines two ideas. First, several legitimate Windows services accept being pointed at a network path and then try to connect to it, authenticating with the machine's own identity. This authentication coercion makes a server speak up, including a domain controller, without compromising it. Some variants have well-known nicknames, such as the "printer bug" tied to the print service or PetitPotam tied to the encrypting file system service.
Second, an NTLM authentication is not bound to the service it was meant for. If it is intercepted and forwarded to another service that accepts it, it is honoured there on behalf of the original machine. This is the relay. The attacker does not learn the password: they act under the victim's identity for the duration of the session. The combination of the two can turn a machine identity, sometimes a highly privileged one, into access to a sensitive service.
Why it still works
By default, NTLM does not verify that the service receiving the authentication is the one it was produced for. Many services still accept NTLM, and some require neither signing nor channel binding, which allows forwarding. Finally, a computer account's identity, especially a domain controller's, is inherently privileged. None of these elements is a vulnerability in the strict sense; it is their accumulation that creates the risk.
Two relay targets to watch. The destinations that make this risk critical are usually the web enrolment interface of an AD CS certification authority, which can issue a reusable certificate on the victim's behalf, and the LDAP service on domain controllers, whose privileged access can be used to modify sensitive objects. These are the two to lock down first.
Reducing the coercion surface
You cannot remove every function capable of triggering an authentication, but you can limit its exposure:
- Stop unnecessary services on domain controllers, starting with the print spooler, which has no place there;
- Apply the patches that have neutralised the variants reachable without authentication;
- Filter RPC traffic between non-administrative segments and domain controllers, so that the relevant interfaces are not reachable from an ordinary user workstation;
- Segment the network so that Tier 0 machines are only reachable from controlled administration zones.
Preventing the relay from succeeding
The underlying measure is to reduce the footprint of NTLM, but while it remains, several protections make relaying ineffective:
- Extended Protection for Authentication (EPA) on web services that rely on integrated authentication, including AD CS web enrolment: it binds the authentication to the TLS channel and prevents its reuse elsewhere.
- Disable or remove AD CS NTLM web enrolment when it is not needed, and more generally require HTTPS and a non-relayable authentication on enrolment endpoints.
- LDAP channel binding and signing on domain controllers: an authentication relayed over a channel different from the original is then rejected.
- Required SMB signing, which prevents relaying over that protocol.
- Placing sensitive accounts in Protected Users, which forbids NTLM for those accounts.
These measures deliberately overlap. Leaving just one of them aside is often enough to reopen a path; it is the whole set that closes the chain.
Monitoring what cannot be removed
Some functions will remain exposed. You therefore also need detection: LDAP connections that do not respect channel binding (in audit mode before enforcing), certificate requests inconsistent with a computer account's usual behaviour, NTLM authentications from computer accounts to unexpected servers. Gathered into monitoring, these signals help spot an attempt before it succeeds.
What an audit checks
- Services exposed on domain controllers, in particular the print spooler.
- Patch status covering the unauthenticated coercion variants.
- Whether EPA is in place on integrated-authentication web services and on AD CS web enrolment.
- Whether LDAP channel binding and signing are required on domain controllers.
- RPC filters and network segmentation around Tier 0 machines.
- The overall reduction of NTLM and the presence of sensitive accounts in Protected Users.