Although a key part of cyber resilience is adapting to changes in technology, addressing attack surfaces that have remained constant is equally critical. This is because most enterprises have maintained a significant amount of legacy infrastructure in addition to newer cloud workloads and SaaS applications. Sometimes this is due to the operational cost of migration as well as concerns about potentially breaking critical processes by doing so. In other cases, this is simply because the IT team is not even aware of the legacy components’ existence. But whatever the reason, legacy infrastructure is a ripe target for threat actors, as it’s always less secure than its modern alternatives. 

In this post we explore a prominent example of legacy infrastructure: the NTLMv1 authentication protocol. This early version of NTLM included critical security weaknesses, enabling attackers to execute a variety of identity-based attacks. And even though it’s now more than 30 years old, it can still be found in production environments — exposing them to risks of compromise that are extremely hard to detect.

We’ll then show how Silverfort enables enterprises to overcome the risks from NTLMv1 with discovery, monitoring, and control on every authentication and access attempt that still utilizes this archaic protocol. 

NTLM Authentication: A Brief History

According to Wikipedia, “In a Windows network, New Technology LAN Manager (NTLM) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocols NTLMv1, NTLMv2 and NTLM2 in a single package.” (NTLM2 combines both NTLMv1 and NTLMv2.) 

NTLMv1 was released back in 1993 and is a challenge-response authentication protocol, which means the authentication process is carried out in three steps: 

1. The client machine establishes a network connection to the target server.
2. The server sends a challenge to the client machine.
3. The client machine responds to the challenge and the server either allows or denies access based on the response.

In 1998, NTLMv2 was released on Windows NT 4.0 SP 4 and has been the current version of the protocol ever since.

General NTLM Security Issues

All versions of NTLM authentication face the following security issues:

1. Lack of salting makes the hash password-equivalent, meaning that if you are able to grab the hash value from the server you can then authenticate without knowing the actual password. This means that an attacker who can retrieve a hash – and there are various ways to dump it from the machine’s memory – can then easily access a target server and impersonate the actual user.
2. While the server does indeed validate the identity of the client, there is no corresponding validation of the server’s identity, which opens up the possibility of a Man-In-The-Middle (MITM) attack.
3. NTLMv1 lacks a client challenge – in case of an attack on NTLMv1, the attacker can force the client to calculate NTLMv1 Response with a known server challenge. Then, the attacker can efficiently guess the user’s password by checking the NTLMv1 response against a rainbow table.
4. Lack of MFA support deprives the protocol of any protection in the case of a compromised password or hash. 

These concerns led Microsoft to replace NTLM with the more secure Kerberos authentication protocol as the default in AD environments, although keeping NTLM as a backup. But even within NTLM, NTLMv1 is significantly less secure than its successor, NTLMv2.

What Makes NTLMv1 a Security Risk

The security level of the protocol depends on the challenge – the harder to compromise, the more secure the authentication. 

In the case of NTLMv1, the difference lies in their specific challenges:

1. NTLMv1 produces a challenge with a 16-bit fixed-length number while NTLMv2 produces challenges of variable lengths.
2. NTLMv1 uses a weak DES encryption algorithm that is fast to decrypt, making it vulnerable to brute-forcing, while NTLMv2 uses the slower HMAC-MD5 that can better resist these attacks, since decrypting can’t take place in real time. 

Any system that uses NTLMv1 authentication is, therefore, exposed to compromise since attackers can easily craft a way to accept the challenge and thus gain access to the system. 

With this in mind, it’s easy to understand why IT and security teams want to move away from NTLMv1. In theory, it seems easy – simply find all systems that use NTLMv1 and switch to a more secure protocol. In practice, however, it is much more challenging.

Obstacles in Detecting and Removing NTLMv1

In an ideal world, there would be some filter that when clicked would reveal all the NTLMv1 authentications taking place within an environment. Unfortunately, the reality is not that simple.

The most straightforward path is to enable Logon Success Auditing on the domain controller. According to Microsoft’s documentation, each endpoint should then generate an event with the required information (Success Auditing Event 4624, which contains information about the version of NTLM. The received event logs contain a ‘Package Name (NTLM only)’ field that state the NTLM’s version). However, collecting these logs cannot be centrally done on the DC and must be retrieved from each individual machine. As well, in many cases the event doesn’t have the NTLM version data or hasn’t even been created. 

Moreover, in most cases, NTLMv1 is found within a legacy application where NTLMv1 authentication is performed against the app server. As such, there is no assurance that the programmer who coded the application implemented a sound auditing mechanism. If the application uses a Windows server, it may be partially audited locally, for example, if it uses internal windows libraries such as IIS authentication (Web server application). However, if the application is completely third-party written, no logs are audited at all. In that case, there is no way to find out if NTLMv1 is in use without intrusive steps (such as decrypting the packets or analyzing the actual app’s code).

While NTLMv1 authentications can be detected partially using network level inspection, such inspection is not possible since in most cases this traffic is encrypted.

So the challenge lies not only in the inherent insecurity of NTLMv1 itself but also in the difficulty of determining whether it’s being used within a given environment. 

Silverfort’s Protection for the NTLMv1 Attack Surface

The Silverfort Unified Identity Protection platform provides organizations with the unique ability not only to discover all NTLMv1 authentications within an environment but to actively block them as well. 

Silverfort analysis engine detects NTLMv1 authentications and flags them as a risk indicator. This risk indicator can be used, both as a filter to discover machines that perform such authentications, and as an access policy trigger. Let’s see how it looks within the Silverfort console:

Discovery

Within the Authentication Logs screen, check the NTLMv1 Authentication box. Once checked, all matching authentications are displayed, providing actionable knowledge about which machines are using NTLMv1 to help decide whether to disable them.

NTLMv1 enabled in Silverfort’s Authentication Logs screen

Protection 

In a similar manner, Silverfort enables the use of an NTLMv1 risk indicator as a trigger to activate an access policy. The action would then be either:

• Deny: Choose this option if you don’t want to allow NTLMv1 at all within the environment as an additional precautionary measure.
  

Silverfort policy to deny access via NTLMv1

• MFA: Choose this option if for any reason you can’t eliminate the use of NTLMv1 (for example, if there is an old application that might break and endanger critical business processes). In this case, even if the authentication flow is compromised, the true user must verify its identity via MFA in order to gain access, effectively disarming attackers’ ability to leverage the protocol’s weaknesses for malicious access.
  

Silverfort policy to require MFA step-up when authenticating via NTLMv1

The Path to Comprehensive Security

In today’s hybrid environment there are many types of systems existing side by side, so comprehensive security means monitoring and protecting all of them. NTLMv1 is just one example of the issues with legacy systems; it’s also important to understand that when the security weakness resides in the legacy infrastructure, a compromise here can enable attackers to gain access to other parts of the environment as well. The right way to think of it is not so much securing legacy systems but rather preventing legacy systems from becoming the gateway to your environment. 

Silverfort’s Unified Identity Protection is the first platform that was purpose-built to protect against identity threats across the entire hybrid enterprise – whether the targeted resource is a SaaS application, a cloud workload, or an on-prem server. Silverfort extends MFA and modern identity security to all core resources that couldn’t be protected before – including NTLMv1.

Is NTLMv1 an attack surface you want to address? Schedule a meeting with one of our experts here.