Windows - Security - Disable Weak NTLM Versions

What the NTLM Version Enforcer does

This Automox Worklet™ configures the LAN Manager authentication level on Windows endpoints to require NTLMv2 and refuse older authentication protocols. NTLM (NT LAN Manager) is a Windows authentication protocol that has evolved through multiple versions, with older versions containing significant security weaknesses.

The Worklet sets the LmCompatibilityLevel registry value at HKLM:\SYSTEM\CurrentControlSet\Control\Lsa to 5, which configures the endpoint to send NTLMv2 responses only and refuse LM and NTLM connections. This is the highest security setting for NTLM authentication.

The Worklet examines registry keys including HKLM:\SYSTEM\CurrentControlSet\Control\Lsa.

Before modifying settings, the Worklet backs up the existing LmCompatibilityLevel value to LmCompatibilityLevelBAK. This enables administrators to restore the original configuration if compatibility issues arise with legacy systems or applications.

Why enforce NTLMv2-only authentication

Legacy LM and NTLMv1 authentication protocols create critical security risks through weak cryptographic algorithms that attackers can crack in minutes. When endpoints accept these legacy protocols, attackers use tools like Responder, Inveigh, and ntlmrelayx to intercept authentication traffic, extract password hashes, and launch pass-the-hash or credential relay attacks. LM hashes split passwords into seven-character chunks using obsolete DES encryption, while NTLMv1 remains vulnerable to rainbow table attacks and efficient cracking with modern hardware. This Automox Worklet enforces NTLMv2-only authentication to eliminate these attack vectors by using stronger cryptography and challenge-response timestamps that significantly increase attack difficulty.

Microsoft and security frameworks including CIS Benchmarks recommend configuring endpoints to use NTLMv2 only. This setting aligns with the principle of defense in depth by reducing the attack surface even when attackers are positioned to intercept authentication traffic.

How NTLM version enforcement works

1. Evaluation phase: The Worklet checks the LmCompatibilityLevel registry value at HKLM:\SYSTEM\CurrentControlSet\Control\Lsa. If the value does not match the desired setting (5 for NTLMv2 only with LM and NTLM refused), the endpoint requires remediation. The Worklet supports a null value for reverting to default behavior.

2. Remediation phase: If an existing LmCompatibilityLevel value exists, the Worklet backs it up to LmCompatibilityLevelBAK before making changes. It then sets LmCompatibilityLevel to 5 (NTLMv2 only, refuse LM and NTLM). If the target value is null, the Worklet restores from backup or removes the registry value to return to default Windows behavior.

NTLM version enforcement requirements

• Windows Vista or later, Windows Server 2008 or later

• Administrative privileges to modify HKLM registry

• All network infrastructure and applications must support NTLMv2

• Legacy systems (Windows XP, Windows Server 2003) that require LM or NTLMv1 must be upgraded or excluded

Expected authentication behavior after remediation

After remediation, you can expect these specific outcomes:

• The LmCompatibilityLevel registry value at HKLM:\SYSTEM\CurrentControlSet\Control\Lsa will be set to 5

• The endpoint will send only NTLMv2 authentication responses and refuse LM or NTLMv1 connections

• A backup of the original value will be stored at LmCompatibilityLevelBAK for rollback capability

• You can verify the change using Get-ItemPropertyValue -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name LmCompatibilityLevel

How to validate disable weak ntlm versions changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for disable weak ntlm versions.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as CIFS-GENERIC, Test-Reg, Test-Path.

4. Validate remediation effects from script operations such as CIFS-GENERIC, Add-Prop, Test-Path, then rerun evaluation for compliance.