{"id":1579,"date":"2025-01-20T07:00:00","date_gmt":"2025-01-20T07:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=1579"},"modified":"2025-01-20T07:00:00","modified_gmt":"2025-01-20T07:00:00","slug":"ridding-your-network-of-ntlm","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=1579","title":{"rendered":"Ridding your network of NTLM"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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\u2019t be an easy job to do. There is the option to disable NTLM when using Azure Active Directory<\/a> but that may not always be the best alternative.<\/p>\n

What is NTLM<\/h2>\n

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

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.<\/p>\n

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\u2019t 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<\/a> that NTLM was fundamentally insecure and should be removed. That message didn\u2019t land, and NTLM usage continued unabated.<\/p>\n

Why NTLM is unsafe<\/h2>\n

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\u00a0NTLMv1 bypass attack discovered by Silverfort recently<\/a>. 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.<\/p>\n

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.<\/a> This is the fourth NTLM vulnerability they have found. The others were PetitPotam<\/a>, PrinterBug\/SpoolSample<\/a> and DFSCoerce<\/a>.<\/p>\n

\u201cAll 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,\u201d 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<\/a> and then CVE-2022-26925<\/a>.<\/p>\n

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

Researchers from Beyond Trust describe its operations<\/a>: \u201cThe vulnerability is triggered when an attacker sends a specially crafted calendar invite or appointment to a target victim\u2019s 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\u2019s 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.\u201d<\/p>\n

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

Kerberos versus NTLM<\/h2>\n

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. \u201cNTLM relies on a three-way handshake between the client and server to authenticate a user,\u201d wrote Crowdstrike\u2019s Narendran Vaideeswaran in a blog in April 2023<\/a>. \u201cKerberos uses a two-part process that leverages a ticket granting service or key distribution center.\u201d That ticketing process means that Kerberos is secure by design, something that never could be claimed for NTLM.<\/p>\n

One of the reasons for NTLM\u2019s enduring reign is that it was easy to implement. This is because when Kerberos (or something else) didn\u2019t 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. \u201cFor example, if you have workgroups with local user accounts, where the user is authenticated directly by the application server, Kerberos won\u2019t work,\u201d wrote TechRepublic<\/a>. 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, \u201cMicrosoft supports legacy security configurations long past their expiration dates,\u201d writes Adrian Amos in a blog<\/a> post from November 2023.<\/p>\n

Microsoft\u2019s pleas to encourage NTLM\u2019s replacement were somewhat disingenuous since there weren\u2019t 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<\/a>. One X user posted this comment in April<\/a>: \u201cFor 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.\u201d<\/p>\n

That happened last fall, when Microsoft documented the evolution of Windows authentication services<\/a>. They said they were \u201cexpanding the reliability and flexibility of Kerberos and reducing dependencies on NTLM.\u201d 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.\u00a0 Eventually, NTLM will be disabled completely in Windows 11, although no precise timeline was indicated.<\/p>\n

How to get rid of NTLM<\/h2>\n

But moving completely off NTLM isn\u2019t 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\u2019t support Kerberos.<\/p>\n

That audit could uncover where you have used NTLM in your own apps. This will require, says Amos, \u201cintroducing a new mechanism for local Kerberos authentication into every\u00a0Windows\u00a0client, and it means cleaning up old configurations and code.\u00a0This will be a Herculean lift that will need to be addressed by every stratum of an enterprise\u2019s development team and literally every single app in the MS portfolio will have to be examined to ensure it supports Kerberos authentication.\u201d That lift may not be as painful as he cites, for example, you should change any authentication strings in your own code from \u201cntlm\u201d to \u201cnegotiate\u201d to enable better security.<\/p>\n

Second, put in place specific blocks. Vaideeswaran suggests, \u201cto 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.\u201d In addition, you can configure SMB clients to block NTLM in more recent Windows 11 and Windows Server preview versions<\/a>.<\/p>\n

Finally, configure Kerberos to support IP addresses to support Service Principal Names, as Microsoft outlined in 2021<\/a>. 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.<\/p>\n

To help with these efforts, last fall Microsoft has produced an hour-long webinar<\/a> 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.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019t be an easy job to do. There is the option to disable NTLM when using Azure Active Directory but that may not always […]<\/p>\n","protected":false},"author":0,"featured_media":1580,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1579","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1579"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1579"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1579\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/1580"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1579"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1579"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1579"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}