Understanding NTLMv1, NTLMv2 and NTLMv2 Session Security Settings
NTLM has three versions – NTLMv1, NTLMv2, and NTLMv2 Session Security. NTLMv2 is supposed to offer better security and defenses against relay and brute force attacks, but it does not entirely block them. NTLMv2 Session Security is a session security protocol that can be used in conjunction with NTLMv1 or NTLMv2 to provide additional security.
NTLM is just one of several legacy protocols still running in most networks. Find out which others are putting you at risk.
What You Will Learn
- How do NTLMv1 and NTLMv2 differ
- What are the risks of continuing to use NTLMv1
- Understanding NTLMv2 Session Security
- NTLM configuration best practices moving beyond NTLM
NTLM Authentication
NTLM authentication is a legacy protocol used to authenticate users and computers in Windows-based networks. Despite the availability of newer and more secure protocols, NTLM is still widely used and required for deploying Active Directory, a crucial component of Windows-based networks. This is because NTLM is deeply ingrained in the Windows architecture, making it difficult to disable or restrict NTLM without causing damage to production systems.
Moving away from NTLM authentication and complying with the CIS benchmarks is challenging, as it requires identifying which computers are using it and migrating to a more secure protocol without breaking anything. Many organizations continue to use NTLM as a fallback mechanism, despite the availability of more secure protocols like Kerberos and OAuth. However, using newer protocols is recommended as they offer stronger security and better protection against certain types of attacks.
NTLM Authentication Server – Client Authentication Process
In a Windows-based network, the domain controller plays a critical role in managing the challenge/response exchange in the NTLMv1 authentication protocol. This involves generating a challenge to the client and validating the user’s credentials by comparing the hashed password provided by the client with the stored hash value for the user’s account. If the two values match, the user is considered authenticated and granted access to the requested resource.
The NTLM authentication flow is as follows:
- The client machine sends a request to connect to the server.>
- The server generates a random nonce to be encrypted by the client.
- The client machine encrypts the nonce with the password hash to prove knowledge of the password.
- The server validates the user’s identity by ensuring that the challenge was indeed created with the correct user/password. It does this either by using data from its own SAM database or by forwarding challenge-response pairs for validation in the domain controller.
How NTLMv2 is Different From NTLMv1
NTLMv2 follows a similar flow to NTLMv1 with a key difference: in step 3, the client includes a timestamp and username along with the nonce, which helps mitigate offline relay attacks. However, NTLMv2 still shares some vulnerabilities with NTLMv1 and doesn’t offer a complete solution. Additionally, NTLMv2 uses a variable-length challenge instead of NTLMv1’s 16-byte random number challenge.
Benefits of requiring NTLMv2 Session Security
When configuring client devices to require NTLMv2 session security, administrators can ensure strong network security with advanced security features such as message integrity and the negotiation of 128-bit encryption.
NTLMv1 vs. NTLMv2 and NTLMv2 Session: Key Differences and Security Implications
NTLMv2 follows a similar flow to NTLMv1 with a key difference: in step 3, the client includes a timestamp and username along with the nonce, which helps mitigate offline relay attacks. However, NTLMv2 still shares some vulnerabilities with NTLMv1 and doesn’t offer a complete solution.
NTLMv2 Session enhances security by incorporating stronger encryption algorithms and advanced features, including HMAC-MD5 for message integrity and 128-bit encryption to safeguard session data. Additionally, NTLMv2 uses a variable-length challenge instead of NTLMv1’s 16-byte random number challenge.
Configure NTLMv2 Session Security
To configure Minimum session security for NTLM SSP-based (including secure RPC) servers, is set to ‘Require NTLMv2 session security, Require 128-bit encryption via Group Policy, set the LAN Manager Authentication Level to require 128-bit encryption or NTLMv2:
| Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity OptionsNetwork security: Minimum session security for NTLM SSP based (including secure RPC) clients |
Default value for NTLMv2
On Windows Server 2008 (non-R2): No requirements.
On Windows Server 2008 R2 and newer, 128-bit encryption is required. (NTLM connections will fail if strong encryption (128-bit) is not negotiated.)
MITRE ATT&CK reference to NTLM vulnerabilities
The MITRE ATT&CK framework adds more relevant information to these known vulnerabilities by connecting these vulnerable flows and procedures to real-life attack campaigns. As stated by MITRE ATT&CK, a PTH- Pass the hash attack can be formed by capturing and manipulating NTLMv1/v2 login processes:
From a classic Pass-The-Hash perspective, this technique uses a hash through the NTLMv1 / NTLMv2 protocol to authenticate against a compromised endpoint. This technique does not touch Kerberos. Therefore, NTLM LogonType 3 authentications that are not associated to a domain login and are not anonymous logins are suspicious.
From an Over-Pass-The-Hash perspective, an adversary wants to exchange the hash for a Kerberos authentication ticket (TGT). One way to do this is by creating a sacrificial logon session with dummy credentials (LogonType 9) and then injecting the hash into that session, which triggers the Kerberos authentication process.
If it is not possible to disable NTLM in an infrastructure, it is critical to monitor NTLM activity and configure it for optimal security and audit.
If NTLM is still in your environment, SMB and NetBIOS likely are too. Get the full picture of your legacy protocol exposure.
NTLMv2 best practices
Using NTLMv2 is essential for ensuring robust network security and providing significant network protection. By correctly configuring NTLMv2, an organization can better safeguard sensitive data, maintain secure communications, and protect against cyber threats.
By adopting server hardening strategies, such as disabling unnecessary services, enforcing strong encryption, and using only secure, updated authentication protocols, organizations can significantly reduce their attack surface. This comprehensive approach not only improves overall network security but also aligns with best practices for network security.
Many of the NTLM hardening steps above — enforcing NTLMv2, restricting legacy authentication, and monitoring credential activity — are directly required by NIST security controls. See what NIST compliance requires for secure system configuration.
Key Takeaways
- NTLMv1 is insecure in Windows authentication and must be disabled.
- NTLMv2 is more secure, but still a legacy protocol.
- For encryption and message integrity, enable NTLMv2 Session Security
- Monitor NTLM authentication to detect credential attack attempts
- Plan migrating to modern authentication methods, like Kerberos
Ensure Secure Authentication with CalCom CHS
Don’t let outdated protocols put your systems at risk. With CalCom Hardening Solution (CHS), you can automatically detect and block insecure NTLMv1 usage, enforce NTLMv2 policies, and streamline compliance with Microsoft security standards.
CHS is a baseline hardening solution designed to address the needs of IT operations and security teams. CHS significantly reduces operational costs and eliminates service downtime by indicating the impact of a security baseline change directly on the production environment. CHS’s automated process simulates the effect of a change in a production environment, thus saving the need for testing changes in a lab environment.
