NTLM Relay Guide: Detecting and Preventing Relay Attacks

NTLM relay lets an attacker who can intercept or coerce a Windows authentication pass it on to a different server and act as the victim, without ever learning the password. NTLM relay is an adversary-in-the-middle technique against the NTLM challenge-response protocol, catalogued by MITRE ATT&CK as T1557.001 Name Resolution Poisoning and SMB Relay. This guide explains the idea at concept level, then concentrates on what defenders control: SMB signing, LDAP signing and channel binding, Extended Protection for Authentication (EPA), reducing and blocking NTLM, and Microsoft's NTLM deprecation path. It is written for Windows, Active Directory and detection engineers who need to close relay paths without breaking production. It deliberately contains no attack tooling or procedures.

Key takeaways

• Relay abuses a missing binding, not a weak password. NTLM does not tie an authentication to the server it was meant for, so a valid exchange can be forwarded to another service.
• Signing and channel binding break the chain. Required SMB signing, LDAP signing, LDAP channel binding and EPA on HTTP services make a relayed authentication useless at the target.
• Windows defaults are moving, but slowly. Windows 11 24H2 and Windows Server 2025 require SMB signing in more cases, Server 2025 turns on EPA for AD CS and LDAP channel binding in "When Supported" mode, and NTLMv1 is removed. Older servers need manual configuration.
• The long-term fix is less NTLM. Microsoft has deprecated all NTLM versions and advises replacing NTLM calls with Negotiate so Kerberos is used wherever possible.
• Audit first, then enforce. Every control here has an audit mode or event trail. Use it to find legacy dependencies before you require anything.

What it is

NTLM is Microsoft's legacy challenge-response authentication protocol. The server sends a challenge, the client answers with a response computed from the user's password hash, and the server (or a domain controller on its behalf) checks the answer. The password itself is never sent, which is good, but the exchange does not cryptographically name the server the client intended to reach. That gap is what relay exploits.

In an NTLM relay, an adversary positioned between a client and a server (or able to make a client connect to them) forwards the client's authentication messages to a third system. If that third system accepts NTLM and does not check signatures or channel bindings, it treats the adversary's session as the victim's. ATT&CK describes this under T1557.001: adversaries can spoof name resolution answers (LLMNR on UDP 5355, NBT-NS on UDP 137, mDNS on UDP 5353) to draw authentication to themselves, and NTLMv1 or NTLMv2 exchanges "can be intercepted and relayed" to protocols such as SMB, LDAP, MSSQL and HTTP. Related techniques are T1187 Forced Authentication, where a system is made to authenticate outward, and T1550.002 Pass the Hash, which reuses captured hash material rather than a live exchange.

How it works

At concept level, a relay needs three things to line up. Each one is a place a defender can intervene.

1. An authentication reaches the wrong party. A client sends NTLM to an adversary because of poisoned name resolution, a malicious UNC link, a coerced machine account, or a client that falls back to NTLM when Kerberos fails (for example when a share is reached by IP address or a CNAME, which Microsoft notes forces NTLM).
2. The adversary forwards it to a target that accepts NTLM. Microsoft's December 2024 MSRC post names Exchange Server, Active Directory Certificate Services (AD CS) web enrolment and LDAP on domain controllers as the services most often targeted.
3. The target does not verify where the authentication was meant to go. Without SMB signing the session cannot prove message integrity with a key the adversary lacks. Without LDAP channel binding or HTTP EPA the target cannot tell that the TLS channel the client authenticated over is not the one in front of it.

The most damaging outcomes come from relaying privileged machine or service accounts. A domain controller's or server's computer account relayed to AD CS or LDAP can lead to certificates or directory changes that give domain-wide control, which is why Microsoft prioritised EPA on those services. See the AD CS Security Guide.

Why it matters

Relay turns one foothold on an internal network into authenticated access elsewhere, often as a machine or service identity nobody watches closely. It needs no malware on the target and no password cracking, and it hides inside ordinary authentication traffic. Machine accounts, service accounts and scanning tools that authenticate automatically are prime sources, so this is as much a non-human identity problem as a network one. See the Lateral Movement Guide.

Prevention controls by target

Choosing between controls

• Signing and channel binding first: they protect the high-value targets quickly and rarely affect modern Windows clients. Start with domain controllers (LDAP), AD CS and Exchange.
• "When Supported" versus "Always": When Supported lets clients that cannot send channel binding tokens continue, so it leaves a gap for exactly those clients. Microsoft describes Always as the stronger option where no legacy clients remain. Move to Always once events 3039 show no remaining failures.
• Blocking NTLM: the most complete fix but the most disruptive. Smaller organisations with few appliances can often reach it in months; large estates with printers, NAS devices, non-domain systems and old line-of-business apps should expect a long exception list and plan per application.
• Disabling LLMNR and NBT-NS: low risk where DNS is healthy, and it removes a common way authentication is drawn to the wrong host, but it does not stop coercion, so it complements signing rather than replacing it.

Safe rollout

1. Inventory NTLM use. Enable Restrict NTLM: Audit NTLM authentication in this domain on domain controllers and collect the NTLM operational log (Applications and Services Logs\Microsoft\Windows\NTLM) centrally. Restrict who can read it, because it maps legacy weak points.
2. Turn on LDAP diagnostics. Set the 16 LDAP Interface Events diagnostic level to 2 on DCs and collect events 2887, 2889, 3039, 3040, 3041, 3074 and 3075 to find clients that bind unsigned or without channel binding.
3. Pilot on a ring. Require SMB signing, LDAP signing and channel binding (When Supported) on a test DC, a test CA and a pilot group of servers. Watch for STATUS_INVALID_SIGNATURE (0xc000a000) on SMB clients and failed binds on LDAP.
4. Fix or isolate the stragglers. Update appliances or contact vendors, replace guest-access shares, move scripts and services to Kerberos (use names, not IP addresses), and remove NTLMv1 by setting LAN Manager authentication level to "Send NTLMv2 response only. Refuse LM & NTLM".
5. Enforce in waves. Domain controllers and AD CS first, then Tier 0 and Tier 1 servers, then workstations. Move channel binding and EPA to Always where audit is clean.
6. Roll back by policy, not by hand. Every setting here is a Group Policy or registry value; keep the previous GPO version so a failing ring can be reverted in one change, and record each exception with an owner and expiry date.

Detection and measurement

• Event 4624 analysis: monitor network logons where Authentication Package is NTLM, especially for privileged and computer accounts, and alert when Package Name (NTLM only) is "NTLM V1" or "LM". Microsoft also advises flagging NTLM logons with Key Length other than 128. See the Windows Event Log Guide.
• Source mismatch: a computer account authenticating with NTLM from an IP address that is not that computer is a strong relay signal.
• Name resolution traffic: LLMNR, NBT-NS and mDNS responses from unexpected hosts, where those protocols are still present (ATT&CK M1031, network intrusion prevention).
• Directory and CA activity: unexpected certificate requests by machine accounts and directory changes made over NTLM sessions.

Useful metrics: percentage of domain authentications using NTLM (trend to zero); count of distinct hosts and accounts using NTLM per week; NTLMv1 and LM logons (target zero); DCs and CAs with signing, channel binding and EPA set to Always; open NTLM exceptions past their expiry date; mean time to triage an NTLM logon from a privileged account.

Framework mapping

Common misconceptions

• "NTLMv2 is safe." NTLMv2 resists offline cracking far better than NTLMv1, but it is just as relayable. Microsoft has deprecated NTLMv2 too.
• "We use Kerberos, so we have no NTLM." Negotiate silently falls back to NTLM when Kerberos fails, for example when a share is reached by IP address or CNAME, or a host is outside the domain. Only the NTLM audit log tells you the real picture.
• "Auditing NTLM protects us." Microsoft is explicit that the Restrict NTLM audit policy does not mitigate relay; it only shows where NTLM is used.
• "Upgrading to Server 2025 finishes the job." Server 2025 enables EPA and channel binding in When Supported mode, which still lets non-supporting clients through, and Server 2019 and 2022 get no new defaults at all.
• "SMB signing alone is enough." It protects SMB targets. Relay to LDAP, AD CS web enrolment or Exchange needs LDAP signing, channel binding and EPA. See the SMB Signing Guide.
• "Disabling LLMNR removes the risk." It removes one way to attract authentication. Coerced authentication of machine accounts and malicious UNC paths remain.

Related concepts

• Microsoft's NTLM deprecation: since June 2024 all NTLM versions (LANMAN, NTLMv1, NTLMv2) are deprecated and no longer under feature development; NTLMv1 is removed from Windows 11 24H2 and Windows Server 2025. Microsoft advises replacing NTLM calls with Negotiate and planning for NTLM being disabled by default in a future release.
• Kerberos: the replacement, with its own risks (delegation, ticket abuse). See the Kerberos Security Guide.
• LDAP hardening: signing, channel binding and LDAPS in depth. See the LDAP Security Deep Dive Guide.
• Active Directory hardening: tiering and reducing privileged machine accounts limit what a relay can reach. See the Active Directory and Entra ID Hardening Guide.
• Where identity fits: computer accounts, gMSAs and service accounts are the identities most often relayed. Treat their NTLM use as a governance finding with an owner, not just a network setting.

Practitioner checklist

• Enable NTLM auditing on all domain controllers and centralise the NTLM operational log.
• Require LDAP signing on DCs after events 2887 and 2889 show no unsigned binds.
• Set LDAP channel binding to When Supported now and Always once event 3039 is clean.
• Enable EPA and HTTPS-only access on AD CS web enrolment, Exchange and other NTLM-accepting IIS applications.
• Require SMB signing on servers and clients, starting with Tier 0 and Tier 1.
• Disable LLMNR, NBT-NS and mDNS where DNS covers the need.
• Remove NTLMv1 and LM; alert on any 4624 with those package names.
• Pilot SMB NTLM blocking on Windows 11 24H2 and Server 2025 with a short, owned exception list.
• Track NTLM share of authentications monthly and report it with the exception register.

Standards and references

• MITRE ATT&CK: Name Resolution Poisoning and SMB Relay
• Microsoft Security Response Center: Mitigating NTLM Relay Attacks by Default
• Microsoft Learn: Deprecated features in the Windows client
• Microsoft Support: LDAP channel binding and LDAP signing requirements for Windows (KB4520412)
• Microsoft Learn: How to enable LDAP signing in Windows Server
• Microsoft Learn: Block NTLM connections on SMB
• Microsoft Learn: Network security: Restrict NTLM: Audit NTLM authentication in this domain
• Microsoft Learn: 4624(S): An account was successfully logged on

Related NHI Mgmt Group resources: SMB Signing Guide · Kerberos Security Guide · AD CS Security Guide · Top 10 Active Directory Security Risks