NTLM Relay - why it still works and how to defend against it

In 70% of our internal infrastructure penetration tests, we successfully execute an NTLM relay attack. Not because we use advanced exploits, but because organizations still do not enforce basic NTLM protection mechanisms. The protocol is over 30 years old and Microsoft is officially retiring it, yet the reality of production environments looks very different from vendor recommendations.

In February 2026, Microsoft announced a three-phase plan to retire NTLM, and in October 2026 the BlockNTLMv1SSO registry key will default to “Enforce.” This is the right direction, but the plan alone does not protect organizations that still rely on NTLM in their infrastructure.

What NTLM relay is and why it is so effective

An NTLM relay attack exploits a fundamental weakness in the protocol: NTLM does not bind the authentication session to a specific communication channel. The attacker positions themselves between the client and server and redirects (relays) the NTLM authentication request to a different server - impersonating the victim.

Simplified flow:

Attacker forces the victim to authenticate to the attacker’s machine (e.g., through an SMB share link, LLMNR/NBNS poisoning, or PetitPotam)
Victim sends the NTLM hash to the attacker
Attacker forwards this hash to the target server (e.g., a domain controller via LDAP)
Target server authenticates the session - it believes it is communicating with the victim
Attacker has an authenticated session on the target server with the victim’s privileges

WARNING

NTLM relay does not require cracking passwords. The attacker never learns the victim’s password - they redirect a ready-made authentication request. This means that even very strong passwords do not protect against this attack.

Authentication coercion vectors

Before relay is possible, the attacker must force NTLM authentication. Here are the most common methods we use in tests:

Method	Description	Required conditions
LLMNR/NBNS poisoning	Responding to multicast DNS queries on the local network	LLMNR and NetBIOS over TCP/IP enabled
PetitPotam (MS-EFSRPC)	Forcing domain controller authentication	DC without patches or without EPA
Printer Bug (SpoolSample)	Forcing authentication via Print Spooler service	Print Spooler enabled on DC
WebDAV	Forcing HTTP authentication to WebDAV	WebClient service enabled
Coerce via MS-DFSNM	Coercion through Distributed File System	DFS configured
Outlook/Office	Malicious document or email with UNC link	No NTLM restrictions in Office

In our tests, we most commonly use a combination of LLMNR poisoning + relay to LDAP. In environments with LLMNR disabled, we switch to PetitPotam or Printer Bug to force domain controller authentication.

Relay targets - where we redirect authentication

Not every protocol is equally vulnerable to relay. Effectiveness depends on whether the target protocol enforces signing or channel binding:

Relay target	Vulnerability condition	Potential impact
SMB	SMB Signing not enforced	Remote code execution (RCE)
LDAP/LDAPS	No LDAP Signing + Channel Binding	AD object modification, adding account to group
HTTP (AD CS Web Enrollment)	No EPA on web enrollment	Certificate issuance (ESC8) - domain takeover
MSSQL	Signing not enforced	SQL query execution with victim’s privileges
IMAP/SMTP	No EPA enforcement	Access to victim’s email

The scenario we execute most frequently:

PetitPotam forces domain controller authentication
Relay to LDAP on another DC (without signing enforcement)
Via LDAP, we create a machine account and configure Resource-Based Constrained Delegation
We use delegation to obtain a Kerberos ticket as a domain administrator

The entire process takes a few minutes and ends with full domain compromise.

Defense mechanisms - what actually works

SMB Signing

SMB Signing adds a cryptographic signature to each SMB packet, preventing relay to SMB. Windows Server 2025 enforces SMB Signing by default, but older systems require manual configuration.

How to enable:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options:
- Microsoft network server: Digitally sign communications (always) > Enabled
- Microsoft network client: Digitally sign communications (always) > Enabled

TIP

SMB Signing may affect file transfer performance (estimated 5-15% depending on load). In environments with intensive SMB traffic, test before production deployment. In practice, modern hardware handles this overhead without noticeable performance degradation.

LDAP Signing and Channel Binding

LDAP Signing protects against relay to LDAP. Channel Binding (Extended Protection for Authentication - EPA) binds the TLS session to the authentication session, protecting against relay to LDAPS.

Both mechanisms must be enabled simultaneously. LDAP Signing without Channel Binding still allows relay to LDAPS.

How to enable:

LDAP Signing:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options:
- Domain controller: LDAP server signing requirements > Require signing

Channel Binding:
Registry: HKLM\System\CurrentControlSet\Services\NTDS\Parameters
- LdapEnforceChannelBinding = 2 (Always)

A positive change: Windows Server 2025 enforces encryption (sealing) on LDAP SASL bind sessions by default, which eliminates relay to LDAP/LDAPS. The problem is that domain controllers running Windows Server 2025 are still few and far between based on our observations.

Extended Protection for Authentication (EPA)

EPA is a channel binding mechanism for HTTP protocols, protecting against relay to web services - including AD CS Web Enrollment (ESC8 attack).

How to enable for AD CS Web Enrollment:

Open IIS Manager on the CA server
Navigate to the CertSrv site
Select Authentication > Windows Authentication > Advanced Settings
Set Extended Protection to “Required”

Disabling LLMNR and NetBIOS over TCP/IP

Disabling these protocols eliminates the easiest authentication coercion vector.

LLMNR:

Computer Configuration > Administrative Templates > Network > DNS Client:
- Turn off multicast name resolution > Enabled

NetBIOS over TCP/IP: Configure via DHCP (option 001) or on the network interface: “Disable NetBIOS over TCP/IP”

Microsoft’s three-phase plan - what is changing

Microsoft is retiring NTLM in three phases:

Phase	Timeline	Scope
1 - Audit	2025 (active)	Auditing tools in Windows Server 2025 and Windows 11 24H2
2 - Alternatives	H2 2026	IAKerb (Kerberos without direct DC access) + Local KDC
3 - Default off	Future release	NTLM disabled by default in new installations

Additionally, in October 2026, Microsoft will change the default value of the BlockNTLMv1SSO key from Audit to Enforce, which will disable NTLMv1 in SSO.

TIP

Do not wait for phase 3. Enable NTLM auditing now and start identifying applications that require it. GPO “Network security: Restrict NTLM: Audit NTLM authentication in this domain” set to “Enable all” is the first step. EventID 8004 logs will show where NTLM is still being used.

Special context: NTLM relay in OT environments

In industrial environments, the NTLM relay problem is particularly acute. SCADA, HMI, and historian systems often run on older Windows versions that do not support modern protection mechanisms. These systems may be joined to an AD domain, but updating them is complicated by availability requirements and compatibility with control software.

For more on the specifics of Active Directory in OT environments, see our article Active Directory in OT environments - specific threats.

Checklist: NTLM hardening

Regulatory context

The NIS2 Directive in Article 21 requires essential entities to implement risk management measures including “policies and procedures regarding the use of cryptography and encryption.” Failure to enforce protocol signing (SMB Signing, LDAP Signing) and lack of channel binding is effectively a failure to apply available cryptographic mechanisms for authentication protection.

Summary

NTLM relay is an attack that should not work in 2026. All defensive mechanisms have existed for years and are well documented. The problem lies in their deployment - organizations fear the impact on compatibility, and the configuration requires changes at multiple levels simultaneously.

At SEQRED, we help with this process. During penetration tests, we identify which relay vectors work in a given environment. We then support IT teams in planning and implementing hardening - from auditing NTLM dependencies, through signing configuration, to legacy application migration.

If you want to check whether your environment is vulnerable to NTLM relay, we invite you to get in touch. A free scoping call will allow us to assess the scale and propose an appropriate test scope.

Sources: