Learn Active Directory - NTLM Authentication

#Introduction

In episode 13 we dissected Kerberos — the modern, ticket-based authentication protocol that is AD's standard. Now it's time to face the other side that can't be ignored: NTLM, the legacy protocol that still lives in almost every Windows environment, even though we'd all like it to retire.

Why is it still relevant to study? Because as long as there are old devices or applications that don't support Kerberos, NTLM will remain an available authentication path — and every available path is an attack surface. You can't turn off something you don't understand, and you can't secure an environment you don't realize still uses NTLM.

Imagine NTLM as an emergency door installed decades ago. It used to be the only door; now it's ancient and easy to bypass, but some building occupants still use it because it's convenient. Your job as an AD admin is to map who still uses that door, push them toward the safe main entrance, then lock that emergency door forever.

#How NTLM Works: Challenge-Response

Unlike ticket-based Kerberos, NTLM uses a challenge-response mechanism — a kind of riddle that must be answered. The flow is three steps:

1. Negotiate — the client sends a NEGOTIATE message to the server: "I want NTLM authentication, here are my capabilities."
2. Challenge — the server replies with a CHALLENGE: a random number (nonce) as the "question".
3. Authenticate — the client computes the response by encrypting that nonce using its password's hash, then sends it back along with the username and domain. The server performs the same calculation with the hash it holds; if the results match, the user is proven authentic.

The crucial point: what's sent isn't the password, but the password's hash (the NT hash) used as the encryption key. That's where the biggest weakness lies — because it's this hash that can actually be stolen and replayed, as we'll see shortly.

Client --> Server : NEGOTIATE  (I want NTLM authentication)
Server --> Client : CHALLENGE  (here's a random nonce for you)
Client --> Server : AUTHENTICATE (response = hash(nonce, NT hash of password))
Server          : verifies with the hash it holds

#NTLMv1 vs NTLMv2: Two Generations of Weakness

NTLM comes in two main versions. Both have problems, but not equally severe:

NTLMv1 is considered severely broken — its key is too short and modern cracking techniques (e.g. with GPUs) can break it in minutes. NTLMv2 is much better, but still inherits the structural weaknesses of the NTLM family: no mutual authentication and credentials that can be abused.

#Why NTLM Is Dangerous

NTLM's problem isn't just cryptography — it opens up several of the most popular attack techniques in the AD attacker world:

1. Pass-the-Hash. An attacker who steals an NT hash (e.g. from a memory dump on one machine) doesn't need to know the real password. They can just use that hash directly to log into other systems that accept NTLM. The hash is a "key copy" that can be used repeatedly — and since NTLM only verifies the hash, the real password is never needed.

2. NTLM Relay Attack. Instead of using the hash, the attacker forwards a legitimate challenge-response. Picture the attacker standing in the middle and connecting two ends of a conversation: they get machine A to authenticate to them, then forward that proof to machine B. Machine B believes the attacker is machine A. Without mutual authentication, no party can detect the deception.

3. No mutual authentication. A fake server can pretend to be a legitimate service to capture credentials — exactly what Kerberos prevents with AP-REP.

4. Weak cryptography. NTLMv1 can be cracked; even NTLMv2 is only as strong as the NT hash that's sent, which lacks the salt protection of modern hashes.

All of these attacks are the reason behind every recommendation we covered in episode 12 — Protected Users disables NTLM, and you should disable NTLM in your environment.

#Detecting NTLM Usage: You Can't Disable What You Can't See

Before disabling NTLM, you need to know who is still using it. The NTLM audit policies in GPO provide three modes that work like a traffic light:

• Audit — only records who uses NTLM, without disturbing anything. Start here.
• Deny domain accounts — blocks NTLM for domain accounts while still allowing local accounts.
• Deny all — blocks NTLM completely. The final mode, only after you're confident the environment is clean.

The setting's location in the GPO Editor: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, on the settings starting with Network security: Restrict NTLM....

With auditing active, NTLM events are recorded in the event log. A quick way to read those records is Get-WinEvent:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=8004} -MaxEvents 20 |
    Select-Object TimeCreated, Message

Event 8004 indicates a client successfully authenticated via NTLM (not all such events are dangerous — some modern applications still use it for certain scenarios, e.g. interactive logons to machines without a domain trust). Events 8001, 8002, and 8003 give similar context for different client and server types. Collect data for one to two weeks in a real environment before making decisions.

#Disabling NTLM Gradually

Disabling NTLM isn't a one-way switch — it's a gradual process with a rollback path. The recommended sequence:

1. Audit first. Enable audit mode for incoming and outgoing NTLM. Let it run long enough to cover the whole work cycle (including morning logons, night batches, and maintenance).
2. Analyze. List all hosts and applications still using NTLM. Group them: which can migrate to Kerberos, which need temporary exceptions.
3. Fix the source. Applications that can use Kerberos (supporting SPNs and domain integration) are directed to the safe path. Old devices that can't be changed become candidates for limited exceptions.
4. Tighten. Change the policy to Deny domain accounts, then watch for breakage. If clean, proceed to Deny all.
5. Maintain. Make "NTLM = 0" a routine monitoring item, not a one-time task.

#NTLM Alternatives

If a system can't use Kerberos, that doesn't mean you must resign to NTLM forever. Several alternative paths:

• Kerberos — the primary path. Modern domain-joined systems almost always support it.
• Certificates and smart cards — asymmetric-cryptography-based authentication, far stronger and not dependent on password hashes. Suitable for high-security scenarios.
• Managed Service Accounts (gMSAs) — for services running on Windows, whose passwords AD manages, so there's no more "hash in a config file".

In most environments, migrating to Kerberos answers 90 percent of NTLM usage. The rest — irreplaceable legacy devices and applications — are confined to isolated network segments with minimal exceptions and strict monitoring.

#Conclusion

In this episode we dissected NTLM thoroughly: the challenge-response mechanism at the protocol's core, the difference between severely broken NTLMv1 and better-but-still-weak NTLMv2, and the real risks of pass-the-hash, NTLM relay, and the absence of mutual authentication. We also learned how to detect NTLM usage via auditing and event 8004, a gradual NTLM disabling strategy via Group Policy, and its alternatives.

The takeaway: NTLM is a protocol whose time to retire has come — and the retirement process starts with awareness (auditing), not sudden prohibition. The less NTLM surface in a domain, the narrower the attacker's room to maneuver.

In the next episode 15, we shift from who gets in to what they can do once in: Access Control & Permissions — NTFS and share permissions, ACLs, inheritance, and delegating permissions within Active Directory itself. Keep the momentum going!