SANS Digital Forensics and Incident Response Blog

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

[Author's Note: This is the 2nd in a multi-part series on the topic of "Protecting Privileged Domain Accounts". My primary goal is to help incident responders protect their privileged accounts when interacting with comprised hosts, though I also believe this information will be useful to anyone administering and defending a Windows environment.]

I realize the LanMan (LM) hash is old-hat for many, but I've recently discovered that the LM hash is even more dangerous than I previously realized. This is due to both the ease of cracking LM hashes on today's hardware, as well as the obscure fact that there is currently no Microsoft-provided feature to remove LM hashes from memory. So even if you think you've heard it all with regard to LM hashes, I encourage you to read on to make sure you are aware of LM hashes lurking in memory.

The Bad

Although the issues with LM hashes are well-documented, let me just briefly describe how LM hashes are created and you will immediately recognize several significant issues with this algorithm. These issues highlight exactly why we need to get rid of the LM hash. In a nutshell, here's how the algorithm works, per Wikipedia:

  • The user's ASCII password is converted to uppercase
  • This password is null-padded to 14 bytes
  • The "fixed-length" 14-byte password is split into two 7-byte halves
  • Each of the two halves is used with the DES function to create two 8-byte cipher-text values
  • The two cipher-text values are concatenated to form a 16-byte value, which is the LM hash
  • No salt is used in the creation of the hash

There are plenty of bad choices that were made in the design of this algorithm. Let me quickly point out a few:

  • The fact that each character is an ASCII character, which provides just 95 printable characters, means that there should be only 95 possibilities per character of the password. However, it's worse than that because each lowercase character is converted to uppercase, so in fact there are only 69 possibilities per character of the password.
  • The maximum number of characters in a password is 14. Anything less than that gets padded with null bytes to 14. The resulting 14-character value is then split in half. Splitting the value in half greatly reduces the search space for any password cracking software. It now just has to guess 2 values within 697 (~7.5 trillion) versus one value within 6914 (~ 55 septillion). This results in nearly 13 orders of magnitude difference, making it a significantly easier problem for cracking software to solve for the two 7-character halves.
  • Finally, there is no salt. A salt is an extra piece of data, which typically differs per machine and/or per user, that is added to the clear-text password so that the output of the hashing algorithm will not be the same when two users have the same password. For example, without adding a salt, it means that if your password is "abc123" and my password is "abc123", our hash values will be the same. Since they are the same, it's possible to pre-compute many common (or uncommon) passwords and store them with their corresponding hash for quick and easy retrieval.

These significant issues are the reasons that pre-computed rainbow table attacks are so effective against LM hashes. The most effective pre-computed attack against LM hashes that I have seen was brought to my attention by Chad Tilbury. While teaching SANS Forensics 408, Chad pointed out to the class this project to put the LM hash rainbow tables on solid state drives. This is an incredibly fast and inexpensive solution for cracking very complex 14-character passwords in just 5-11 seconds! What does this mean? This means that if your (or your users') LM hash is available to an attacker, they will know the clear-text password almost instantly.

The Ugly

So if all that isn't ugly enough, let's move on to the really ugly stuff. But before we do, I need to point out that Microsoft has long recognized the weaknesses of the LM hash and provided us with some techniques for disabling its use. Let me review these techniques and then I'll show you a glaring omission in Microsoft's attempts to protect us from the LM hash.

By default, Windows Vista and higher no longer store LM hashes on disk (in the SAM database) by enabling the "NoLMHash" Registry setting. Furthermore, this MS article describes how to disable it for older operating system versions, as well as in Active Directory. In a nutshell, it describes how to push the NoLMHash setting via Group Policy, as shown here on my test domain controller:

Another mitigation option from Microsoft provides a way to prevent Windows from authenticating with the LMv1/LMv2 challenge-response network authentication protocol. In the next few weeks I will post an article to discuss network authentication in-depth, so I won't go into all the inner workings here. Suffice it to say that an LM hash is required to complete LMv1 or LMv2 challenge-response network authentication. So if we disable the LM challenge-response protocols as provided by Microsoft, and specify that only the newer NTLMv2 protocol be used (which only requires the NT hash, not the LM hash), then Windows shouldn't need the LM hash, right? That's my thinking.

So here I have changed the network authentication level to the most secure setting, which is to only allow NTLMv2 (as well as Kerberos)-effectively disabling the LM challenge-response protocols:

Now I want to test the effectiveness of these changes and see if it truly disables LM hashes as I would expect. I will do this on a Windows 7 SP1 system, hoping that the latest OS will provide the necessary protection against storing LM hashes.

On my Windows 7 test machine named USER-WIN7, which is joined to the MSAD2 test domain I used in my previous article, I updated Group Policy to reflect the changes made above to the domain's GPO. Here are the new settings reflected on the Windows 7 client:

For good measure, I have also changed local account MIKE's password and domain account MSAD2-RESPONDER2's password and then rebooted the machine:

Now here's where it gets really ugly. Having implemented the policy to disable the storage of LM hashes, we should not see LM hashes stored on disk. And by implementing the policy to disable the LM challenge-response protocols over the network, there should be no need for the LM hash to be stored in memory. After all, why would it, since it is not needed for local or remote use now? Well, time to see what happens in practice.

After making the changes above to presumably prevent the use and storage of LM hashes, I've logged on at the console of the Windows 7 host as domain user MSAD2-RESPONDER2. I have also issued the RunAs command to logon the local user MIKE. This will allow us to see both users' hashes loaded into memory. (Remember, an account must have a current "interactive" logon session in order for the hashes to be found in memory?see my article on password hashes for details).

Let's first look at the local hashes on disk.

  • So here I've run pwdump6, which will show the hashes on disk (in the SAM), for the local user accounts only:

As expected, no LM hashes are available. The first 2 accounts are disabled by default and no password was ever set for them. For user account MIKE, only his NT hash is available. So far, so good!

Now we need to look at what hashes are in memory.

This is not good at all! It turns out that Windows calculates and stores the LM hash in memory, assuming the password is less than 15 characters, regardless of what the host or domain settings are for LM hash storage and LM challenge-response!

Now with the LM hashes in hand, we can easily crack the passwords. Here I'm using the previously discussed SSD implementation of the LM rainbow tables from Objectif Sécurité:

  • Local account MIKE's cracked password:

  • Domain account MSAD2-RESPONDER2's cracked password:

This is scary stuff! This means that essentially any user who has their machine comprised and hashes dumped from memory will have effectively divulged their clear-text password, since freely-available LM rainbow tables can crack the most complex 14-character passwords in just seconds.

Let that sink in for a second... I discussed last time how devastating pass-the-hash attacks can be, which is absolutely the case. However, if attackers can just get the actual password, in most environments that opens up many more systems to attack from inside and often outside the network.

This issue of having LM hashes in memory was identified in Hernan Ochoa's paper describing his tool Windows Credentials Editor (see page 23 of his paper). For confirmation beyond Hernan's paper and my own testing, I contacted Microsoft about this issue and the unofficial response I received was that they are aware of the problem. The general message was that even if they were to fix this problem, there are still the significant issues of pass-the-hash as well as LSA-encrypted passwords (which I'll cover next week), so they don't see enough reward versus the risk of changing a significant piece of their code base.

The Good

I realize this is a stretch, but here's what I will label as the one "good" thing about the LM hash?the fact that a 15-character password or greater will completely break the algorithm, and thus Windows cannot calculate and store the LM hash in memory (or on disk). So here's our one defense for this issue?make your passwords 15 or more characters!

To demonstrate this, I will change local user MIKE's password and domain user MSAD2-RESPONDER2's password to a value greater than 14 characters:

Now after a logoff/logon, let's recheck those hashes in memory:

Whew! The one redeeming value of the LM hash algorithm?the fact that we can completely break it with a sufficiently long password. A nice side effect of this is that with a password of 15 or more characters, you'll also make your NT hash very resistant to pre-computed attacks. That said, we still have to protect the NT hash to avoid pass-the-hash attacks. As discussed in my last article, the way to do this is to avoid interactive logons with privileged accounts.


With the effectiveness of LM rainbow tables on today's hardware, we have to consider LM hashes effectively equivalent to clear-text passwords. Unfortunately, we do not have a Microsoft-provided mechanism for disabling the LM hash in memory. So for accounts you use for interactive logons, your only defense is to make sure you set your passwords to be 15 characters or more in order to break the LM hash algorithm.

This is a fairly easy solution for one-off accounts, but it gets much more difficult when trying to protect thousands of end-user accounts. While you will probably get significant push back (and maybe some laughter too), it is worth at least discussing the implementation of a 15-character password policy, or passphrase policy, for your organization. That, or put pressure on Microsoft to give us better option.

More to come next week, so stay tuned!

Mike Pilkington is a Sr.Security Analyst and Incident Responder for a global Fortune 500 company in Houston, TX, as well as a SANS Mentor and Community Instructor.


Posted February 29, 2012 at 8:42 PM | Permalink | Reply


Good article. 15 character passwords should probably be the standard for Windows enterprises for this very reason. By default, Windows doesn't store LM hashes (except in memory!) and its important for people to remember that when setting the "NoLMHash" option that it only applies to future passwords. All current passwords are still stored in LM (and possibly password histories) which effects organizations who either are upgrading from XP/2K3 or trying to lock down their settings in real-time.

Posted March 1, 2012 at 3:26 AM | Permalink | Reply


You might want to check as how you can play with LM hashes:

Posted March 1, 2012 at 11:45 PM | Permalink | Reply


Does this rely Administrative rights to extract the hashes from memory?
Does this still work if you a member of Power Users?

Posted March 5, 2012 at 5:27 AM | Permalink | Reply

Mike Pilkington

In a nutshell, yes, it requires administrative privileges to get the hashes out of memory. A Power User could not do it without having the special permission "SeDebugPrivilege" added to it's rights. That would not typically be done, for reasons discussed here:
The technique typically involves injecting code into lsass.exe to extract the hashes directly from it. Hernan Ochoa's current tool, WCE, appears to do it in a different manner, by "reading" memory and then parsing and decrypting the hashes. In either case, you effectively need administrative rights. You can read more about these two techniques from Mr. Ochoa's paper "WCE Internals":
Thanks, Mike

Posted March 9, 2012 at 2:59 PM | Permalink | Reply

photo editor free download

Wow. Nice article. I love your style. And its well structured. And informative, but not too much. I like it.

Posted March 9, 2012 at 8:38 PM | Permalink | Reply


Just to play devil's advocate for a moment ''" what is the benefit of making passwords 15 characters when the NT hash is still written to disk and in memory? The attacker needs admin privileges to pull the LM hash from memory, but if he's already got admin, he's got access to the unsalted NT hash. With the NT hash, the attacker doesn't need to know the user's password, the NT hash can be replayed via pass-the-hash. I realize it's all a part of DiD, but I'm wondering if there is a more specific benefit.

Posted March 10, 2012 at 6:43 AM | Permalink | Reply

Mike Pilkington

Hi Will,
I understand your point and I don't necessarily disagree with it. My point is simply, why make it easier for the attacker? What concerns me most about allowing the password to be obtained so easily (which is what we're doing by making LM hashes available) is that it often opens up many more systems for the attacker to infiltrate''"systems that don't support the native Microsoft network authentication protocols. This is particularly dangerous and often true of external services such as VPN and webmail. Ideally, we'd simply have a Microsoft-provided mechanism to fully disable LM hashes, including in memory, and so it would be one less vulnerability to worry about. So yes, I guess you could say one more "layer" of defense-in-depth.
Thanks, Mike

Posted March 28, 2012 at 11:19 PM | Permalink | Reply


Hi Mike, worth noting that the use of non-ascii characters also prevents the creation of LM hashes.

Posted March 30, 2012 at 5:37 PM | Permalink | Reply

Mike Pilkington

Hi BigW,
You bring up a great point. I should have been more clear in the post that using 15 characters isn't the only way to break LM hashes. I do think it's the best way though. In my article on encrypted passwords in memory (, a reader made a similar point and I gave the following response, which applies here as well:

Hi Anders,
You bring up a great point! You are very right, there are a lot of ALT characters which will also break the LM hash, and I should have mentioned that. Unfortunately though, there are also some issues with relying on ALT characters for this purpose.
The following Microsoft TechNet article discusses the use of ALT characters to break the LM hash:
After first making the point that >14 character passwords will break the LM hash, it goes on to say the following:
"Second, if the password contains certain ALT characters, the system will also not be able to generate an LMHash. This latter point is tricky, because while some ALT characters significantly strengthen the password by removing the LMHash, others significantly weaken it since they are converted into a normal upper-case letter prior to storage."
So it turns out that there are some ALT codes which could do the opposite of what we intend. That stinks!
Table 1 in the article does list the ALT codes which will break the LM hash, which is nice. However, that's pretty difficult to keep track of and would be really hard to train English-speaking users to follow in a password policy. Though for non-English speaking users, it would probably be much easier, and in fact may not even be necessary since I would think most non-English speakers probably use Unicode in their passwords to begin with?
As kind of a side note''In testing I've tried quite a few variations of passwords with ALT codes in Windows XP and haven't had a great deal of luck. For example, I was able to create a new password in XP with ALT-7 (bullet symbol), but thats not a Unicode character and thus it creates an LM hash (verified with WCE). On the other hand, I tried including ALT-0128 (euro symbol) in a new password, but I couldn't get XP to accept it as a password in the Change Password dialog box. On Windows 7, it worked just fine though. It also worked if I set the password on the domain controller and then logged into XP with the new password. So possibly it's user error, but from what I could tell, XP (at least my non-international version) does not have full support for changing passwords with ATL codes.
To sum up, you make a great point and I was definitely too absolute in saying that the "only" way to break LM hashes is with >14 character passwords. On the other hand, ALT characters do not provide a straightforward and fail-proof method for disabling the LM hash, so I still recommend >14 character passwords for consistently breaking the LM hash.

Hope that helps BigW, and thanks for rightly pointing out the non-ascii option to breaking LM hashes.

Posted February 12, 2013 at 10:59 AM | Permalink | Reply


What is the point to extract LM hashes from live memory? Have a look at the following software, it extracts PLAINTEXT passwords using all known methods including biometric credentials, WCE-like, Win8 Vault ones, etc.:

Posted February 12, 2013 at 7:44 PM | Permalink | Reply

Mike Pilkington

I agree. The next article in the series discusses exactly that via the mimikatz tool: However, I need to update that article. At the time I wrote it, it was not yet known that the Kerberos SSP also stored the password in memory. With that being the case, there's no way to realistically avoid the passwords in memory, other than avoiding interactive logons as I mentioned.

Posted February 28, 2013 at 2:33 PM | Permalink | Reply


Good article. Does having two factor authentication help defeat these kind of exploits?

Posted May 15, 2013 at 8:14 PM | Permalink | Reply


Forgive my ignorance, but if the hash has been obtained, then couldn't the attacker just use a pass-the-hash attack to gain access? Then it wouldn't matter if the hash was LM or NT, credentials have still been obtained.

Posted May 17, 2013 at 7:35 PM | Permalink | Reply

Mike Pilkington

Hi Curious,
That is true, pass-the-hash is extremely effective and once an attacker is in the environment and has the hashes, then they can mostly get where they want to with them. There are some tools though that need the actual password. For example, from the outside, a password is often all that is necessary to login to client VPN gateways or webmail. Since the LM hash is so simple to reverse to get the password, a stolen LM hash becomes an issue not only from the inside (via pass-the-hash), but also the outside since it can effectively be turned into the password.
All that said, it's really become a moot point with the discovery of passwords in memory by Benjamin Delpy, implemented in his tool mimikatz. We can now dump the password just as easily as the LM hashes. So at this point, I'd consider this information about LM hashes mostly an FYI regarding yet another way our credentials are exposed with an interactive logon.

Posted July 21, 2013 at 6:49 AM | Permalink | Reply


Great article, after having penetration testing done on our financial computer system it was noted to disable the LM hash. Instead of going through the registry edit, I can inform the CEO to change our password policy to be no less than 15 characters.