NTLM Relay Attacks: Understanding the Threat and How to Defend Against It

Introduction

NTLM Relay Attacks remain a serious threat in enterprise networks relying on Windows authentication protocols. Exploited by red teams and threat actors alike, these attacks allow adversaries to pivot laterally and escalate privileges without cracking passwords. Despite being a well-documented vulnerability, NTLM relay continues to be a viable vector in misconfigured environments.

This article dives into the inner workings of NTLM relay, real-world attack scenarios, and defensive measures to harden your infrastructure.

What Is NTLM Relay?

NTLM (NT LAN Manager) is an authentication protocol used by Windows systems. In relay attacks, adversaries intercept NTLM authentication messages from a victim and relay them to another service, gaining access or performing actions on behalf of the authenticated user.

Unlike traditional credential theft, NTLM relay does not require password cracking. Instead, it leverages weaknesses in authentication flow, SMB/LDAP bindings, and the lack of message signing.

The attack chain typically involves:

• Capturing authentication attempts via tools like Responder
• Relaying the NTLM challenge-response to a vulnerable service
• Gaining access to sensitive systems or Active Directory objects

To understand similar credential abuses, check our article on Pass-the-Hash attacks.

Tools Commonly Used in NTLM Relay

Several tools enable attackers and red teams to automate and chain NTLM relay attacks:

• Responder: Captures broadcasted authentication attempts (LLMNR, NBNS)
• Impacket’s ntlmrelayx.py: Performs relaying to SMB/LDAP/RPC and more
• PetitPotam: Forces NTLM authentication from a domain controller

These tools can be chained to execute DCSync attacks, Active Directory enumeration, or shadow admin creation.

If you're exploring AD exploitation paths, our guide on BloodHound and domain enumeration is a valuable reference.

Real-World Exploitation Scenario

1. An attacker connects to the corporate LAN and launches Responder to spoof LLMNR responses.
2. A legitimate user accesses a shared resource and their machine unknowingly sends an NTLM authentication request.
3. The attacker relays this request using ntlmrelayx.py to a domain controller's LDAP interface.
4. The attacker binds as the victim and adds a new machine to AD or grants privileges.

This is often a zero-click attack from the user’s perspective — making it especially dangerous.

Defenses Against NTLM Relay

To defend effectively against NTLM relay, combine protocol hardening, monitoring, and network segmentation.

1. Disable NTLM Where Possible

• Move to Kerberos-only environments where feasible
• Use LDAP over Kerberos (SASL/GSSAPI) instead of NTLM binds
• Disable NTLM via Group Policy (but validate for legacy systems)

2. Enforce SMB and LDAP Signing

• Enable SMB signing on all endpoints and servers
• Enforce LDAP Channel Binding and LDAP Signing on domain controllers

Many environments still lack these settings due to backward compatibility concerns. Our article on Active Directory misconfiguration audit can guide your validation process.

3. Network Hardening

• Isolate high-value systems (e.g., Domain Controllers, file servers)
• Limit LLMNR and NBNS traffic via GPO or firewall rules
• Use firewalls to block unnecessary SMB, RPC, and LDAP exposure

Monitoring and Detection

NTLM relay attacks leave traces that can be detected through:

• Event ID 4624: Look for unusual logons with NTLM authentication type
• Suspicious LDAP binds or machine account creations
• High-frequency authentication failures to SMB or LDAP interfaces

Forward these logs to your SIEM or SOC for correlation and alerting. Integrating with ELK Stack or Wazuh allows advanced detection logic and dashboarding.

Conclusion

NTLM relay attacks exploit legacy protocol weaknesses and persist in modern networks due to misconfigurations and backward compatibility requirements. While Microsoft has introduced mitigation controls, only proactive hardening, detection, and protocol management can eliminate this attack vector.

If your environment is still NTLM-reliant, conduct an internal audit and consider an Active Directory security audit with PingCastle or a full red team simulation.