Disabling NTLM: Retiring the Protocol Behind Pass-the-Hash and Relay

NTLM is 30 years old, and it is still the single authentication protocol most likely to get your Windows environment breached. Kerberos was supposed to replace it back in Windows 2000, yet NTLM lingers everywhere — in hardcoded IP-address connections, on legacy appliances, in scanner service accounts, and as the automatic fallback whenever Kerberos can't find a Service Principal Name. Every attacker toolkit — Responder, ntlmrelayx, mimikatz, Rubeus — has a mode built specifically to abuse it. If you only harden one authentication surface this quarter, make it this one.

Why NTLM is dangerous by design

NTLM authenticates by proving knowledge of a password hash, and that hash is used directly as the credential. This produces two structural weaknesses that no patch can fix:

• Pass-the-Hash: Because the NT hash is the credential, an attacker who dumps it from LSASS or the SAM never needs to crack it. They replay it as-is to authenticate to any host that accepts NTLM.
• NTLM Relay: NTLM has no channel binding by default and no mutual authentication of the server. An attacker who can coerce a victim into authenticating (via PetitPotam, a poisoned LLMNR response, or a malicious file path) relays that authentication in real time to a target like LDAP, SMB, or AD CS — no cracking, no hash, just a live man-in-the-middle.

Kerberos, by contrast, uses time-limited tickets and supports mutual authentication and channel binding. Moving to Kerberos-only closes both attack classes at the protocol level.

Step one: audit before you break anything

The reason NTLM survives is fear — nobody knows what will break if they turn it off. Windows solves this for you. Set the domain controllers and member machines to audit NTLM traffic first, then read the logs before enforcing anything.

Turn on auditing via Group Policy or directly in the registry on a member host:

Security Options:
  Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all
  Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts

# On domain controllers, NTLM usage lands in:
#   Applications and Services Logs > Microsoft > Windows > NTLM > Operational
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 200 |
  Where-Object Id -in 8001,8002,8003 |
  Select-Object TimeCreated, @{n='Msg';e={$_.Message.Split("`n")[0]}}

Let this run for two to four weeks so you capture monthly batch jobs and quarter-end processes. The output tells you exactly which source hosts, which accounts, and which target servers still rely on NTLM.

Step two: fix the callers, not the symptom

Most NTLM usage falls into a handful of fixable patterns:

1. Connections by IP address instead of hostname. Kerberos needs an SPN, and SPNs are name-based. Change \\10.0.0.12\share to \\fileserver01\share and the same session negotiates Kerberos.
2. Missing or duplicate SPNs. Use setspn -Q to find services whose SPN is missing or registered on the wrong account; fix them so Kerberos can be selected.
3. Legacy appliances and scanners. Vulnerability scanners and old NAS boxes are chronic offenders. Update firmware, or scope them into a short NTLM exception list rather than leaving the whole domain open.

The goal of the audit phase is a shrinking list. Each entry you resolve is one fewer excuse to keep the protocol enabled domain-wide.

Step three: enforce and add relay defenses

Once the audit list is empty (or down to a documented exception set), flip Restrict NTLM: NTLM authentication in this domain to Deny all, using the Add server exceptions list for the stragglers. Pair that with the controls that neutralize relay even where NTLM must remain:

• SMB signing required on all hosts — blocks SMB relay outright.
• LDAP signing and channel binding (EPA) on domain controllers — kills the classic relay-to-LDAP privilege escalation.
• Disable LLMNR and NBT-NS so attackers can't harvest NTLM authentications with Responder in the first place.
• Enforce Extended Protection for Authentication on IIS, Exchange, and AD CS web enrollment endpoints.

How WinSentinel helps

NTLM exposure is not a single checkbox — it's a posture that spans registry policy, SMB and LDAP signing state, LLMNR/NBT-NS configuration, and cached-credential hygiene. WinSentinel's free single-machine audit inspects every one of those on the host it runs on, flagging NTLM fallback settings, unsigned SMB, LLMNR left enabled, and LSASS protection gaps, with the exact remediation for each. Nothing is throttled: all 33 modules run at full depth on that machine, free.

For organizations, the Pro tier turns that per-host posture into a fleet program. A central node collects NTLM-restriction and signing state across every managed endpoint, rolls it into a compliance view, and raises drift alerts the moment a machine re-enables NTLM or loses SMB signing after a reimage — so a two-week audit isn't a one-time project but a continuously enforced baseline across 50 or 500 machines.

NTLM won't disappear on its own. Audit it, fix the callers, enforce Kerberos-only, and keep watching for drift. The attack toolkits already assume you didn't.