If NTLM (NT LAN Manager) is part of your authentication strategy, your organisation is facing critical security risks. And you are not alone. NTLM is still widely used, despite Microsoft deprecating it in 2024. NTLM vs Kerberos’ is not just a technical decision anymore—transitioning to Kerberos is critical for protecting against today’s threats. Just last month, a major vulnerability was discovered allowing threat actors to steal NTLM credentials by having a user view a malicious file in Windows Explorer. This exploit, requiring almost no user interaction, is a stark reminder that NTLM isn’t just outdated – it’s actively putting your systems at risk.
But don’t worry. Updating your authentication system doesn’t have to be overwhelming or disruptive. This article will explain why it’s time to move on from NTLM. We will explore the key benefits of Kerberos, a modern alternative. Finally, we will provide a clear, phased plan to switch smoothly and securely.
What is NTLM Authentication?
NTLM (NT LAN Manager) is an authentication protocol developed by Microsoft in the early 1990s. NTLM, introduced with Windows NT 3.1 in 1993, provides a reliable way for Windows systems to authenticate users in local networks. NTLM was important before the widespread adoption of Active Directory and Kerberos.
But as you can imagine, with a protocol developed over 30 years ago, NTLM’s design reflects the security practices of that time, which are no longer sufficient to defend against modern cyber threats and hasn’t been able to for quite some time. Its reliance on outdated cryptographic practices and its susceptibility to attacks like pass-the-hash have made it a weak link in modern security architectures.
NTLM Deprecated in 2024
Microsoft officially deprecated NTLM in June 2024 as part of a broader push to encourage organisations to adopt more secure and modern authentication protocols. This included the deprecation of LANMAN, NTLMv1 and NTLMv2. Despite this, NTLM remains in use in many environments, often due to the use of legacy systems, lack of resourcing, perceived difficulty in migrating, or because organisations are just unaware of the risks posed by the continued use of NTLM. A recent report from Silverfort found 64% of user accounts and 37% of administrator accounts are still regularly authenticating to NTLM!
Risks Associated with NTLM Authentication
Over the past few decades, NTLM’s inherent vulnerabilities have been exploited through various attack methods, which, dependent on configuration and whether hardening techniques have been deployed, are still viable attacks today.
Pass-the-Hash Attacks
Pass-the-Hash (PtH) attacks were first publicly described in 1997 by Paul Ashton, a security researcher. Ashton demonstrated how compromised hashed NTLM credentials could be reused to authenticate on a network without needing the plaintext password. This was groundbreaking at the time, as it eliminated the need to crack NTLM hashes to recover the original password – a process that can be computationally intensive and is not always viable, especially for long and complex passwords. In the 1990s, the computational resources required for cracking hashes were considerably more limited compared to today’s standards, making the PtH technique particularly appealing as it allowed immediate exploitation of credentials without the need for decryption.
NTLM Relay Attacks
An NTLM relay attack is a method where a threat actor intercepts and relays NTLM authentication attempts from one system to another, effectively impersonating a legitimate user to gain unauthorised access to network resources. This type of attack exploits the lack of mutual authentication in NTLM, allowing threat actors to act as a “man-in-the-middle” between the client and server. Like PtH attacks, relay attacks bypass the need to crack the intercepted credentials, simplifying and accelerating system compromise.
New Attack Vectors
Despite Microsoft’s efforts to mitigate these risks through measures like SMB signing, NTLM continues to be susceptible to new attack methods.
As mentioned at the start of this article, a new zero-day vulnerability was discovered in December 2024. This attack allows threat actors to capture NTLM credentials simply by having the user view a malicious file in Windows Explorer. The user doesn’t even need to open the file. This “clickless” exploit needs little user interaction, greatly increasing the chances of successful credential theft. Even NTLMv2 implementations remain vulnerable to this type of attack.
The persistence of such vulnerabilities highlights the critical need for organisations to transition away from NTLM to more secure authentication protocols. This ongoing risk is one of the key reasons Microsoft officially deprecated NTLM in 2024.
The Alternative to NTLM
While NTLM has served its purpose for decades, modern authentication protocols like Kerberos offer far more secure and robust alternatives. Other options, such as SAML (Security Assertion Markup Language) or OpenID Connect, are also viable depending on organisational needs, particularly for cloud-based or federated environments.
However, Kerberos stands out as the most practical choice for organisations using Active Directory, as it is already built into Windows and offers a seamless transition path. Kerberos addresses NTLM’s critical security weaknesses by incorporating mutual authentication, ensuring that both the client and server verify each other’s identities before establishing a connection. This prevents man-in-the-middle attacks and eliminates the possibility of server impersonation.
This article focuses on Kerberos because migrating to it is straightforward, with minimal risk of disruptions. By carefully planning and staging the migration, organisations can enhance their authentication security without impacting day-to-day operations.
What is Kerberos?
Originally developed at MIT in the 1980s, Kerberos is a modern authentication protocol that operates on a ticket-based system, where a trusted authority—known as the Key Distribution Center (KDC)—issues encrypted tickets to users and systems. These tickets are used to prove identity and grant access to resources, eliminating the need to transmit passwords across the network.
Key features and benefits of Kerberos include:
- Mutual Authentication: Ensuring both the client and server verify each other’s identity, preventing impersonation and man-in-the-middle attacks.
- Strong Encryption: Protecting authentication data and ensuring its integrity during transmission.
- Scalability: Supporting large, complex networks with minimal performance impact.
NTLM vs Kerberos
Kerberos’s key features above address the risks of using NTLM. But here is a full comparison of NTLM vs. Kerberos.
Feature | NTLM | Kerberos |
Authentication Mechanism | Challenge-response. | Ticket-based system managed by a trusted Key Distribution Center (KDC). |
Mutual Authentication | Not supported. | Fully supported, ensuring both the client and server verify each other’s identity. |
Encryption | Uses outdated cryptographic practices, vulnerable to modern attacks. | Utilises strong, modern encryption methods to protect authentication data. |
Susceptibility to Attacks | Highly vulnerable to pass-the-hash, relay attacks, and replay attacks. | Resistant to pass-the-hash and relay attacks due to ticketing and session management. |
Network Traffic | Requires frequent authentication exchanges, increasing traffic and overhead. | Reduces overhead by using reusable tickets during their validity period. |
Scalability | Limited in large, distributed environments. | Designed to handle large, complex networks efficiently. |
Default in Windows | Enabled by default in older Windows environments but deprecated in 2024. | Default authentication protocol for modern Active Directory environments. |
Migration from NTLM Authentication to Kerberos Authentication
While transitioning from NTLM to Kerberos is a critical step in strengthening organisational security, it is essential to approach this migration in a phased approach to reduce the impact Microsoft Windows NTLM removal could have on critical business processes. The steps below allow the identification of NTLM dependencies during the process, thereby helping to mitigate the risk of disrupting critical services.
Enable NTLM Audit Logging
Before disabling NTLM, it is crucial to identify which systems and applications currently rely on NTLM. It’s rare that organisations map this type of information within asset inventories or CMDBs, and if you do, there is always the risk that something has been missed or data is out of date. Implementing audit logging, specifically around NTLM, will help detect NTLM usage across your network.
Steps to Enable NTLM Audit Logging via Group Policy
Open Group Policy Management Console (GPMC):
- Open the Default Domain Controller Policy
- Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
Configure the Following Policies:
- Network Security: Restrict NTLM: Audit NTLM authentication in this domain:
- Set to Enable all.
- Network Security: Restrict NTLM: Audit Incoming NTLM Traffic:
- Set to Enable auditing for domain accounts.
- Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers:
- Set to Audit all.
Analyse Audit Logs
Review the collected logs to identify systems and applications using NTLM. This analysis will help determine which services need configuration changes to support Kerberos.
After policy application, events related to the use of NTLM authentication will appear in the Event Viewer under:
- Applications and Services Logs > Microsoft > Windows > NTLM
Look for events indicating NTLM authentication attempts, such as Event ID 4624 with the Authentication Package value set to NTLM.
Events can be analysed on each server or can be collected from the central Windows Event Log Collector.
Transition to Kerberos Authentication
Once NTLM dependencies are identified, proceed to configure systems and applications to use Kerberos.
Open Group Policy Management Console (GPMC):
- Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options.
Configure the Following Policies:
- Network Security: Restrict NTLM: Incoming NTLM Traffic:
- Set to Deny all accounts.
- Network Security: Restrict NTLM: NTLM authentication in this domain:
- Set to Deny for domain accounts.
- Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers:
- Set to Deny all.
Continuous Monitoring and Maintenance
After enforcing these policies, closely monitor systems for any authentication issues.
Ensure that all services are functioning correctly with Kerberos authentication.
Regularly review authentication logs to ensure NTLM is not being used and that Kerberos authentication is functioning as intended. Address any anomalies promptly to maintain a secure authentication environment.
Additional Configuration Options
If you want a more phased approach, consider starting with just blocking NTLMv1. Then, move up to stricter controls. If you have systems or apps that can’t be migrated and need to be excluded, check this excellent article on Windows OS Hub. It has details and screenshots for more granular config options.
Start Strengthening Your Security
Removing Microsoft Windows NTLM and migrating to Kerberos is not just about adopting a modern authentication protocol – it’s about safeguarding your organisation against evolving cyber threats. Take a phased approach, starting with auditing NTLM usage. Then, transition to Kerberos. This will boost security without disrupting operations.
In light of the recent zero-day exploit for NTLM, this is a perfect time to take proactive steps to modernise your authentication systems. If you need help with your migration strategy, please reach out.
0 Comments