NTLM relay attacks are back from the dead
NTLM relay attacks are the easiest way for an attacker to compromise domain-joined hosts. While many security practitioners think NTLM relay is a solved problem, it is not – and, in fact, it may be getting worse. Anecdotally, they are used in most attacks seen by my employer’s consulting arm and have gotten much more common in the last few years.
With most environments vulnerable, NTLM sets the stage for lateral movement and privilege escalation. These attacks originate from Authenticated Users and can often reach Tier Zero, resulting in a large exposure and a critical impact.
Here’s an introduction to how these attacks work, what they can target, and how to defend against them.
The basics
NTLM is a legacy authentication protocol from the 1990s. Kerberos is the preferred authentication protocol in Active Directory environments now, but when Kerberos isn’t viable, NTLM is still widely used. A lot of software is hard-coded to call the NTLM authentication package instead of the Negotiate package (which wraps Kerberos and NTLM and negotiates the most suitable option).
NTLM authentication involves three messages: Negotiate, Challenge, and Authenticate. The client sends a message to the server to initiate the authentication flow, the server responds with a random challenge, and the client replies with a cryptographic response that proves it has the correct credentials. This makes each authentication attempt unique and prevents replay attacks, where an attacker intercepts a valid authentication exchange and replays the packets/messages later to impersonate the client.
The problem with NTLM is the vulnerability to relay attacks. An attacker can simply relay the NTLM messages between a client and server, back and forth, until the server establishes a session for the client, allowing the attacker to perform any operation the client could perform on the server. Relay attacks allow for authenticating to the target without spending time and resources on password cracking or relying on weak passwords, making NTLM an easy target.
Diagram of an NTLM Relay attack
NTLM relays + coerced authentication
But, you may say, doesn’t this attack rely on the victim trying to authenticate at the right time? Actually, no. Relay attacks can be combined with authentication coercion attacks (like the Printer Bug or PetitPotam) that force the victim to make an immediate authentication request. These two authentication coercion techniques can be performed by all Authenticated Users (practically, anybody), so a relay attack can be initiated by anyone.
Targets and attack next steps
NTLM relay attacks have three common targets. Next steps and mitigations are different for each.
1. SMB servers: A successful relay attack against an SMB server establishes a session. So, the attacker’s next steps depend on the access the relay victim has. For example, they could gain access to the C$ or ADMIN$ share on the relay target, dump LSA secrets from Remote Registry, including the computer account password, or move laterally via the Service Control Manager. A common scenario involves coercing authentication from the SCCM site server and relaying it to the SCCM database server to take over the entire hierarchy.
Most Windows hosts, especially Windows servers, are susceptible to this attack. Microsoft is working to mitigate them – domain controllers starting with Windows Server 2008 and all Windows hosts starting with Windows Server 2025 and Windows 11 prevent NTLM relay attacks by requiring SMB signing by default. And yet, it is off by default in older versions, and most organizations don’t change it.
2. LDAP or LDAPS: Targeting LDAP or LDAPS is more complicated than targeting SMB but can be quite fruitful. Most domain controllers are currently vulnerable to NTLM relay attacks via LDAP.
LDAP servers support mitigating relay attacks with LDAP signing and LDAP channel binding (both must be enforced to prevent relay attacks). But neither is enforced by default, and most organizations do not change those defaults. Note that these settings are DC-level settings, not domain-level, so different domain controllers in the same environment can have different configurations.
One positive development is that domain controllers now enforce encryption (sealing) via session security on LDAP SASL bind by default in Windows Server 2025. This means relaying to LDAP or LDAPS is no longer viable. As more domain controllers are run on Windows Server 2025, the vulnerability to this attack will decrease.
3. ADCS web enrollment (ESC8): Relaying to ADCS is much more complicated than relaying to SMB because certificate abuse has a lot of requirements. However, the relaying logic is still relatively simple. Relaying to ADCS web enrollment allows the attacker to obtain a certificate for the relay victim, which they can use to impersonate them. My colleagues Will Schroeder and Lee Chagolla-Christensen discovered this and disclosed it in their Certified Pre-Owned white paper. If the CA is susceptible to relay attacks, all the computers that can enroll a suitable certificate are exposed. Note that the default “Machine” certificate template meets the attack criteria and exposes all the computers in the domain.
In general, NTLM relay attacks are complex with many moving parts, but are fast and easy to execute if the operator knows what they’re doing. I can say as a red teamer that they are our bread and butter when attacking an AD environment. If the conditions that allow any of these attacks exist in an environment, it’s very bad!
Defense and mitigations
Microsoft is working on several mitigations for these attacks, including disabling NTLM by default. But that is at least years away. The best way to protect against relay attacks in the near term is to ensure all servers enforce signing and channel binding. This is disruptive to servers that don’t support these features, so being specific about which features to enforce on which servers is ideal. I recommend evaluating your environments for NTLM relay attacks and prioritizing high-exposure targets on a continuous basis.