NTLM Relay: Bypassing Authentication by Intercepting Network Traffic!

To grasp the mechanics of an NTLM Relay attack, it is essential to first understand how the NTLM authentication protocol functions. NTLM utilizes a challenge-response mechanism. When a client attempts to access a resource on a server (e.g., a file share or a web application) using NTLM, a three-step handshake occurs.

1. Negotiation: The client sends an NTLM Negotiate message to the server, indicating its capabilities and proposing authentication parameters.
2. Challenge: The server responds with an NTLM Challenge message, which includes a randomly generated 8-byte string known as the server challenge.
3. Authentication: The client uses its password hash (the NTLM hash) to encrypt the server challenge. It then sends this encrypted challenge, along with the user's username and domain, back to the server in an NTLM Authenticate message. The server (or the Domain Controller, via Pass-Through Authentication) verifies if the client correctly encrypted the challenge, thus authenticating the user without transmitting the password in plain text.

The critical flaw in this design—and the foundation of the NTLM Relay attack—is that the server only verifies that the client possesses the correct password hash. It does not natively verify the identity of the client originating the connection or the integrity of the connection itself.

In an NTLM Relay attack, the adversary positions themselves between the victim client and the target server. The attack unfolds as follows:

1. The attacker coerces or waits for the victim client to initiate an NTLM authentication attempt toward the attacker's machine.
2. The attacker receives the NTLM Negotiate message from the victim and immediately forwards it to the intended target server.
3. The target server responds with an NTLM Challenge, which the attacker relays back to the victim client.
4. The victim client encrypts the challenge using its password hash and sends the NTLM Authenticate message to the attacker.
5. Finally, the attacker relays this valid, encrypted response to the target server.

Because the response correctly solves the server's challenge using the victim's credentials, the target server accepts the authentication. The attacker now possesses an authenticated session with the target server, operating with the privileges of the victim user.

NTLM Relay attacks are not limited to a single protocol. Attackers can intercept authentication attempts on one protocol and relay them to a completely different protocol, making this attack vector highly versatile and dangerous.

SMB to SMB Relaying

Server Message Block (SMB) is the backbone of Windows file and print sharing. Relaying an SMB authentication attempt to another SMB service is a classic and highly effective technique. If an attacker relays the credentials of a Domain Administrator from a victim machine to a Domain Controller or a critical file server via SMB, the attacker gains immediate administrative execution capabilities on that target. They can use tools like psexec or smbexec within the relayed session to execute arbitrary commands, dump credentials, or deploy malware.

HTTP to SMB Relaying

Often, attackers trick clients into authenticating over HTTP (for example, by forcing a client to visit a malicious webpage that requests NTLM authentication). The attacker can take this HTTP authentication attempt and relay it to an SMB server. This cross-protocol relay is particularly dangerous because users are frequently unaware that an HTTP prompt can lead to full system compromise if their credentials are relayed to a critical SMB resource.

SMB to LDAP Relaying

Lightweight Directory Access Protocol (LDAP) is used to query and modify Active Directory. Relaying SMB authentication to LDAP allows an attacker to interact with the directory service. A severe escalation occurs if the attacker relays the credentials of a user with high privileges (like an Exchange Server account or an administrator) to LDAP. This allows the attacker to execute DCSync attacks (requesting password hashes from the Domain Controller) or manipulate Active Directory objects, such as creating new administrative users or modifying group memberships.

Relaying to AD CS (Active Directory Certificate Services)

A more recent and devastating evolution of the NTLM Relay attack targets Active Directory Certificate Services (AD CS). Many organizations deploy AD CS with web enrollment interfaces (like certsrv) that often support NTLM authentication. If an attacker relays a machine account's NTLM authentication (e.g., coerced from a Domain Controller) to the AD CS web interface, they can request a client authentication certificate for that relayed machine account. Once the certificate is issued, the attacker can use it to authenticate to the domain as that machine via Kerberos (PKINIT), effectively granting the attacker full control over the compromised system or even the entire domain.

The impact of NTLM Relay attacks is frequently demonstrated during Penetration Testing and Red Teaming engagements, often leading to rapid domain compromise.

One common scenario involves the abuse of multicast name resolution protocols like LLMNR (Link-Local Multicast Name Resolution) or NBT-NS (NetBIOS Name Service). When a user mistypes a server name (e.g., trying to access \\filesrvr instead of \\fileserver), the Windows machine attempts to resolve the name using DNS. If DNS fails, it broadcasts an LLMNR or NBT-NS query to the local network.

An attacker running a tool like Responder listens for these broadcasts and maliciously replies, claiming to be the requested server. The victim's machine then attempts to authenticate to the attacker's machine using NTLM over SMB. The attacker intercepts this authentication and, using a tool like ntlmrelayx.py, relays it to a target server where SMB signing is disabled. If the victim user has administrative privileges on the target server, the attacker instantly gains code execution, turning a simple typo into a system compromise.

Another real-world example involves coerced authentication. Attackers can use tools like PetitPotam or PrinterBug to force a remote system, such as a Domain Controller, to authenticate to the attacker's machine. If the attacker coerces a DC to authenticate via SMB, they can relay that authentication to the AD CS web enrollment service. By requesting a certificate for the DC, the attacker can then authenticate as the Domain Controller itself, gaining the ability to perform DCSync and extract all domain password hashes, leading to total Active Directory takeover.

Because NTLM Relay attacks exploit the fundamental design of the NTLM protocol rather than a specific software bug, mitigating them requires a combination of configuration changes, protocol hardening, and architectural improvements.

Enforce SMB Signing

The most direct defense against SMB-based NTLM Relay attacks is enforcing SMB Signing. SMB Signing requires every SMB packet to be digitally signed, proving that it originated from the authenticated user and has not been tampered with. If an attacker attempts to relay an NTLM authentication to a server that requires SMB Signing, the attack will fail because the attacker cannot generate the required cryptographic signatures for subsequent SMB packets without knowing the user's password.

• Ensure that the Group Policy setting "Microsoft network server: Digitally sign communications (always)" is Enabled on all critical servers, especially Domain Controllers.
• While enforcing SMB Signing on all clients and servers is ideal, it can introduce performance overhead, so prioritize enforcing it on high-value targets first.

Enable LDAP Signing and Channel Binding

To prevent relay attacks targeting LDAP, you must enforce LDAP signing and LDAP Channel Binding.

• LDAP Signing: This requires that LDAP traffic be digitally signed, preventing tampering and relaying. It can be enforced via Group Policy settings on Domain Controllers.
• LDAP Channel Binding: When LDAP is accessed over an encrypted connection (LDAPS or StartTLS), Channel Binding ties the inner NTLM authentication to the outer TLS channel. If an attacker intercepts the NTLM authentication and tries to relay it over a new TLS connection, the Channel Binding token will not match, and the Domain Controller will reject the authentication.

Disable NTLM Authentication

The ultimate solution to NTLM Relay attacks is to eradicate NTLM from the environment entirely. While this is often a challenging, long-term project due to legacy application dependencies, it is the most effective security posture.

• Audit your environment using NTLM auditing policies (Event ID 8004 in the NTLM Operational log) to identify which applications and devices are still relying on NTLM.
• Gradually transition applications to modern authentication protocols like Kerberos or OAuth/SAML.
• Once NTLM usage is eliminated or isolated to specific, hardened segments, utilize the "Network security: Restrict NTLM" Group Policy settings to block NTLM traffic on the network.

Mitigate Name Resolution Poisoning

To prevent attackers from capturing NTLM authentications via LLMNR and NBT-NS spoofing (as seen with Responder), these protocols should be disabled.

• Disable LLMNR: Use Group Policy to enable "Turn off multicast name resolution".
• Disable NBT-NS: This must be disabled via DHCP scope options (Option 43, vendor-specific) or manually on the network adapters of individual machines.

Secure AD CS Configurations

If utilizing Active Directory Certificate Services, it is crucial to protect against NTLM relaying to the web enrollment interfaces.

• Remove the Web Enrollment roles if they are not strictly necessary.
• If they must be used, enforce HTTPS and configure IIS to require Extended Protection for Authentication (EPA), which implements channel binding to thwart relay attacks.
• Disable NTLM authentication on the IIS server hosting the AD CS endpoints, forcing clients to use Kerberos.