What is NTLM Authentication?

Definition

NTLM (NT LAN Manager) is a challenge-response authentication protocol developed by Microsoft. It was the primary Windows authentication protocol before Kerberos and remains widely supported as a fallback in Active Directory environments.

NTLM exists in two main versions:

• NTLMv1 — weak, deprecated, should be disabled.
• NTLMv2 — stronger but still vulnerable to relay and reuse.

In simple terms:

NTLM is the older Windows authentication protocol that's still around — and still helping attackers.

---

Why NTLM Matters

• Many environments still depend on NTLM for legacy applications, file shares, or services that don't support Kerberos.
• NTLM is the foundation of multiple severe attacks: Pass-the-Hash, NTLM relay, and various AD CS abuses.
• Microsoft has signaled NTLM's deprecation and recommends migration to Kerberos / modern auth.

---

How NTLM Works

Challenge-Response Flow

1. Negotiate — client requests NTLM authentication.
2. Challenge — server sends a random nonce.
3. Response — client encrypts the nonce with its NTLM hash.
4. Validation — server (or DC via netlogon) validates the response.

The NTLM hash is derived from the user's password and never expires unless the password changes.

Properties

• No mutual authentication (in basic NTLM).
• No defense against relay by default.
• Hash is functionally equivalent to the password for authentication purposes.

---

Common NTLM Attacks

1. Pass-the-Hash (PtH)

Attackers steal NTLM hashes (e.g., from LSASS) and use them to authenticate without knowing the plaintext password.

2. NTLM Relay

Attackers force a victim to authenticate to them (using protocols like SMB, HTTP, RPC), then relay that authentication to another service to impersonate the victim.

• PetitPotam — coerces DC authentication.
• PrinterBug — abuses the print spooler.
• Relay to AD CS (ESC8 / ESC11) — relay authentication to a certificate web service to obtain certificates.

3. NTLMv1 Cracking

NTLMv1 challenge-response can be cracked offline with reasonable hardware.

4. Net-NTLMv2 Capture

• Responder, Inveigh — listen for NTLM authentication broadcast (LLMNR, NBT-NS, mDNS) and capture hashes for offline cracking or relay.

5. Hash Cracking

NTLM password hashes captured from NTDS.dit or memory are cracked with modern GPU rigs at high speed.

---

Real-World Examples

1. PetitPotam → AD CS → Domain Admin

Attacker uses PetitPotam to coerce DC to authenticate to attacker-controlled host, relays the auth to AD CS web enrollment, obtains a certificate as the DC, and uses it to perform DCSync.

2. Pass-the-Hash Lateral Movement

Attacker dumps NTLM hashes from a compromised workstation, finds a Tier 1 admin's hash, and authenticates to many servers as that admin without needing the password.

3. LLMNR Poisoning

Attacker on the LAN poisons LLMNR/NBT-NS responses. A user's machine sends NTLMv2 challenges to the attacker, who cracks weak passwords offline or relays to other services.

4. Legacy App Forcing NTLM

A legacy app doesn't support Kerberos. Every authentication flows over NTLM. Compromise of the app server exposes hashes of every user who ever logged in.

---

NTLM Hardening Best Practices

1. Inventory NTLM usage. Use Audit policy to log NTLM authentication and identify dependencies.
2. Disable NTLMv1 entirely.
3. Restrict NTLM progressively:
   • Network security: Restrict NTLM policies.
   • Block outgoing NTLM where possible.
   • Add exceptions only for verified legacy needs.
4. Disable LLMNR and NBT-NS to remove poisoning surface.
5. Enable SMB signing to prevent SMB relay.
6. Enable LDAP signing and channel binding to prevent LDAP relay.
7. Enable EPA (Extended Protection for Authentication) on web services.
8. Disable the Print Spooler on systems where it's not needed (especially DCs).
9. Patch PetitPotam and related vulnerabilities.
10. Segment legacy systems that still require NTLM.
11. Detect anomalous NTLM authentication patterns (NTLMv1 use, relay indicators).
12. Plan migration to Kerberos / modern auth for legacy applications.

---

NTLM Security Checklist

• NTLM usage inventoried via auditing?
• NTLMv1 disabled?
• LLMNR and NBT-NS disabled?
• SMB signing enabled?
• LDAP signing and channel binding enforced?
• EPA enabled on web services?
• Print Spooler disabled where not needed?
• PetitPotam mitigations applied?
• Outbound NTLM restrictions in place?
• Legacy NTLM dependencies tracked with retirement plans?
• NTLM relay / Pass-the-Hash detections live?

---

How Forestall Helps

Forestall analyzes the AD environment to surface NTLM-related exposure:

• Hosts and accounts heavily reliant on NTLM.
• Web services without EPA, LDAP without signing, SMB without signing.
• AD CS templates vulnerable to NTLM relay (ESC8 / ESC11).
• Print Spooler exposure on Tier 0 systems.
• Attack paths that begin with NTLM relay or Pass-the-Hash.

---

Frequently Asked Questions

Can I disable NTLM completely?

Eventually, but it requires inventory, dependency analysis, and migration. Most environments restrict it tightly long before fully disabling.

Why is NTLMv2 still vulnerable?

It's resistant to direct password recovery from challenge-response, but still vulnerable to relay and to offline cracking when passwords are weak.

What replaces NTLM?

Kerberos for AD-integrated apps; OAuth/OIDC and SAML for modern web apps.

Is Pass-the-Hash still relevant?

Yes — wherever NTLM is allowed and credential hygiene is weak. EDR, Credential Guard, and tiered admin reduce the impact.

How dangerous is PetitPotam?

Without mitigations, it can lead directly to Domain Admin via AD CS relay. Apply patches, restrict NTLM, enable EPA on AD CS, and harden CA configurations.

---

Conclusion

NTLM is a legacy protocol that has outlived its security model. Every organization should be on a path to restrict it, then disable it. Until then, harden everything around it: enable signing and channel binding, disable poisoning vectors, secure AD CS, and detect relay and reuse. Each NTLM dependency you eliminate removes a class of attack from your environment.