Pass-The-Hash: Protect Your Windows Computers! (Part 3)

If you would like to read the other parts in this article series please go to:


Now that we are in the third installment of this article topic and series, I am sure you have been getting a bit anxious to learn all you can about Pass the Hash (PTH) and the methods to reduce the effects of this attack. In the first article we discussed the overview of PTH, describing methods to help protect your Windows computers from this attack. In the second article we discussed some of the GPO options that can be set to reduce the overall effects of PTH. As mentioned many times, there is no silver bullet to eliminate the risk of PTH, however, taking precautions to reduce the risk can go a long way. Since PTH first must gain local admin privileges to the computer, that is where we started with article 2 and setting GPO policies to reduce this ability for the attack. Now, we are moving on in this article to discuss how to remove LANManager, which is a very old authentication protocol which is easily hacked and attacked.

Is LANManager Really Still a Factor?

I often get this response to my comments about removing LANManager (LM) from a Windows Active Directory domain. Now that we are in the year 2014 and we have the latest operating systems such as Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, is this really still a factor? The short answer is yes!

If we take a step back in time and look at when LM was first introduced, we have to go quite a way back. LM was first introduced in 1990 (Well, for what we know as LanManager anyway). That is right, LM was introduced nearly 25 years ago. This was the era of Windows for Workgroups, which is Windows version 3.11. Now that we have both a desktop/workstation and server OS, why does Microsoft still support an authentication protocol that was designed for an operating system from so long ago?

The reason is due to legacy applications. Not legacy operating systems, but legacy applications. I am pretty sure that very few companies are running an operating system that still requires the use of LanManager. However, there are numerous applications that are built to support only LanManager. Your question might be how does an application need an authentication protocol? That is a great question.

The answer is that the application will have a service account which must authenticate back to Active Directory in order to perform the application functions. This is done by backup apps, databases, client/server apps, and many more types of apps. Since the service account (which is nothing more than a standard user with elevated privileges and rights) must authentication using LanManager, the domain controllers for the domain must support LanManager.

Eliminate the use of LANManager

Now wait! I just said that there is a chance that you have an application or many applications that need LanManager? Well, you will first need to discover this. The best way to do this is to just setup logging/auditing of logons on your domain controllers. Then, look through the logs for the LM events. If you don’t have any over a 30 to 60 day period, chances are very good that you don’t have any applications that use LM.

If this is the case, you can eliminate the use of LM by your domain controllers. This is a Group Policy setting which updates the Registry. In order to find this setting in a Group Policy Object, you should follow this path in a GPO when editing it:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

Towards the bottom of the list that is shown on the right hand side at this GPO path, you will find a setting which is labeled: Network security: LAN Manager authentication level. When you select the “Define this policy setting” check box, you will be able to click the drop down list, which is shown in Figure 1.

Figure 1: Options for the Network security: LAN Manager authentication level GPO setting.

The default for your domain controllers is the fourth option labeled “Send NTLMv2 response only”. Although this setting only mentions that it will use NTLMv2, it is not the case. When this setting is in place the domain controller will still authenticate LM authentication requests. In order to protect your domain and environment in the most secure manner, you should set this setting for your domain controllers to “Send NTLMv2 response only: Refuse LM and NTLM”.

Don’t Store LANManager Hash

Not only do you need to ensure that your domain controllers are not authenticating LM requests, but that they are not supporting LM in any way. It might seem like the above setting would eliminate any use of LM, but it is not the case. There is another way that your domain controller could interact with LM, which is almost worse than the issue above.

When a domain user sets the password for their user account the password must be registered in the Active Directory database in some fashion. When this occurs there could also be an entry for the LM authentication protocol for faster performance. This is called the LM hash and it is stored in the Active Directory database along with the user account. Well, unless you ensure that it is not stored!

To find this setting you will go to the same path as the setting above:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

Then you will look for the setting labeled: Network security: Do not store LAN Manager hash value on next password change. By default this setting is set to Enabled for your domain controllers starting with Windows Server 2003. However, I have seen instances where the setting is still set to Disabled due to upgrade paths from Windows 2000 Active Directory domains and domain controllers.

When you set this setting to Enabled the LM password hash will not be generated and stored along with the user account in Active Directory. This is ideal and does not need to occur, even if you are using LM, as the LM hash will be generated on the fly for LM authentications by the domain controller.


LanManager is still around and can be an inlet for a PTH attack. Actually, having the LM hash is exactly what PTH attacks are looking for. By eliminating any use or tracking of LM you can negate PTH from being successful by obtaining anything regarding LM. Unfortunately Microsoft configures your domain and domain controllers to support LM out of the box during installation. You need to take the necessary steps to ensure that LM is not being used as an authentication protocol by your domain controllers, as well as ensuring that LM hashes are not being stored with the user accounts in Active Directory. If you take these additional precautions, along with the settings mentioned in Part I and Part II of this series, you will be going a long way to protect your Windows computers and the entire network from the PTH attack. I would not allow your network and Active Directory domain to be left vulnerable from the PTH attack, as it is very powerful, obtrusive, and hard to negate. Not taking action is just asking for trouble!

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top