NTLM/LM Hashes on Domain Controller

Question

I've noticed that when extracting password hashes from a domain controller (using Elcomsoft proactive password auditor) sometimes I'll get LM and NTLM hashes and other times I'll only get NTLM hashes.

I note that the NTLM + LM hashes (the accounts that contain both sets) are recovered orders of magnitude faster than the hashes that are only NTLM.

I'm curious as to why this is the case?

I understand that LM is the older and weaker of the two, but I don't understand why both LM and NTLM are being stored in these scenarios?

More importantly, given that it appears that NTLM hashes exclusively are the safer option, how can I enforce NTLM only and remove existing LM hashes for users?

Answer 1

There' a pretty good Microsoft KB article on this exact subject.

Basically, LM is used for compatibility with older clients. Specifically, Windows 98 and below. If you do not have any older clients on the network, then the cause for both hashes is most likely due to the password length being <15 characters.

When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password.

It appears that the reason for this is due to the hashing limitations of LM, and not security related.

In the event that the user's password is longer than 15 characters, the host or domain controller will not store the LM hash for the user; the LM response cannot be used to authenticate the user in this case. A response is still generated and placed in the LM Response field, using a 16-byte null value (0x00000000000000000000000000000000) as the LM hash in the calculation. This value is ignored by the target.

It is advised to disable LM hashes as the protocol is severely broken as you suggested. For those who might not be aware, some of the problems with LM's include:

• Passwords are not case sensitive.
• Password are split into 7 chars and hashed seperately, making brute force trivial.
• Passwords are limited to a maximum of 14 characters in length.

There are a couple methods to removing LM hashes listed on the KB article I mentioned, I will quote the GPO method in case the link goes bad.

Method 1: Implement the NoLMHash Policy by Using Group Policy

To disable the storage of LM hashes of a user's passwords in the local computer's SAM database by using Local Group Policy (Windows XP or Windows Server 2003) or in a Windows Server 2003 Active Directory environment by using Group Policy in Active Directory (Windows Server 2003), follow these steps:

1. In Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
2. In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.
3. Click Enabled, and then click OK.

Answer 2

As a follow up to David's answer I wanted to point out this article (I can't add a comment):

Protecting Privileged Domain Accounts: LM Hashes: The Good, the Bad, and the Ugly

It shows that even when clients are told not to store LM hashes in the SAM database, they will still be held in memory and can be dumped to a file.