NTLM attacks are especially relevant to Active Directory environments. One of the most common attack scenarios is NTLM Relay, in which the attacker compromises one machine and then spreads laterally to other machines by using NTLM authentication directed at the compromised server. The best way to cope with NTLM vulnerabilities is basically not to use NTLM, as there are better and safer authentication methods out there. But that’s easier said than done because most large and established infrastructures contain machines that can only use NTLM. In this case, it is important to make sure they are configured in the most secure fashion possible.
LAN Manager (LM) is a family of early Microsoft client/server software products that allows users to link personal computers together on a single network. Network capabilities include transparent file and printer sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory will use LM, NTLM, or NTLMv2.
LAN Manager authentication includes the LM, NTLM, and NTLM version 2 (NTLMv2) variants, and is the protocol that is used to authenticate all Windows clients when they perform the following operations:
- Join a domain
- Authenticate between Active Directory forests
- Authenticate to down-level domains
- Authenticate to computers that do not run Windows 2000, Windows Server 2003, or Windows XP
- Authenticate to computers that are not in the domain
The possible values for the Network security: LAN Manager authentication-level setting are:
- Send LM & NTLM responses –Clients use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send LM & NTLM – use NTLMv2 session security if negotiated – Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send NTLM responses only –Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send NTLMv2 responses only –Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
- Send NTLMv2 responses only\refuse LM –Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).
- Send NTLMv2 responses only\refuse LM & NTLM –Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).
- Not Defined
Default configurations per operating system:
*Windows Vista – Not Defined
*Windows 95-based and Windows 98-based clients only send LM.
*Windows 2000, Windows Server 2003, and Windows XP- send LM and NTLM authentication responses.
*Windows 95, Windows 98, and Windows NT operating systems cannot use the Kerberos version 5 protocol for authentication. For this reason, in a Windows Server 2003 domain, computers authenticate by default using both the LM and NTLM protocols.
The default setting on these servers allows all clients to authenticate with servers and use their resources. However, this means that LM responses — the weakest form of authentication response — are sent over the network, making it possible for attackers to sniff that traffic and easily reproduce the user’s password.
You can enforce a more secure authentication protocol for Windows 95, Windows 98, and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a secure channel to protect the authentication process. Even if you use NTLMv2 for earlier clients and servers, Windows-based clients and servers that are members of the domain will use the Kerberos authentication protocol to authenticate with Windows Server 2003 domain controllers.
Configure the Network security: LAN Manager Authentication Level setting to Send NTLMv2 responses only. We recommend this level of authentication when all clients support NTLMv2.
For more information about how to enable NTLMv2 on older versions of Windows, see article 239869. Microsoft Windows NT 4.0 requires Service Pack 4 (SP4) to support NTLMv2, and Windows 95 and Windows 98 platforms need the directory service client installed in order to support NTLMv2.
Clients that do not support NTLMv2 authentication will not be able to authenticate in the domain and access domain resources by using LM and NTLM. You can follow this guide to help determine where NTLM may be used within your environment.
CALCOM’S RECOMMENDED VALUE:
Send NTLMv2 response only. Refuse LM.
Note: If the server is set to send NTLMv2 responses only and refuse LM & NTLM, clients that use LM and NTLM will not be able to access IIS applications unless the client\workstation is also set with the same configuration. Other applications might not work properly as well.
HOW TO CONFIGURE:
To configure NTLM compatibility for Windows Vista and Windows 7:
- Click Start > All Programs > Accessories > Run and type secpol.msc in the Open box, and then click OK.
- Click Local Policies > Security Options > Network Security: LAN Manager authentication level.
- Click Send LM & NTLM – use NTLMv2 session security if negotiated.
- Click Apply.
Configuring GPO to Force NTLMv2
Go to the GPO section Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options and find the policy Network Security: LAN Manager authentication level.
You can also disable NTLMv1 through the registry. To do it, create a DWORD parameter with the name LmCompatibilityLevel and the value 0-5 in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa. Value 5 corresponds to the policy option “Send NTLMv2 response only. Refuse LM NTLM”.
AUTOMATE YOUR SERVER HARDENING:
Server hardening can be a painful procedure. If you’re reading this article, you probably already know it. Endless hours, labor, and money are invested in this process, which can often result in production breakdown despite the effort to prevent it. CHS by CalCom automates the entire server hardening process. CHS’s unique ability to ‘learn’ your network eliminates the need to perform lab testing while ensuring zero outages to your production environment. CHS will allow you to implement your policy directly on your production servers, hassle-free. Want to know more?