When performing Security checks in customer environments I often find out that Lan Manager or NTLMv1 is still allowed. Most customers don't know that this setting leaves the environment highly vulnerable to attacks targeting their authentication methods.

Why you should not use Lan Manager and NTLMv1 anymore you will read in this article.

What's the problem with Lan Manager?

Lan Manager is the 'grandpa of authentication' in Windows Systems. It was implemented in 1987 and nowadays it is old and deprecated. And yes of course, it can be broken easily.

This protocol is still used by Windows-NT based operating systems to store Password Hashes. And due to backward compatibility issues it is still in use: If a password is stored, which is shorter than fifteen Characters, a LM-Hash is generated and used.

A LM-Hash is NOT case-sensitive: Before creating the hash, all characters are being casted to uppercase characters. So it does not matter if upper or lower characters were used when creating the password.

But there is also another vulnerability, caused by the first implementation of this protocol

In the earliest implementation, it was supposed that a password will never be longer than seven characters. Therefore the initial length of passwords could not exceed seven characters. Eight Bit were used to store it: seven Bits for the password plus one parity bit.

When computer systems became faster and stronger, Brute-Force attacks became an issue to those "secure" eight Bit passwords. They could easily be guessed, so it was decided to add more characters to the passwords.

But since everyone was using a password which was generated with the old recommendations and the old protocol, the new password authentication mechanism had to be backward compatible to avoid business disruption.

Therefore a new mechanism was built: eight more Bits (again seven Bits for the password, one parity Bit) were added to the password to enable passwords up to fourteen characters. To maintain the usability of the old passwords, the new Bits were concatenated to the old half.

Both halves were hashed and concatenated: That's how the actual LM password hash was created.

It was considered that this hash will not be broken that easily. But that was not the truth...

There is still a risk after the fix

This mechanism is still risky: if a password is shorter than fourteen characters, all unfilled bits will be filled with NULLs. So if a password is shorter than 8 characters, the second half (the new half) will remain empty and will be filled with those zero values.

Both halves - again - will be hashed and concatenated. But since the second half only contains zeroes, a hash over those zeroes is created.

So every time the second half is filled with zeroes, the same hash value will be used for the second part of the password.

If the password is split in two halves an attacker could compare the second half with the default hash for a password containing only zeroes. If it matches, the attacker can be sure that the password has less than seven characters.

Breaking the hash of the first half is easy: the attacker only needs to compare his prepared rainbow tables with the actual hash value and can easily break the password.

NTLM

To understand why you should not use NTLMv1 anymore, you have to understand how this protocol works. NTLM is a challenge/response-based authentication protocol. It is the default authentication protocol of Windows NT 4.0 and earlier Windows versions.

How NTLM basically works

1. When logging on, the client sends the plaintext user name to the server.
2. The server generates a random number ("challenge") and sends it back to the client.
3. The hash of the user name is used to encrypt the challenge, received from the server and returns the result back to the server ("response").
4. The server sends the following three items to the domain controller to verify that the requesting user is allowed to log on:
   • User name
   • Challenge (which was sent to the client)
   • Response (which was received from the client)
5. The domain controller looks up the user name and gets the corresponding password hash out of the Security Account Manager database and unses it to encrypt the challenge.
6. The domain controller compares the encrypted challenge it computed earlier with the response computed by the client. If both are identical, the authentication is successful.

How to deactivate Lan Manager and NTLMv1

Please be careful when deactivating Lan Manager and NTLMv1 - really!!!

Many old devices in your environment could still use those old authentication protocols. Some devices support NTLMv2, but only after configuring it on the device. So don't disable Lan Manager and NTLMv1 without knowing which devices still use it.

First step: Audit!

Prior to disabling those old authentication protocols: Listen to your devices - or better: Audit them!

If you don't know which devices are relying on Lan Manager or NTLMv1, you can't disable it without crashing some of your systems.

1. Collect Audit Logs in a central log collection.
2. Filter for Event Logs with the Event ID 4624 - An Account was successfully logged on.
3. In this event you will find the section "Detailed Authentication Information"
   1. If the "Authentication Package" was NTLM, NTLM was used as authentication method
   2. Now have a look at "Package Name (NTLM only)", if LM or NTLMv1 is the value of this attribute, Lan Manager or NTLMv1 was used
4. Investigate all clients/servers where Lan Manager or NTLMv1 was used: why are they using this deprecated authentication protocol?

When you have investigated and upgraded every device to use NTLMv2, you are ready to enforce NTLMv2 globally in your environment.

Enforce NTLMv2 only

So, you have audited your logon events and found out that no device is using old authentication protocols? You are ready to enforce NTLMv2? Very good! Read here how to do it.

The magical key you are looking for is called Lan Manager Authentication Level. This setting defines which authentication level is used.

You can either enforce it locally or via GPO:

• Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity OptionsNetwork security: LAN Manager authentication level

Since there are 6 levels (from 0 to 5), that means 0 is the most insecure setting, but also the default. 5 is the most restrictive and most secure level - but hard to achieve.

If you want to set your LAN Manager authentication level as high as possible, start with Level 3: This level enables NTLMv2 as default, but still allows a fallback to Lan Manager and NTLMv1 in case the client is not able to use NTLMv2.

Then audit, audit, audit a lot to find out which devices are still using Lan Manager and eliminate them. If there is no client/server using Lan Manager anymore, you can set the level to 4.

And again: Audit, audit, audit, audit and audit once more! Is there really no device left which is using NTLMv1? Nice, you can set your lan manager authentication level to 5. Congratulations, you've just eliminated your old and vulnerable authentication protocols! Really good job!