NTLM Explained: Pass-the-Hash, Relay, and Why It Is Being Retired

NTLM is the authentication protocol Windows used before Kerberos and still falls back to constantly. Its two fundamental weaknesses — the password hash functions as the credential, and the authentication is not bound to a service — are the reason two of the most durable Windows attacks exist. This article is about the protocol itself; how attackers get clients to authenticate to them in the first place is covered under LLMNR and NBT-NS poisoning.

The challenge-response exchange

A client requests access. The server sends a random challenge. The client computes a response using the challenge and its NT hash — a hash derived from the password — and returns it. The server, or a domain controller on its behalf, computes the same value and compares.

The password itself never crosses the network, which was the design goal. What matters is what follows from the details.

NTLMv1 uses a weak construction that can be broken to recover the hash outright and should be disabled everywhere. NTLMv2 adds a client challenge and a timestamp, which is considerably stronger but does not change the two structural problems below.

Pass-the-hash

Because the response is computed from the NT hash rather than from the password, the hash is the credential. An attacker who obtains it does not need to crack anything — they can authenticate with it directly.

Hashes are obtainable from memory on a machine where the user has a session, from the local account database, or from a domain controller's directory database. And the NT hash is unsalted and fast to compute, so where cracking is attempted, it is quick.

The practical consequence is that a single compromised machine yields working credentials for every account that has logged on to it, and those credentials work anywhere the account has rights. This is why a domain administrator logging on to a workstation is a serious finding, and why administrative tiering matters more than password complexity here.

Relay

The second structural problem is that an NTLM authentication is not bound to the service it was intended for. An attacker who receives an authentication attempt can forward the challenge and response to a different server and be authenticated there as the victim.

No cracking, no password, no hash even — the attacker simply sits in the middle and passes messages. If the relayed account has administrative rights on the target, that is code execution.

Cross-protocol relay extends this: authentication captured over one protocol can often be relayed to another — to LDAP, to certificate enrolment services, to web services using Windows authentication. Certificate service relay is particularly damaging, because a certificate obtained this way is a durable credential that survives a password reset.

The specific control is signing. SMB signing, LDAP signing, and channel binding on services using TLS all bind the authentication to the session, so a relayed exchange fails validation. Requiring signing — not merely enabling it if the peer asks — closes the relay path even where poisoning still works.

Why Kerberos is different

Kerberos issues a ticket for a named service, so an authentication intended for one service cannot be presented to another. That service binding is the property NTLM lacks, and it is why relay does not apply.

Kerberos has its own attacks — ticket theft, forged tickets, and offline cracking of service account passwords, covered under Kerberoasting — but they require different preconditions and different defences. The exam distinction to hold: Kerberos uses tickets bound to services with mutual authentication; NTLM uses a challenge-response that is not bound to anything.

Reducing and removing NTLM

Start by finding out where it is used, since almost nobody knows. Enable NTLM auditing, collect the events, and build the inventory — the answer is usually a handful of legacy applications, some scanners and appliances, and connections made by IP address rather than by hostname, which forces NTLM because Kerberos needs a service principal name.

Then restrict progressively. Disable NTLMv1 immediately. Require SMB and LDAP signing and enable channel binding. Use Group Policy to block NTLM to specific servers, then to block it outbound with exceptions, then to deny it entirely as the exception list empties. Newer Windows releases add negotiation improvements that reduce the fallback cases.

Protect the credentials in the meantime: unique local administrator passwords per machine, Credential Guard to keep secrets out of reachable memory, tiered administration so privileged hashes never land on workstations, and the vaulting and just-in-time model described under privileged access management.

Exam angles

Know NTLM as challenge-response authentication where the password hash is the credential, enabling pass-the-hash, and where the authentication is not service-bound, enabling relay. Identify SMB and LDAP signing and channel binding as the relay mitigations, and unique local administrator passwords plus administrative tiering as the pass-the-hash mitigations. Contrast with Kerberos, whose service-bound tickets prevent relay, and recognize disabling NTLMv1 as a baseline hardening step.