What is the difference between authentication coercion and NTLM relay in an Active Directory attack path?

Authentication coercion forces a target, often a privileged account or service, to initiate authentication to an attacker-controlled system. NTLM relay is the follow-on step that forwards that authentication to another service that accepts it. Coercion creates the credentialed connection, while relay abuses it. Together they can turn a network-only foothold into expanded domain access.

How coercion and relay split the attack path

Authentication coercion and NTLM relay are related, but they are not the same step. Coercion is the trigger that makes a target authenticate outward, usually over a protocol or service path the attacker can influence. Relay is the abuse phase, where the captured NTLM authentication is forwarded to a second service that accepts it. That distinction matters because each step has different prerequisites and different defenses.

Coercion usually depends on a reachable service, a vulnerable workflow, or a protocol feature that can be induced to send an authentication attempt. Relay depends on the target service still accepting NTLM in a way that can be reused without strong channel binding or signing protections. In practice, the first step creates the credentialed connection, and the second step turns that connection into unauthorized access.

The two techniques often appear together in AD attack paths because they convert a network position into an authentication event and then weaponize that event before the session expires. The chain is especially dangerous when the coerced identity has elevated privileges or when the relayed service reaches a higher-value system such as directory services, management interfaces, or internal admin planes.

Why the difference matters for detection and control

Coercion and relay fail in different places, so defenders should not treat them as one generic “NTLM attack.” If you only watch for the relay endpoint, you can miss the coercion mechanism that forced the authentication in the first place. If you only watch for coercion, you can miss the reuse of the resulting NTLM exchange against a separate service. The useful control question is whether the environment allows unsolicited authentication to be induced and then accepted elsewhere.

That is why hardening must address both the source of coerced authentication and the destination service’s acceptance rules. Protocol signing, EPA where available, NTLM reduction, and protocol-level restrictions reduce relay viability; segmentation, service hardening, and removal of unnecessary outbound authentication paths reduce coercion opportunities. For a broader identity-control view, NHIMG’s Active Directory and Entra ID Hardening Guide is useful because it treats NTLM, delegation, privileged groups, and tiering as parts of the same attack surface.

When the path involves privileged users or service accounts, the impact is rarely limited to one endpoint. A coerced authentication from a domain admin, backup service, or management account can be relayed into access that looks legitimate to the destination service. That is why attack-path analysis matters more than isolated event review.

What practitioners should verify in an AD attack path

Authentication coercion tells you how the outbound connection was obtained, while relay tells you how the attacker tried to reuse it. In incident work, that means you should verify three things: the exact protocol used to force authentication, the account that originated it, and the service that accepted the relayed exchange. Without all three, you can miss the real privilege boundary that was crossed.

For practitioners, the most important judgement is whether NTLM is still allowed anywhere that matters. If NTLM remains enabled for high-value services, relay remains a live risk even if coercion is not yet observed. If coercion-capable protocols or services remain exposed, attackers may still be able to create the authentication event they need later. NHIMG’s MFA Guide is relevant here because relay often becomes much more damaging when it is paired with weak legacy authentication and session abuse rather than phishing-resistant sign-in.

In mature environments, the operational goal is not just to detect one-off coerced logons, but to map which services can be induced to authenticate and which destinations still accept relayed NTLM. That inventory is often the difference between a theoretical weakness and a practical domain compromise path. NHIMG’s Identity Security Posture Management (ISPM) Guide helps here because attack-path visibility and standing access are what make these chains visible at scale.

Risk and Threat Considerations

These techniques are dangerous because they exploit trust in internal authentication flows, not just stolen credentials. An attacker can use coercion to make a privileged system authenticate, then relay that authentication into a service that treats the connection as legitimate. The result is often lateral movement or privilege escalation without needing to know the password.

Failure mechanism: A coerced NTLM exchange is accepted by a second service that does not sufficiently bind the authentication to the original channel, target, or service context.

Impact: The attacker can convert an internal authentication event into unauthorized access, often with the privileges of the coerced account and sometimes with domain-level reach.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1187 — Forced Authentication	Covers coercion of a victim system to authenticate to an attacker-controlled host.
	T1557 — Adversary-in-the-Middle	NTLM relay is a classic man-in-the-middle reuse of captured authentication.
	T1021.002 — SMB/Windows Admin Shares	Relayed Windows authentication often targets SMB or administrative Windows services in AD paths.
Recommendation — Hunt for forced-authentication events and restrict services that can be induced to connect outward. Detect and block relay paths with signing, channel binding, and network segmentation. Restrict administrative SMB exposure and require protections that prevent relayed authentication.
NIST SP 800-53 Rev 5	AC-3 — Access Enforcement	Limits what relayed credentials can reach once authentication succeeds.
	IA-5 — Authenticator Management	NTLM relay abuses weak authenticator handling and legacy credential flows.
	SC-23 — Session Authenticity	Channel binding and session integrity directly address relay-style reuse of authentication.
Recommendation — Enforce least-privilege authorization on services that accept Windows authentication. Reduce reliance on legacy authenticators and manage credential lifecycle tightly. Apply session integrity protections where authentication can otherwise be relayed.
ISO/IEC 27001:2022	A.5.15 — Access control	Covers restricting and governing which services can accept legacy authentication.
	A.8.5 — Secure authentication	Secure authentication controls are directly relevant to preventing relay abuse of Windows auth.
Recommendation — Restrict legacy authentication paths to only the services that truly require them. Require stronger authentication methods and harden legacy authentication dependencies.
OWASP ASVS	V10 — OAuth and OIDC	Included only for the generic authentication-hardening principle around token and session handling, which parallels relay-resistant auth design.
Recommendation — Use phishing-resistant, channel-bound authentication patterns where the platform allows them.
OWASP API Security Top 10	API2 — Broken Authentication	Relay succeeds when authentication is accepted in a way the target cannot bind securely to the real client.
Recommendation — Eliminate authentication flows that can be reused or replayed by an intermediary.

Practitioner Guidance

What to prioritise: Treat NTLM relay resistance and coercion resistance as separate control objectives. If either side is weak, the full attack path can remain viable.

What to verify: Check whether high-value services still accept NTLM, whether signing or channel binding is enforced where possible, and whether any protocol or service can still be induced to authenticate to an attacker-controlled host.

Common mistake: Teams often focus on “disabling NTLM” in the abstract, but leave legacy paths, outbound authentication triggers, or exempted services in place. That leaves the chain intact even when the policy looks strong on paper.

Practitioner takeaway: The security question is not whether coercion or relay exists in isolation, but whether your environment still allows an attacker to manufacture an authentication event and reuse it against a more privileged service.