NTLM Relay Attacks: Why Your Network Is an Open Door

If I could only pick one attack technique for every internal penetration test, it would be NTLM relay. It requires no credentials to start, generates minimal noise, and works in over 90% of the environments I test. The reason is simple: most organizations have not enforced the signing and channel binding controls that would prevent it.

NTLM relay is not a new attack. Security researchers have been demonstrating it for well over a decade. Yet it remains one of the most reliable paths to Domain Admin access because the default Windows configuration leaves the door wide open.

How NTLM Relay Actually Works

NTLM authentication is a challenge-response protocol. When a client wants to authenticate to a server, the server sends a challenge, the client computes a response using its password hash, and the server validates it. The critical weakness is that the protocol does not cryptographically bind the authentication to a specific service or channel.

As an attacker positioned on the network, I intercept the client's authentication attempt and forward it to a different server. That server thinks the client is authenticating directly to it. I use tools like ntlmrelayx to automate this, sitting between the client and whatever target I choose. The client authenticates, but I am the one who gets the session.

What makes this devastating is coercion. I do not have to wait passively for authentication to happen. With techniques like PetitPotam, PrinterBug, or DFSCoerce, I can force machines -- including domain controllers -- to authenticate to my attacker-controlled host. When a domain controller's machine account authenticates to me and I relay that to LDAP on another DC, I can modify Active Directory objects directly. I have added myself to Domain Admins this way in under ten minutes on multiple engagements.

The Protocols at Risk

NTLM relay is not limited to SMB. I routinely relay to multiple protocols depending on what is available and what signing requirements are in place:

• SMB to SMB: The classic relay. If SMB signing is not required on the target, I relay SMB authentications and get remote code execution. This works on most workstations by default.
• SMB to LDAP/LDAPS: If LDAP signing or channel binding is not enforced, I relay to LDAP and modify AD objects. This is my preferred path because it allows me to grant myself any privilege I want.
• HTTP to LDAP: Web-based NTLM authentication often has no Extended Protection for Authentication (EPA). I relay those to LDAP as well.
• SMB to ADCS HTTP enrollment: If Active Directory Certificate Services has web enrollment enabled without EPA, I relay to it and request a certificate as the relayed user. This is the ESC8 attack path, and it gives me persistent access.

Detection: What to Monitor

Detecting NTLM relay requires understanding what normal NTLM traffic looks like in your environment and watching for anomalies. Here are the specific indicators I tell defenders to monitor:

First, watch for NTLM authentication events where the source workstation name does not match the connecting IP address. In a relay attack, the authentication metadata says it is coming from the victim machine, but the network connection comes from the attacker's IP. Event ID 4624 on the target server contains both the workstation name and the source network address -- when they do not match, investigate immediately.

Second, monitor for machine accounts authenticating to LDAP or ADCS web enrollment from unexpected sources. Domain controllers should not be authenticating to your ADCS web enrollment endpoint. If you see a DC's machine account requesting a certificate through HTTP enrollment, you are likely under active attack.

Third, watch for unusual LDAP modifications, particularly changes to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on computer objects. This attribute is what I modify when performing resource-based constrained delegation attacks via relay. Event ID 5136 in the Directory Service Changes audit log captures these modifications.

Hardening: Shutting the Door

The remediation for NTLM relay is well-documented but rarely fully implemented. Here is the complete checklist I provide in every report:

1. Enforce SMB signing on all machines. Configure the GPO "Microsoft network server: Digitally sign communications (always)" to Enabled on all servers and workstations. Yes, workstations too. The performance impact is negligible on modern hardware.
2. Enforce LDAP signing. Set "Domain controller: LDAP server signing requirements" to "Require signing" on all domain controllers. Also set the client-side policy to require signing.
3. Enable LDAP channel binding. Set the LdapEnforceChannelBinding registry value to 2 on all domain controllers. This prevents relay to LDAPS even when signing is bypassed through TLS.
4. Enable EPA on all web services. This includes ADCS web enrollment, Exchange, SCCM, and any internal web application using Windows authentication. EPA binds the NTLM authentication to the TLS channel, preventing relay.
5. Disable NTLM where possible. Use Group Policy to restrict NTLM authentication. Start by auditing NTLM usage with the "Restrict NTLM" policies in audit mode, then progressively block it. The goal is Kerberos everywhere.

Testing Your Defenses

I always recommend that organizations validate their NTLM relay protections proactively. Run PingCastle or Purple Knight against your domain -- both tools check for missing SMB signing, LDAP signing, and channel binding configurations. BloodHound Enterprise can also identify machines that are vulnerable to relay attacks based on their signing configuration.

Do not assume your GPOs are applied correctly. I have seen many environments where the policy was defined but not linked to the right OU, or where a conflicting policy at a lower level overrode the security setting. Verify with actual network traffic analysis that signing is being enforced, not just configured.

NTLM relay is a solved problem from a technical perspective. Every control needed to prevent it exists today and has existed for years. The only reason it still works is that organizations have not deployed those controls. If you take one action from this article, enforce SMB and LDAP signing everywhere. It is the single highest-impact change you can make to your AD security posture.