Ridding your network of NTLM – Source: www.csoonline.com

Microsoft has hinted at a possible end to NTLM a few times, but with quite a few Windows 95 or 98 in use that do not support the alternative, Kerberos, it won’t be an easy job to do. There is the option to disable NTLM when using Azure Active Directory but that may not always be the best alternative.

What is NTLM

The acronym is somewhat of a misnomer: it stands for Windows New Technology LAN Manager and harks back to Microsoft’s original network server operating system that first appeared in 1993. Windows NT was born out of a fiery divorce from IBM’s OS/2 operating system and used NTLM as its default authentication protocol. Over the next decade, it was Microsoft’s go-to place for single sign-ons back before SSOs were a major product category of their own.

NTLM harks back to another era of connectivity: when networks were only local connections to file and print servers. Back then, the internet was still far from a commercial product and the web was still largely contained as an experimental Swiss project. That local focus would come to haunt security managers in the coming decades.

This is because, unlike modern SSOs, NTLM uses a simplistic dialog that authenticates users without requiring much in the way of password security. As you might imagine, that isn’t a good way to authenticate anything, with the result that Microsoft has been trying to kill off this ancient protocol for years. It first told the world in 2009 that NTLM was fundamentally insecure and should be removed. That message didn’t land, and NTLM usage continued unabated.

Why NTLM is unsafe

As a result, many applications have made it part of their authentication processes, which is what the hackers count on for their exploits. These exploits pop up regularly, with varying responses from Microsoft. The most recent one includes an NTLMv1 bypass attack discovered by Silverfort recently. This attack is notable in that it can occur even when NTLMv1 has been disabled by a Group Policy mechanism network wide. The vendor claims this motivated Microsoft to remove the protocol from Windows 11 version 24H2 and Windows Server 2025.

Another exploit found last December by 0patch researchers was also a bypass attack: a malicious file viewed in Explorer enables an attacker to obtain NTLM credentials. This is the fourth NTLM vulnerability they have found. The others were PetitPotam, PrinterBug/SpoolSample and DFSCoerce.

“All of these are present on all latest fully updated Windows versions, and if your organization is using NTLM for any reason, it could be affected,” the researchers wrote. Only one of these five exploits have been patched or received CVE numbers, the lone exception being PetitPotam which received CVE-2021-36942 and then CVE-2022-26925.

Back in 2023, researchers found another relay and hash-stealing attack that works by sending a specially crafted email that doesn’t require a user to open or click on it. This was given the CVE 2023-23397.

Researchers from Beyond Trust describe its operations: “The vulnerability is triggered when an attacker sends a specially crafted calendar invite or appointment to a target victim’s email address. This invite contains additional properties that cause Outlook to make an SMB [server message block] connection and trigger NTLM authentication to a server on the internet that is under the attacker’s control. From there, the attacker can capture the NTLM hashes and use them to authenticate themselves as the victim, leading to potential escalation of privileges and further compromise of the environment.”

Aside from the lack of password security, NTLM has several other behaviors that make it a hacker’s paradise. First, it doesn’t require any local connection to a Windows Domain. Also, it is needed when using a local account and when you don’t know who the intended target server is. On top of these weaknesses, it was invented so long ago — indeed before Active Directory was even considered — that it doesn’t support modern cryptographic techniques, making its simple unsalted hashing system trivially easy to break and decode.

Kerberos versus NTLM

Those modern techniques are thankfully part of the Kerberos protocols, which is what Microsoft has been trying to replace NTLM with over the past several years. Since Windows Server 2000, it has been the default choice for authentication. “NTLM relies on a three-way handshake between the client and server to authenticate a user,” wrote Crowdstrike’s Narendran Vaideeswaran in a blog in April 2023. “Kerberos uses a two-part process that leverages a ticket granting service or key distribution center.” That ticketing process means that Kerberos is secure by design, something that never could be claimed for NTLM.

One of the reasons for NTLM’s enduring reign is that it was easy to implement. This is because when Kerberos (or something else) didn’t work properly, NTLM was the fallback choice, which means if a user or an app tries to authenticate with Kerberos and fails, it automatically (in most cases) tries to use NTLM protocols. “For example, if you have workgroups with local user accounts, where the user is authenticated directly by the application server, Kerberos won’t work,” wrote TechRepublic. Microsoft has said that local users still make up a third of NTLM usage, one of the reasons why Microsoft wants to maintain its older systems. Another pain point is the protocol used to implement Remote Desktop Services, which can often fallback to NTLM. However, “Microsoft supports legacy security configurations long past their expiration dates,” writes Adrian Amos in a blog post from November 2023.

Microsoft’s pleas to encourage NTLM’s replacement were somewhat disingenuous since there weren’t any easy fixes. In the mid-1990s they offered an updated version 2 of NTLM that was supposed to solve some of the security issues. It was a half-hearted effort, and v2 is still rife with exploits. One X user posted this comment in April: “For about a decade or more, Microsoft took an approach that customers who wanted to be more foundationally secure needed to either possess significant expertise and determination to implement non-default and obscure things or shift to using its new MS cloud stuff. But now Microsoft is finally launching a major effort to actually help customers transition away from NTLM without unacceptably breaking compatibility.”

That happened last fall, when Microsoft documented the evolution of Windows authentication services. They said they were “expanding the reliability and flexibility of Kerberos and reducing dependencies on NTLM.” That post mentions an auditing tool that can discover NTLM instances across your networks, and a feature called IAKerb that allows clients to use Kerberos in more diverse network topologies and adds encryption to the authentication dialog. However, NTLM is still alive as a fallback option.  Eventually, NTLM will be disabled completely in Windows 11, although no precise timeline was indicated.

How to get rid of NTLM

But moving completely off NTLM isn’t going to be easy. Enterprises need to follow a series of steps to finally rid themselves of the NTLM scourge. First, you should perform a protocol audit that will discover all the various nooks and hidden apps that it resides, including legacy clients that are running unpatched and ancient versions of Windows (such as Windows 95 or 98) that can’t support Kerberos.

That audit could uncover where you have used NTLM in your own apps. This will require, says Amos, “introducing a new mechanism for local Kerberos authentication into every Windows client, and it means cleaning up old configurations and code. This will be a Herculean lift that will need to be addressed by every stratum of an enterprise’s development team and literally every single app in the MS portfolio will have to be examined to ensure it supports Kerberos authentication.” That lift may not be as painful as he cites, for example, you should change any authentication strings in your own code from “ntlm” to “negotiate” to enable better security.

Second, put in place specific blocks. Vaideeswaran suggests, “to be fully protected from NTLM relay attacks, you will need to enable server signing and EPA on all relevant servers and you should fully patch with the latest Microsoft security updates. You should also restrict any NTLM network traffic by setting a Group Policy Object to refuse NTLM responses.” In addition, you can configure SMB clients to block NTLM in more recent Windows 11 and Windows Server preview versions.

Finally, configure Kerberos to support IP addresses to support Service Principal Names, as Microsoft outlined in 2021. This is enabled by changing a Registry entry on each endpoint. This is essential if your network has load balancers to split up TCP/IP traffic, for example.

To help with these efforts, last fall Microsoft has produced an hour-long webinar on what is new and contains other tips on how to migrate away from NTLM, and ways that enterprises can strengthen their infosec. It certainly is time to make these changes and prevent future exploits.