NTLM Relay Attack Detection: Signs, Tools and Response Steps

How NTLM Relay Attacks Work

Imagine you hand a sealed letter to a postman, trusting he will deliver it to the intended recipient. An attacker intercepts the letter, opens it, reads the contents, and then hands it to a different recipient who accepts it as genuine because they cannot verify the original sender. This is the core mechanic of NTLM relay attacks. The NetNTLM challenge-response protocol allows a client to prove its identity to a server without sending the actual password.

Instead, the client sends a cryptographic hash derived from the password and a challenge issued by the server. The flaw lies in the server’s acceptance of this hash. The server checks if the hash matches the stored credentials but does not verify if the request originated from the expected client context or if the hash has been replayed from another session.

An attacker captures the authentication handshake when a user attempts to access a resource. The attacker then redirects the victim’s traffic to a malicious server controlled by the threat actor. When the victim authenticates to this rogue server, the attacker captures the NTLM hash. The attacker then relays this hash to a legitimate internal server, such as a domain controller or a file share, impersonating the victim. Because the protocol does not bind the hash to a specific destination, the target server accepts the relayed credentials as valid. This allows the attacker to gain access with the victim’s privileges without ever knowing the plaintext password.

What People Usually Get Wrong

Many defenders assume that cracking the hash is the attacker’s primary goal. This is a misconception. In a relay attack, the attacker does not need to break the cryptographic hash. They simply need to move it from one context to another. This makes the attack significantly faster and harder to detect through traditional password-cracking monitoring. Another common error is relying solely on endpoint detection. Since the relay happens at the network layer and involves server-to-server or user-to-server communication, endpoint logs may only show a successful login. Without network visibility, the redirection step remains invisible.

Defenders also often overlook the role of LLMNR and NetBIOS Name Service. These legacy protocols are designed to resolve hostnames locally when DNS fails. Attackers use these services to poison responses, tricking users into connecting to the attacker’s machine. Disabling these protocols is a critical step that many organisations neglect because they assume modern DNS is sufficient. If a user types a short name that does not resolve, the system broadcasts a request. An attacker listening on the network can respond to this request, initiating the relay chain.

NTLM Relay Attack Detection Methods

Effective NTLM relay attack detection requires a combination of network monitoring and log correlation. You cannot rely on a single data source. The first step is to monitor for anomalous SMB traffic. Standard user behaviour involves accessing file shares from their own workstation. If a server begins receiving SMB connections from unexpected IP addresses, such as other servers or non-user devices, this is a strong indicator of a relay. You should configure your intrusion detection systems to alert on SMB traffic originating from hosts that do not typically act as clients.

The second method involves analysing authentication logs for impossible travel or unusual context. If a user account authenticates to a resource from a server IP address instead of a workstation IP, this is a red flag. You must review the source IP of the authentication request. If the source is a domain controller or a web server, the likelihood of a relay is high. Additionally, look for multiple failed authentication attempts followed by a sudden success. Attackers often test multiple targets with a captured hash. A burst of activity from a single source IP can signal a relay attempt.

The Role of Threat Intelligence

Threat intelligence platforms can provide indicators of compromise related to known relay attack tools and techniques. While the attack itself is generic, the tools used to execute it often have specific signatures. Monitoring for these signatures can help identify active campaigns. However, reliance on external intelligence is not enough. You must integrate this data with your internal telemetry. An indicator of compromise is only useful if you can map it to your environment. This means ensuring that your security information and event management system can ingest and alert on these specific patterns.

Threat intelligence also helps in understanding the broader context of privilege escalation attacks. Attackers use NTLM relaying as a stepping stone to gain higher privileges. By understanding the typical progression, you can anticipate the next move. For example, after gaining initial access via relay, an attacker may attempt LSASS credential theft to dump more credentials. Monitoring for these subsequent activities can help you detect the attack even if the initial relay was missed. This layered approach ensures that you have multiple opportunities to detect and respond.

Prevention and Hardening Strategies

The most effective defence against NTLM relay attacks is to eliminate the underlying vulnerability. This involves enforcing SMB signing. When SMB signing is enabled, every packet must include a cryptographic signature that proves its origin. An attacker cannot relay a signed packet because they do not possess the private key required to generate a valid signature for the new destination. You should configure your group policies to require SMB signing on all servers and clients. This adds a small performance overhead but significantly increases security.

Disabling legacy protocols is another critical step. Turn off LLMNR and NetBIOS Name Service on all devices. These protocols are unnecessary in modern environments and provide a easy entry point for attackers. Additionally, migrate away from NTLM authentication entirely. Use Kerberos, which provides mutual authentication and binds the session to the specific service. Kerberos tickets cannot be easily relayed because they are encrypted and contain specific service identifiers. If you must support legacy systems, restrict NTLM usage to specific, isolated segments of the network.

See also: Port Scanning Myths: What Attackers Actually Reveal · Difference Between Session Hijacking and Spoofing: Mechanisms and Defences

Incident Response and Alert Triage

When you detect a potential NTLM relay attack, immediate action is required. The first step is to isolate the affected systems. Prevent further communication between the suspected attacker and the targeted servers. This stops the relay chain and limits the damage. Next, investigate the authentication logs to determine the scope of the compromise. Identify all accounts that were used in the relay attempt and check for any successful logins. Reset the passwords for these accounts and revoke any active sessions.

You must also review the actions taken by the attacker. Check for any file access, data exfiltration, or privilege escalation attacks. Look for new user accounts or changes to group memberships. Document the incident and update your detection rules to catch similar patterns in the future. Alert triage is critical here. You must distinguish between false positives and true attacks. False positives can occur when administrative tools legitimately relay credentials. Ensure your response process accounts for these legitimate use cases to avoid unnecessary disruption.

Long-Term Security Posture

Building a resilient security posture requires continuous monitoring and improvement. Regularly audit your network for legacy protocols and configurations. Ensure that all devices are updated and patched. Implement network segmentation to limit the lateral movement of attackers. Even if an attacker gains access via a relay, segmentation can prevent them from reaching critical assets. Additionally, invest in training for your security team. Understanding the mechanics of NTLM relay attacks helps in developing better detection and response strategies.

Remember that no single control provides complete protection. You must layer multiple defences. Combine protocol hardening, network monitoring, and threat intelligence to create a robust security framework. Regularly test your defences with simulated attacks. This helps identify gaps and ensures that your detection mechanisms are working as expected. By staying proactive and adapting to new threats, you can significantly reduce the risk of NTLM relay attacks.

Key takeaways

• NTLM authentication does not verify the identity of the server receiving the hash.
• Enabling SMB signing prevents the relay by requiring cryptographic proof of origin.
• Detection requires correlating authentication logs with network flow data to spot anomalies.

Frequently asked questions

Can NTLM relay attacks work over the internet?

No, they typically occur within internal networks where legacy protocols are still in use and traffic is less restricted.

Does enabling SMB signing stop all NTLM attacks?

It stops relay attacks by requiring cryptographic proof of origin, but it does not prevent other forms of credential theft or brute force attacks.

How do I know if my servers are vulnerable?

Check your group policies for SMB signing requirements and audit for disabled LLMNR and NetBIOS services on all network devices.

What is the difference between NTLM relay and pass-the-hash?

Pass-the-hash involves replaying a hash to the same server, while NTLM relay involves redirecting the hash to a different server.

How this guide was produced: written by the Cipher Insider editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.