NTLM is an old technology, introduced way back in Windows NT 3.1, so why it is worth talking about today? Simply put, NTLM authentication is a huge security vulnerability that’s still being exploited in organizations around the world — and a risk you can minimize or even eliminate in pretty short order.
In this blog, I’ll explain what NTLM authentication is and the security concerns that come with using it. Then I’ll detail what’s involved in minimizing or even eliminating its use in your IT ecosystem.
What is NTLM?
NTLM is an authentication protocol — a defined method for helping determine whether a user who’s trying to access an IT system really is actually who they claim to be. It was released in 1993, which is a long time ago, especially when you consider that IT years pass even faster than dog years. In 1998, Microsoft released an improved version, NTLMv2, in Windows NT 4.0 Service Pack 4.
I’m emphasizing the age of these technologies not to cast shade on them, but to provide context. NTLM is the successor to an ever older protocol, LM, which was used in Microsoft’s LAN Manager product of the late 1980s. When LM was created, computer networks were far simpler, used primarily for file and print sharing and maybe a few client-server applications. There was no internet to speak of, so each organization’s network stood alone, unconnected to any other company’s network.
As a result, the chief form of cybercrime that IT pros needed to worry about was someone looking to steal user passwords by eavesdropping on network logon traffic. It doesn’t take a genius to figure out that there’s a straightforward way to eliminate this risk: Don’t send user passwords across the network.
But then how can a user prove they are who they claim to be? What if there was something else the user could send across the network to prove they know the password that the IT system has on record?
There is a password hash.
How NTLM authentication works
A password hash is a pretty cool thing. It’s created by a hashing algorithm — a special function that transforms a password into a different string of characters. The function is repeatable: The same password will always generate the same hash. And it’s one-way: It’s easy to transform a password into a hash, but there’s no way to transform the hash back into the password.
To see how the password hash addresses the problem at hand, let’s step through the NTLM authentication process that happens when I attempt to log on to my corporate network:
- I enter my username and password on my local computer.
- My computer runs the password I typed through the standard hashing algorithm used by both client machines like mine and the domain controllers (DCs) that provide authentication and authorization services. That gives it my password hash, which it will use in Step 5.
- My machine sends the nearest DC a logon request, which includes my username.
- The DC sends back a random number, which is known as a logon challenge.
- My computer encrypts the logon challenge using the hash of my password and sends the result (response) back. (Now you know why NTLM is called a challenge-response authentication protocol.)
- To see whether I provided the correct password, the DC encrypts the logon challenge using the hash of the password that it has on record associated with the username that came in the logon request — which was created using the same hashing algorithm as my client machine is using.
- The DC compares the result it gets with the response my computer sent. Since both the DC and my client machine are using the same hashing algorithm and the same encryption process, if the results match, that proves I entered the correct password. In that case, I’m authenticated.
Note that during this NTLM authentication process, neither my password or its hash ever got sent across the network. For further security, all of these communications are encrypted using a shared secret key, which is my computer’s domain password.
So, what’s the problem with NTLM authentication?
While it’s true that no passwords are sent across the network for snooping snoopers to grab, NTLMv1 is a very weak authentication protocol by today’s standards. And while v2 is much more secure than v1, it’s still not nearly as secure as more recent protocols like Kerberos.
Do you remember back when merchants took your physical credit card, placed it on a special device, put a special sales slip on top of it, and slid the handle across to take an imprint of your card? You’d get one copy, and they’d slip the other one into their till. That meant your credit card number was stored by every merchant you visited, giving thieves plenty of opportunities to steal it.
NTLM authentication is like that. As you can see from the process above, the password hash is a critical element of authentication — if an attacker can obtain my username and password hash, they can start at step 3 of the process above; this hacking technique is called pass the hash and dates back to 1997. Since usernames are sent in plain text, they’re easy for attackers to grab. Unfortunately, password hashes aren’t that hard to obtain, either — they’re scattered in multiple places. On the client machine, password hashes are stored in the SYSTEM and SAM files, which can be read by anyone who has administrator-level privileges and are vulnerable to multiple hacks as well. By default, hashes are also cached in memory, where attackers can potentially extract it using a readily available tool like Mimikatz.
On the server side, password hashes are stored in the NTDS.dit file on each domain controller. There, the hashes are vulnerable to DCSync attacks, which tricks a DC into syncing its store of hashes with malicious software pretending to be another DC. Other ways to get hashes include Responder, which is a tool that emulates a server, and attacks that exploit the Link-Local Multicast Name Resolution (LLMNR) protocol.
Plus, hashes aren’t passed only during the logon process I used as an example above. After all, the reason I log on to my corporate network is because I need to use some resources there, such as a certain piece of data, a particular application or the printer down the hall. But not every user has permissions to access every resource, so whenever a request comes in, the resource will want to know, “Who’s asking?” So my client needs to pass my credentials across the network again and again and again. Password hashes are also retained in the memory of Remote Desktop Protocol (RDP) server software for the duration of the user session — which means that if a user disconnects rather than logging out, their password hash still in memory.
Is that all?
Not by a long shot. NTLM authentication is also very vulnerable to brute-force attacks because the hash algorithm that the protocol uses is well known and passwords are not salted. Salting adds a random string of characters to a password before it is hashed, so even if you and I happen to choose the same password, we will have different password hashes. Since NTLM does not allow for salting, every user who picks the same password will have the same password hash — no matter what network they’re accessing. As a result, attackers can take a list of common passwords, run them through the known hashing algorithm, and get a rainbow table of password hashes that are likely to be associated with at least some users in a network. All they need to do is try them until they happen upon the correct one. (You’re not using any default passwords, are you? Especially for powerful admin accounts? You can be sure attackers include them in their tables.)
Plus, the NTLM authentication protocol does not support multifactor authentication (MFA), so hackers who manage to grab a password hash never have to worry about being challenged for a second piece of information, such as code sent to the user by email or SMS, in order to authenticate.
NTLM authentication is also subject to NTLM relay attacks. Basically, because the user’s client has no way to validate the identity of the server that’s sending the logon challenge, attackers can sit between clients and servers and relay validated authentication requests in order to access network services. Although this is an old technique that is widely used in penetration testing, vulnerabilities have been discovered in the past few years that enable hackers to bypass some security measures, making this form of attack popular again.
There are also some more technical reasons why NTLM is a weak protocol. Version 1 uses a 16-byte random number for the logon challenge, which is not very secure. In v2, it’s a variable-length challenge, which is much better, and the encryption step adds in a timestamp. However, both versions of the NTLM authentication protocol rely on the outdated MD4 cryptographic hash function; there is no support for modern cryptographic methods like AES or SHA-256. Weaknesses in MD4 were published in 1991, before NTLMv1 was even introduced; today, it’s considered severely compromised. In addition, all lowercase letters in a password string are converted to uppercase before creating the hash, limiting the possible result set. As a result, by 2012, every possible 8-character password could be cracked in under 6 hours; in 2019, that time was slashed to less than 2.5 hours.
Wow, so why does anyone still use NTLM authentication?
Technically, they don’t have to. Microsoft replaced NTLM with Kerberos as the default authentication protocol way back in Windows 2000. Kerberos is a much stronger protocol that relies on a ticket granting service or key distribution center, and uses encryption rather than hashing. (I explain Kerberos authentication in detail here.)
However, NTLM authentication is still supported in Windows for a very good reason: to maintain compatibility with older systems and enable logon authentication on stand-alone systems. And there are still plenty of old applications out there that use v2 and even the much weaker v1.
If an organization relies on those applications for important business processes, they will naturally be reluctant to risk breaking them by disabling the authentication protocol they rely on. After all, to the management team, the business risks seem far more pressing and clearer than the security risks I detailed above. The IT team might be reluctant as well. After all, many of the applications involved were developed and implemented back in the 1990s and early 2000s, so the IT pros in charge of the corporate network today probably had nothing to do with deploying them. Therefore, they might not be confident about the risks involved in turning off NTLM.
Reduce your AD attack surface.
Is there a way to reduce, disable or eliminate NTLM authentication safely?
Yes! The best strategy is to take a phased approach. Start by simply doing an audit: What applications are using each of the two versions of the protocol? You can enable this auditing using the Group Policy setting Network Security: Restrict NTLM: Audit NTLM authentication in this domain. A third-party Active Directory security solution like Change Auditor will provide more detailed information, such as which version of the protocol is being used.
With that information in hand, check whether you can configure the applications to use a stronger protocol (NTLMv2 or, ideally, Kerberos), or whether there is a newer version of the application or a different application with similar functionality that you could use instead.
Ideally, you want to eliminate use of both versions of NTLM in favor of Kerberos. To disable NTLM, use the Group Policy setting Network Security: Restrict NTLM. If necessary, you can create an exception list to allow specific servers to use NTLM authentication. At a minimum, you want to disable NTLMv1 because it is a glaring security hole in your environment. To do that, use the Group Policy setting Network Security: LAN Manager authentication level.
Conclusion
The NTLM authentication protocol, especially v1, poses a serious security threat to any IT environment where it remains enabled. I don’t recommend disabling it blindly, since that could easily disrupt important business processes. But it’s worth making the effort to determine exactly where it’s being used and systematically reconfiguring or replacing applications so that you can minimize or even eliminate the use of NTLM authentication in your IT ecosystem.
