A password can remain secret, the authentication exchange can be cryptographically valid, and an attacker can still authenticate as you.
No password cracking. No stolen plaintext credentials. Sometimes, not even a vulnerability in the target application.
The attacker simply forwards an authentication exchange between two systems and lets the legitimate user do the cryptographic work for them.
This is called an NTLM relay attack, and it exposes a subtle weakness in how authentication can be used across network connections. The problem isn't necessarily that NTLM fails to verify the credentials. It's that a valid authentication exchange can sometimes be redirected to a service the user never intended to authenticate to.
To understand how that happens, we need to look at what NTLM actually proves, what it leaves unverified, and how an attacker can exploit that gap.
NTLM Doesn't Send Your Password
NTLM is a Windows authentication protocol that uses a challenge-response mechanism. Instead of sending a user's plaintext password across the network, it allows a server to verify a response calculated using password-derived secret material.
A simplified authentication exchange works like this:
- Negotiation: The client and server establish the parameters for authentication.
- Challenge: The server sends the client a challenge value.
- Response: The client calculates a response using the challenge and its NTLM credentials.
- Verification: The server, or an appropriate authentication authority, validates the response.
- Authentication: If verification succeeds, the client can access resources according to the account's permissions.
The important detail is that the response depends on the server's challenge. An attacker who captures a response from an earlier exchange generally cannot simply replay it against a new challenge and expect it to work.
That sounds reasonably secure, and it is an important property of challenge-response authentication.
But there's another question the protocol must answer: is the client authenticating to the service it actually intended to reach?
A valid response can prove possession of the necessary credential material without necessarily proving that the authentication is bound to the intended server or communication channel.
That distinction is where NTLM relay attacks begin.
The Attack: Let Someone Else Authenticate for You
Imagine three systems on a corporate network:
- The victim: A Windows computer logged in as a domain user.
- The attacker: A system capable of receiving or inducing the victim's NTLM authentication.
- The target: A server that accepts NTLM authentication and grants the victim certain permissions.
The attacker wants to access the target as the victim. They don't know the password, but they may not need it.
Here's the basic sequence:
Victim Attacker Target
| | |
|--- Authentication ---->| |
| |--- Authentication ---->|
| |<------ Challenge -------|
|<------- Challenge -----| |
| | |
|-------- Response ----->| |
| |---- Response --------->|
| | |
| |<-- Authentication OK ---|
| | |
| |--- Access as victim --->|
This diagram is simplified, but it captures the essential idea: the attacker forwards messages between the victim and the target while the victim generates the cryptographic response.
Let's walk through what happens.
First, the attacker gets an authentication attempt.
The victim must be induced to authenticate to a service controlled by the attacker, or the attacker must otherwise be able to obtain the victim's authentication exchange. The method depends on the environment and may involve coercing a machine to connect to another system.
Next, the attacker forwards the exchange to the target.
Rather than independently generating a valid NTLM response, the attacker relays the victim's authentication messages to the target. The target provides a challenge, which is forwarded to the victim.
The victim generates the response.
Because the victim has the necessary credentials, their system calculates the appropriate response to the challenge. The attacker forwards that response to the target.
The target validates the response.
If the target accepts the exchange and the relevant relay protections are absent, authentication can succeed as the victim.
The attacker has not necessarily learned the password or cracked a hash. They have forwarded a live authentication exchange to a service that accepts it.
The resulting access depends on the target, the account's permissions, and the protections enforced by the protocol and service.
Why Does the Relay Work?
The interesting part is that the attacker doesn't have to break the cryptography.
The weakness lies in the context in which authentication is accepted.
NTLM's challenge-response mechanism helps prevent straightforward replay of a captured response against a different challenge. However, NTLM authentication by itself does not universally bind the exchange to the specific server or protected communication channel the client intended to use.
If the attacker can relay the exchange while the target accepts it without the necessary protections, the target may have no sufficient way to distinguish the relayed authentication from an acceptable authentication attempt.
Think of it as a distinction between proving your identity and proving who you're communicating with.
A system may verify that the authentication response is valid but fail to verify that the exchange belongs to the intended connection.
This is why NTLM relay is not the same as password cracking or pass-the-hash. Password cracking attempts to recover a password. Pass-the-hash abuses password-hash material to authenticate. Relay attacks forward authentication messages between systems, potentially without recovering the password or obtaining the hash.
The technique is also conditional. Not every NTLM exchange can be relayed successfully. The target protocol, account privileges, service configuration, and protections such as signing and Extended Protection all affect the outcome.
When a Relay Becomes a Bigger Problem
NTLM relay becomes particularly serious when the target can grant access to sensitive resources or perform privileged operations on behalf of the authenticated user.
One example is Active Directory Certificate Services (AD CS), Microsoft's infrastructure for issuing and managing certificates in Windows environments.
Certificates can be used for authentication, which makes certificate enrollment services a potentially valuable target. Under certain configurations, an attacker who relays a privileged account's NTLM authentication to an inadequately protected enrollment endpoint may be able to obtain a certificate that enables further impersonation.
Microsoft addressed this risk in its guidance on mitigating NTLM relay attacks against AD CS.
The key word is configuration. AD CS is not automatically vulnerable simply because it is deployed. The risk depends on how the enrollment services are exposed and whether the appropriate authentication protections are enabled.
This example illustrates how relay attacks can become part of a larger intrusion. A successful relay may provide the foothold needed to access resources, request credentials or certificates, or move further through a network, depending on the target's permissions and configuration.
The attack doesn't magically grant domain administrator privileges in every environment. It turns an accepted authentication exchange into access that the attacker may otherwise have been unable to obtain.
Why Changing the Password Isn't Enough
If an attacker steals a password, changing it is an obvious response. If a password hash is compromised, credential rotation is also important.
But NTLM relay exploits a different problem.
The attacker can forward a live authentication exchange without learning the password. Changing the password alone does not fix a target service that accepts relayed authentication without adequate protections.
The solution has to address the authentication flow itself.
SMB Signing
Server Message Block (SMB) signing adds integrity protection to SMB messages. When signing is required and correctly enforced, it can prevent common SMB relay attacks because the attacker cannot freely create or modify signed messages without the necessary session key.
This is particularly relevant to SMB relay. It is not a universal defense against relay attacks targeting other protocols.
Extended Protection for Authentication
Extended Protection for Authentication (EPA) helps bind authentication to the intended service or communication channel, making it harder to reuse authentication from one connection in another context.
Two related concepts are important:
- Channel binding: Associates authentication with the underlying TLS channel.
- Service binding: Helps ensure that authentication is associated with the intended service identity.
The exact protections available depend on the protocol, application, and configuration. Simply enabling TLS does not guarantee protection against NTLM relay if authentication is not properly bound to the connection.
Reduce NTLM Usage
Where operationally feasible, organizations should reduce NTLM authentication and move to stronger alternatives such as Kerberos in supported environments.
Legacy applications, workgroup configurations, and other dependencies may make immediate removal difficult. Administrators should audit NTLM usage before restricting it and address systems that still depend on the protocol.
Harden Services and Limit Privileges
High-value services, including file servers and certificate enrollment endpoints, should enforce the protections supported by their protocols. Unnecessary exposure should be removed, and authentication configurations should be reviewed rather than assumed secure by default.
Least privilege matters, too. A relayed authentication exchange can only grant the attacker the access the target permits for that identity. Limiting administrative privileges and restricting where privileged accounts authenticate can reduce the impact of a successful relay.
No single mitigation prevents every possible relay scenario. Effective defense combines protocol-level protections, hardened services, reduced NTLM usage, and carefully controlled permissions.
The Real Lesson Behind NTLM Relay
NTLM relay attacks expose a subtle distinction in security engineering: verifying an authentication response is not always the same as verifying the context in which that response is being used.
The protocol can validate the response without the attacker ever learning the password. If a target accepts that authentication without adequate channel or service protections, a legitimate exchange can become a path to unauthorized access.
That's why protecting credentials is only part of authentication security. Systems must also ensure that authentication is being used with the intended service and under the right conditions.
Sometimes, an attacker doesn't need to steal your password. They just need to redirect the proof that you know it.
Top comments (0)