Subscribe to the Non-Human & AI Identity Journal
Threats, Abuse & Incident Response

NTLM Relay

← Back to Glossary
By NHI Mgmt Group Updated May 26, 2026 Domain: Threats, Abuse & Incident Response

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.

Expanded Definition

NTLM relay is a credential forwarding attack against Microsoft environments, where an attacker intercepts an NTLM authentication exchange and passes it to another service that will accept it. The attacker does not crack the password; they reuse the authentication flow itself.

Definitions vary across vendors on how broadly NTLM relay is grouped with man-in-the-middle activity, but in NHI and IAM operations the practical distinction is simple: the session is valid, the trust decision is flawed. That is why NTLM relay is closely tied to weak signing settings, exposed SMB or LDAP services, and unmanaged service identities rather than just “bad passwords.” NIST Cybersecurity Framework 2.0 is useful here because it frames identity and access as a governance problem, not only an authentication event. For teams managing machine-to-machine access, the attack often becomes possible when legacy NTLM is still allowed while stronger controls such as signing, channel binding, or Zero Trust enforcement are missing.

The most common misapplication is treating NTLM relay as a password theft problem, which occurs when defenders focus on resets instead of the exposed authentication path.

Examples and Use Cases

Implementing relay resistance rigorously often introduces compatibility constraints, requiring organisations to weigh legacy interoperability against stronger authentication controls.

  • An attacker coerces a workstation to authenticate to a malicious listener, then relays the captured exchange to LDAP to add a privileged directory object. This pattern is discussed in real-world breach analysis such as the Cisco Active Directory credentials breach.
  • A file server accepts relayed SMB authentication because message signing is disabled, allowing unauthorized access without knowing the underlying password. Microsoft environments that still depend on NTLM without compensating controls are especially exposed.
  • A relay targets an internal web application or management interface that trusts integrated Windows authentication but does not require channel protection. The result is access that appears legitimate to the service.
  • A SOC validates whether service accounts are using NTLM at all, then plans a migration path to stronger identity controls aligned with NIST Cybersecurity Framework 2.0 and modern Zero Trust guidance.
  • A red team demonstrates that local administrator credentials are unnecessary when coercion plus relay is enough to reach a trusted target, which helps stakeholders understand why authentication transport matters as much as credential strength.

In practice, NTLM relay is less about one tool and more about a chain of assumptions that trust an inbound authentication exchange without verifying its provenance.

Why It Matters in NHI Security

NTLM relay matters in NHI security because non-human identities often authenticate automatically, repeatedly, and with broad privileges. If a service account, API-adjacent host process, or automation endpoint can be induced to authenticate over a relayable path, the attacker can pivot into systems that were never meant to receive that trust. This is exactly the kind of hidden exposure that makes NHI risk hard to see at scale, especially when organisations still lack full visibility into service accounts. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into their service accounts, which means relay-prone authentication paths can sit unnoticed until they are abused. That visibility gap is compounded when secrets, permissions, and legacy protocols are managed separately instead of as one identity surface.

For governance teams, the fix is not only patching a server. It usually includes reducing NTLM usage, enforcing signing where possible, constraining privileged service paths, and validating that NHI authentication flows align with NIST Cybersecurity Framework 2.0 and Zero Trust assumptions. The breach lesson is reinforced by the Cisco Active Directory credentials breach, where identity trust became an attack path rather than a control. Organisations typically encounter NTLM relay only after a lateral movement event or directory compromise, at which point the authentication model itself becomes operationally unavoidable to address.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02Covers weak secret and authentication handling that enables relayable sessions.
NIST CSF 2.0PR.AC-1Identity and access control practices govern who and what can authenticate to services.
NIST Zero Trust (SP 800-207)Zero Trust rejects implicit trust in an authentication exchange just because it succeeded.

Reduce relay exposure by hardening NHI authentication paths and removing unnecessary NTLM trust.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on May 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org