NTLM v1 vs v2 vs Kerberos: Key Risks & Best Practices

NTLM v1, NTLM v2, and Kerberos Active Directory are core authentication protocols in Windows environments, but not all are created equal. With increasing risks like credential theft and relay attacks, choosing the proper protocol is critical. In this guide, we break down how these protocols work, where they’re vulnerable, and why moving away from NTLM can significantly improve your security posture.

What You Will Learn

• How NTLMv1 works
• What NTLMv2 improves
• How Kerberos authentication works
• The security advantages of Kerberos over NTLM
• Best practices for migrating from NTLM to Kerberos

Is NTLM Secure?

NTLMv1 is a Microsoft authentication protocol used primarily for network authentication on Windows-based systems. It is a challenge-response authentication protocol, where the server sends a challenge to the client, which is then encrypted using the client’s password hash and sent back to the server for authentication.

NTLMv1 Authentication

NTLM is a Microsoft authentication protocol supported in Windows since Windows 95. NTLM sets and manages the default authentication protocol, authentication levels, authentication message, authentication method, rainbow table, server challenge, clients, and servers, as well as brute force attacks.

NTLM authentication uses a challenge and response flow, where:

1. Client computer
   • User enters their domain name, User ID, and password.
   • Creates a cryptographic hash (either NT or KM hash) of the password.
   • Sends the targeted server the user name in plain text.
2. Server
   • Generates a challenge, which is a 16-byte random number
   • Sends it to the client computer.
3. Client computer returns the challenge with the hash of the user’s password
4. Server forwards the Domain Controller (DC) the user name, the challenge, and the response.
5. DC
   • Request the user’s password hash from the Security Account Manager.
   • Encrypts the challenge.
   • Compares the encrypted challenge to the client’s encrypted response.
   • Approve authentication if the challenges match.

Avoid using NTLMv1 whenever possible due to the vulnerabilities.

• Fixed hash length
• Challenge-response mechanism exposes passwords

NTLMv2: Incremental Improvements & Remaining Risks

NTLM v2 improves on NTLM v1’s authentication flow with these changes:

1. In Stage 2, the client attaches a timestamp to the user name
2. Instead of a 16-byte challenge, the server generates a variable-length challenge.

While changes mitigate relay attacks, NTLMv2 continues to use the exact authentication mechanism and exposes the same vulnerabilities.

NTLM Security Risks: Hash Theft, Replay Attacks & More

NTLM  suffers from various vulnerabilities, particularly in its earlier versions like NTLMv1. These vulnerabilities include susceptibility to pass-the-hash and pass-the-ticket attacks, replay attacks, weak hashing algorithms, man-in-the-middle attacks, downgrade attacks, and credential theft. These weaknesses can lead to unauthorized access, credential theft, and compromise of network security.

To mitigate these risks, it’s essential to use more secure authentication mechanisms like Kerberos or newer versions of NTLM (such as NTLMv2) where possible, along with implementing additional security measures such as network segmentation, encryption, and strong password policies.

Kerberos Enterprise-Grade Authentication Explained

Since Windows 2000, Windows has supported Kerberos, an open-source software authentication protocol that supports two-factor and mutual authentication. It verifies client requests with tickets, tokens, and three types of keys. This enables authentication delegation, allowing a server to access remote resources on behalf of a client using multi-tier applications.

Authentication Flow

1. Client Computer:
   • User enters their username and password.
   • Generates an encrypted authentication request.
   • Sends a request to the Key Distribution Center (KDC)’s Authentication Server (AS).
2. Authentication Server:
   • Verifies request credentials
   • Issues a Ticket Granting Ticket (TGT) as proof of the user’s identity.
   • Encrypts TGT with the KDC’s secret key.
3. Client Computer:
   • User requests access to a network resource.
   • Presents TGT to the KDC’s Ticket Granting Service (TGS)
   • Requests a service ticket for the resource.
4. TGS
   • Validates TGT.
   • Issues a service ticket that confirms client authentication
   • Encrypts ticket with the service’s secret key
5. Client Computer
   • Receives ticket
   • Presents it to the requested service
6. Service
   • Validates ticket
   • Grants access

CVE-2022-37967 Vulnerability

CVE-2022-37967 security bypass and elevation of privilege vulnerabilities with Privilege Attribute Certificate (PAC) signatures. The security update addresses Kerberos vulnerabilities where an attacker could digitally alter PAC signatures, raising their privileges. NIST’s National Vulnerability Database (NVD) base score, which reflects the severity of the CVE-2022-37967 vulnerability, is 7.2 and considered High. Hardening Windows Kerberos for domain controllers is recommended, and implementing all relevant patches and related service packs.

Our ebook about legacy protocals explains how using NTLM putting your network at risk and how to secure your environment.

NTLM vs Kerberos

NTLMv1 is the oldest among the three authentication protocols, while NTLMv2 offers incremental security enhancements. However, Kerberos authentication is notably more advanced and provides greater security compared to both NTLMv1 and NTLMv2.

Why NTLM Persists and How to Phase It Out Safely

The obvious question is why NTLMv1 and NTLMv2 are still in use if there’s a safer alternative? The answer is that neglecting NTLM is more complex than it sounds. This process holds challenges such as:

• Using applications that do not support Kerberos
• Mapping where NTLM is being used
• Checking the impact of disabling NTLM

Here are a few examples of when you’ll use NTLM:

1. Kerberos
   • Does not work when you use a load balancer for web traffic (requires special configuration).
   • The process won’t work if the SPN presented by the client does not exist in the AD. For example, when trying to access a resource using an IP instead of a name.
2. When you need to work with:
   • External (non-domain) and internal clients.
   • Domain accounts and local user accounts on the IIS box.
3. When you have no SPN registered.
4. When the client
   • Doesn’t have DNS or DC connectivity.
   • Proxy settings or the Local Internet Zone are not used for the targeted site.

Key Takeaways

• NTLMv1 is outdated and insecure
• NTLMv2 improves security slightly
• Kerberos provides enterprise-grade security
• Kerberos enables advanced features
• Both NTLM and Kerberos have their own niches and issues
  

How CalCom Can Help You

Detecting these scenarios can be a pain. For this reason, we highly recommend using CIS compliance automation for this process. Tools such as CalCom Hardening Suite (CHS) automate server hardening. CHS will report where NTLM is being used and where you can disable NTLM and use only Kerberos without causing any damage. It will also enforce your policy in the production environment to make sure everything is configured correctly. Finally, it will monitor and fix any configuration drifts to make sure you remain compliant and secure.