Understanding NTLMv1, NTLMv2 and NTLMv2 Session Security Settings

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 than its previous version, and to some extent it does provides better defense against relay and brute force attacks, but does not completely 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 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:

1. The client machine sends a request to connect to the server.>
2. The server generates a random nonce to be encrypted by the client.
3. The client machine encrypts the nonce with the password hash to prove knowledge of the password.
4. 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:

Default value for NTLMv2

On Windows Server 2008 (non-R2): No requirements.

On Windows Server 2008 R2 and newer: Require 128-bit encryption. (NTLM connections will fail if strong encryption (128-bit) is not negotiated.)

MITRE ATT&CK reference to NTLM vulnerabilities

The MITRE ATT&CK framework add more relevant information to this 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 inject 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

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.