OK, now it’s really time to disable Net-NTLMv1

The risks of poisoning attacks against Net-NTLMv1 have grown with the release of an 8.6TB rainbow table. Net-NTLMv1 isn’t fully dead yet, but it should be.

What is NTLM?

New Technology LAN Manager, i.e. NTLM, is a protocol mechanism that Microsoft has used as a basis for authentication handling for years. It is the successor to the infamous LM (LAN Manager) protocol.

LM is known for being insecure in many of its own ways, such as being a maximum of 14 characters, including null padding if the password is less than 14 characters long, and is split into two separate DES keys that are easily crackable.

How does NTLM work?

Being a challenge and response mechanism, NTLM operates by exchanges hashed data between systems to authenticate. The exchange at a high level is like:

1. User logs on to a computer with their username and password (and domain).
2. Computer stores the hash of the password.
3. Client computer sends the username to the destination server in plaintext.
4. Server responds with a challenge (an 8-byte nonce).
5. Client computer encrypts the challenge with the user’s password hash and returns it to the server.
6. Server then forwards the username, the challenge, and the client response to a domain controller.
7. The domain controller then uses the username to retrieve the hash from the directory, and uses the password hash to encrypt a challenge.
8. The domain controller then compares the original encrypted challenge forwarded by the server to the one it computed. If successful, authentication is granted.

The gist is that the user and destination server create a challenge and response together, which is then compared to a challenge independently created by an authenticating domain controller.

What’s the difference with LM, NTLM, and Net-NTLMv1/v2?

It can get a little confusing with naming. In the pentest world there are some colloquialisms, but here’s a rough high-level breakdown:

• LM / NTLM – Generally referred to as being the hash of the user’s password, which is stored locally for local user accounts or in LSASS, or on the domain controller within a domained network.
• NTLMv1 / NTLMv2 – Also known as Net-NTLMv1 and Net-NTLMv2, which is the challenge and response. The ‘hash’ here is usually what is being compared during the authentication process.

Generally speaking, NTLM is straight one-way cryptographic hash (128 bits) of a user’s password. Net-NTLMv1/v2 “hashes” are obtained (in an attacking sense) from poisoning requests to interactions like SMB shares, RDP connections, and so forth.

Why should I be concerned about Net-NTLMv1?

For starters, Microsoft have stopped developing the NTLM suite as of a few years ago. But, all of the NTLM functionality remained enabled by default. Kerberos is the recommended authentication mechanism as it stands today, but Windows would still fallback to NTLM authentication if/when Kerberos fails.

As you can imagine in a situation where an attack is being performed, the goal of the attacker would be to obtain Net-NTLM hashes and forcing a victim’s system to use this would bypass Kerberos.

Equally, connecting via an IP address to a system resource compared to a fully-qualified domain name will still use NTLM – there are a few ways to force Kerberos authentication that require additional configuration.

What this means in practice is that Net-NTLMv1 and Net-NTLMv2 can be abused by an internal threat to move laterally within a network via an initial poisoning attack. A successful attack would allow the attacker to obtain the hash of a challenge/response with a challenge that is controlled by them (e.g. 1122334455667788).

This could be your pentesters, which of course would be an annoyance when the report comes in. But it could be a more credible threat that has been able to gain a foothold on your network.

The way that “password cracking” attacks are normally performed for Net-NTLM hashes is through dictionary, mutation, and even brute-force cryptanalysis. Rainbow tables have been around for decades, and were used to great effect on LM/NTLM hashes – but were often a bit painful to precompute and store the much larger data used for more complex hash mechanisms.

However, Google (Mandiant) have publicly released a rainbow table of a whopping 8.6TB of pre-computed hashes back in December 2024 (but have only now blogged about it).

Critically, what this means for businesses is:

• Your pentesters might arrive for internal pentests with a sizeable set of external hard-drives.
• Your organisation is potentially at an even greater risk to compromise from more advanced threats if you still have Net-NTLMv1 enabled on your internal network.

How do I secure against attacks on Net-NTLMv1?

The good news is that if you have Windows Server 2025 and Windows 11 (24H2) throughout your infrastructure then NTLMv1 has been removed.

If you’re still in a transition phase for upgrading your systems, then you will need to consider disabling Net-NTLMv1 entirely. Unless you’re on a legacy system, of which you likely have larger concerns, then you shouldn’t see any impact to operations.

There may be a requirement to keep NTLMv1 enabled on networks that interface with non-Windows devices like printers, for example. In this case, it’s highly recommended to audit the event log to identify traffic that still communicates through this.

Most importantly – validate what could potentially break before making any sweeping changes. Take a look at the monitoring section below.

Monitoring for NTLMv1 authentication

Enabling and monitoring the “Logon Success Auditing” event will allow you to observe the event ID “4624”. This will log Success events that will contain information about NTLM versions.

Within the log you’ll be looking for “Authentication Package” and “Package Name (NTLM only)”, with the latter detailing the NTLM version used.

Here’s an excerpt of an example courtesy of Microsoft:

Detailed Authentication Information:  
Logon Process: NtLmSsp  
Authentication Package: NTLM  
Transited Services: -  
Package Name (NTLM only): NTLM V1  
Key Length: 128

Disabling Net-NTLMv1

It is highly recommended to disable NTLMv1 entirely by configuring your systems to enable “NTLMv2” only. There are a few ways to do this depending upon whether you’re configuring a local system or a domain controlled system.

Disabling via Group Policy

1. Configure a new group policy
2. Navigate to:
   • Computer Configuration
   • Policies
   • Windows Settings
   • Security Settings
   • Local Policies
   • Security Options
   • Network Security: LAN Manager authentication level
3. Enable “Send NTLMv2 response only”

You can enable NTLMv2 authentication via the Windows Registry, such as on a Domain Controller, but be warned about configuring a setting incorrectly!

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa > LMCompatibilityLevel: 5

Disabling Locally

1. Open the local computer policy panel
2. Navigate to:
   • Local Security Settings
   • Local Policies
   • Security Options
   • Network Security: LAN Manager authentication level
3. Enable “Send NTLMv2 response only”

By implementing these changes the affected system will only utilise NTLMv2.