NTLM relay and coerced authentication expose Active Directory trust gaps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on CrowdStrike's research: NTLM relay combined with coerced authentication can turn a standard domain user into SYSTEM on vulnerable domain controllers.

Why it matters: It matters because Active Directory hardening can still fail when session trust is relayable, so IAM teams need to assess whether signing, binding, and protocol controls actually hold under attack.

Context

NTLM relay is an identity attack pattern in which an authentication exchange is captured and forwarded to another service so the attacker can act as the original identity. In Active Directory, that becomes dangerous when domain controllers accept relayed authentication despite hardening controls that are supposed to prevent impersonation.

This CrowdStrike analysis focuses on the gap between identity policy and protocol reality. The article shows that channel binding and LDAP signing are only effective if they are enforced end to end, because a relay-capable path can still convert a low-privileged foothold into domain controller compromise.

For IAM and AD teams, the important question is not whether the environment has mitigation settings on paper, but whether those settings survive a coercion-and-relay sequence in practice.

Key questions

Q: What breaks when NTLM is still enabled in Active Directory?

A: NTLM preserves a replayable trust path that attackers can abuse once they obtain cached hash material from a compromised endpoint. The result is not just weaker authentication, but a lateral movement path that bypasses password cracking and can turn one host compromise into broader directory access.

Q: Why do channel binding and LDAP signing not fully stop relay attacks?

A: They assume the authentication exchange reaches the intended server intact. If an attacker can force the session, intercept it, and relay it before the trust decision is anchored to the original endpoint, the protections are bypassed in practice. Teams need to test enforcement on the real authentication path, not just confirm that the settings exist.

Q: How can security teams tell whether Active Directory relay protections are actually working?

A: Look for evidence that privileged authentication paths cannot be coerced into outward requests and then reused against LDAP or LDAPS. If a domain controller can be made to authenticate to an attacker listener and the resulting session still succeeds, the control boundary is weaker than the policy suggests.

Q: Should organisations remove NTLM entirely or keep it with compensating controls?

A: If NTLM remains necessary, organisations should treat it as a bounded exception with strong enforcement around signing, binding, and service exposure. Where relayable paths exist on domain controllers, compensating controls may not be enough because the protocol itself can still be shaped into an escalation channel.

Technical breakdown

How coerced authentication creates the relay opportunity

Coerced authentication forces a target system to initiate an outbound login to an attacker-controlled listener. In the article, the example is a domain controller being induced to authenticate through a print spooler-triggered request, which produces a legitimate NTLM exchange that the attacker can capture. The key mechanism is not password theft in the classic sense. It is abuse of the authentication flow itself, where the identity system willingly emits a reusable session exchange. Once the attacker has that exchange, the remaining problem is not access creation but access redirection to a different service.

Practical implication: confirm which internal services can be induced to authenticate outward, not just which credentials are stored.

Why channel binding and LDAP signing do not help if the session is relayable

Channel binding and LDAP signing are meant to tie authentication to a trusted transport and prevent message tampering. In a relay attack, the attacker sits in the middle and forwards the authentication before those protections can do their job, or alters the negotiation so the receiving service accepts the session anyway. This article shows the deeper issue: the control assumes the original peer relationship remains intact. When the exchange is co-opted mid-stream, the trust decision is made on a manipulated session rather than the true initiating endpoint.

Practical implication: verify that signing and binding are enforced on the actual LDAP and LDAPS paths used by domain controllers.

Why a low-privileged user can still become SYSTEM

The escalation comes from the combination of a coerced machine-authentication flow and a relay target that accepts privileged operations from the relayed identity. Once the attacker can reuse the domain controller's authentication context, the machine account privileges associated with that context can be abused to reach SYSTEM-level impact. This is an identity trust failure, not a privilege assignment mistake alone. The environment may look hardened at provisioning time, yet the runtime authentication path still permits a privilege jump that bypasses the intended boundary.

Practical implication: treat relayability as an escalation condition and test it against domain controller authentication paths.

Threat narrative

Attacker objective: The attacker aims to turn a low-privileged foothold into domain controller compromise by abusing relayed authentication.

1. Entry occurs when the attacker gains a low-privileged domain account and reaches a domain controller environment that can be coerced into authenticating outward.
2. Credential access happens when the coerced NTLM exchange is captured by an attacker-controlled listener and prepared for relay.
3. Escalation follows when the authentication is forwarded to LDAP or LDAPS in a way that bypasses channel binding and signing expectations.
4. Impact occurs when the relayed machine account context is used to obtain SYSTEM-level control of the domain controller and threaten the broader Active Directory environment.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication trust is only as strong as the session path that carries it. This article shows that identity controls built around signing and binding can fail when the authentication exchange itself is coerced and replayed. The vulnerability is not merely weak configuration, but the assumption that the original requester and the receiving service remain bound together. For Active Directory teams, that means runtime relayability matters as much as hardening posture.

Channel binding and LDAP signing are not sufficient if the environment still permits coercion. Those safeguards are designed for normal client-server authentication, not for an attacker who can force a privileged host to initiate the session and then redirect it. The control gap is structural: the policy exists, but the authentication flow remains mutable. Practitioners need to test the path, not just the setting.

Identity blast radius in Active Directory is still determined by where machine accounts can be made to speak. When a domain controller can be induced to authenticate to an attacker listener, the machine identity itself becomes the delivery vehicle for privilege escalation. That makes machine-account exposure and relay paths a governance issue, not only a technical exploit detail. The practical conclusion is that AD trust boundaries must be validated against coercion, not assumed from documentation.

NTLM relay remains a living protocol risk because legacy identity flows still privilege convenience over binding. The article reinforces that old authentication paths can survive layered hardening and still provide escalation routes if they are not removed or tightly constrained. That is why NHI governance cannot stop at secret hygiene or account review. It must include protocol-level trust testing across every authentication boundary.

Printer-triggered authentication is a named concept for a broader governance problem: coerced identity emission. When systems can be forced to speak first, identity no longer behaves as a request-response control plane. It becomes an attacker-shaped channel for privilege transfer. The implication is that teams must treat any relay-capable authentication path as part of their identity attack surface, not as a side effect.

What this signals

Identity teams should assume that any relay-capable authentication path expands the attack surface beyond simple credential compromise. The real question is whether the environment can prevent a coerced identity from being replayed into a privileged context. When that answer is uncertain, protocol hardening has to be treated as part of identity governance, not just infrastructure tuning.

NTLM remains a governance problem wherever it survives alongside privileged Windows services. The issue is not only deprecated protocol usage, but the fact that coercion converts normal authentication into attacker-directed delegation. That makes relay testing a recurring control validation exercise for AD and PAM teams.

For practitioners

• Validate LDAP and LDAPS relay resistance Test domain controller authentication paths for channel binding, LDAP signing, and any accepted relay target combinations that still permit redirected authentication.
• Map coercible authentication sources Inventory Windows services and protocols that can be induced to authenticate outward, including spooler-related paths and other callable interfaces on privileged hosts.
• Prioritise domain controller hardening Remove or constrain legacy NTLM-dependent paths on domain controllers before they become the relay endpoint for coerced machine authentication.
• Hunt for anomalous relay patterns Correlate unexpected NTLM authentication flows, altered negotiation flags, and unusual LDAP or LDAPS usage to identify relay attempts in progress.

Key takeaways

• NTLM relay still matters because it can turn a legitimate authentication exchange into an escalation path when coercion is possible.
• The exploit logic depends on a trust assumption failure, not just a missing hardening setting, so AD controls need runtime validation.
• Teams should validate coercion resistance, relay resistance, and privileged service exposure together because they fail as one control surface.

Key terms

• NTLM Relay: NTLM relay is an attack technique where an authenticated challenge-response session is captured and forwarded to another service that accepts it as legitimate. The attacker does not need the password itself, only a reusable authentication exchange that the target will trust.
• Coerced Authentication: Coerced authentication is the act of forcing a system to initiate an outbound login to an attacker-controlled endpoint. In identity attacks, this turns a trusted host into the source of a valid authentication event that can be intercepted, relayed, or manipulated.
• Channel Binding: Channel binding ties an authentication session to the underlying secure transport so that the session cannot be replayed on a different channel. It is a control against relay attacks, but it only helps when the receiving service enforces it consistently.
• Session Signing: Session signing is a control that protects the authenticated session after login by adding integrity checks to traffic. It does not secure the initial authentication exchange itself, so it can reduce tampering but still leave NTLM relay possible if the target accepts unsigned or weakly bound authentication.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.