NTLM (NT LAN Manager) is Microsoft's old authentication protocol that was replaced with Kerberos starting Windows 2000. It was designed and implemented by Microsoft engineers for the purpose of authenticating accounts between Microsoft Windows machines and servers. Even though it has not been the default for Windows deployments for more than 15 years, it is still very much in use and I have not yet seen a network where it has been completely abandoned. In fact it also supported by the latest version of Active Directory.
The challenge with having NTLM in your network is that it is easily exploitable and puts an organization at risk for a breach. In this blog, I’ll discuss why NTLM is risky as well as what are some of the best ways to mitigate these risks. [If you are interested in seeing how Preempt can help you get a handle of NTLM, check out this video.]
Quick fun facts
- Prior to NTLM, Microsoft had the LAN Manager (LM) authentication protocol.
- The protocol was developed by Microsoft together with IBM and was a symbol of simpler times when the Internet was a novelty and cyber threats were not as scary.
- LM uses an extremely weak cryptographic scheme. So much so, that with modern computational devices, an LM hash is pretty much equivalent to sending plaintext passwords.
- NTLM was introduced in 1993 with Windows NT 3.1 and was later improved in a second version (NTLMv2) in Windows NT 4.0.
- NTLMv2 had some security improvements around strength of cryptography, but some of its flaws remained.
- Even in the most recent version of Windows, NTLM is supported.
- Active Directory is required for default NTLM and Kerberos implementations.
NTLM Authentication Flow
With NTLM, a user proves their identity to the server by means of encrypting a random challenge generated by the server.
Figure 1 illustrates this flow:
- User machine sends a request to connect to the server (step 2)
- Server generates a random nonce to be encrypted by user (step 3)
- User machine encrypts the nonce with the password hash to prove knowledge of the password (step 4)
- The server validates user identity by making sure encrypted challenge was indeed created by the correct user password either by using data in its own SAM database or by forwarding challenge-response pairs for validation in the domain controller (DC validation in step 5-7)
All versions of NTLM use this flow. The main difference between versions is that in NTLMv2 the client includes a client nonce and a timestamp. This helps mitigating offline replay attacks.
Issues and Vulnerabilities
Now for the really interesting stuff. Say you are a very responsible admin. You make sure all systems are patched. You have some network and endpoint protection solutions. And of course you've disabled LM and NTLMv1 completely allowing only the safer NTLMv2.
Here are the issues.
All NTLM versions use a relatively weak cryptographic scheme. While I agree none of the weaknesses are deal breakers, they do make it relatively easier to crack hashes and achieve plaintext passwords. First, hash is based on MD4 which is relatively weak. Second, even though hash it is salted before it is sent over the wire, it is saved unsalted in a machine’s memory. But, the worst issue is that in order to authenticate to a machine, a user must respond to a challenge from the target, which exposes its password to offline cracking. Just to illustrate how severe this issue is, it was recently published that all passwords with 8 characters can be cracked in less than a day with almost standard hardware.
Client and server are tasked with creating nonces for challenges by themselves with no help from the DC and dispensing weak nonces can result in malicious impersonation. You might be inclined to ask who will create weak nonces and be surprised to find that the answer is Microsoft. Yes, you heard correctly. In 2011 it was discovered that Microsoft SMB (Server Message Block) server implementation had serious security issues with its nonces. Even though these are fixed, they were undetected for approximately 20 years. Now imagine what's going on with your 3rd party server and it's NTLM implementation.
No Multi Factor Authentication (MFA)
NTLM, being strictly password based, lacks effective support for smart cards and other Multi Factor Authentication solutions. Sure, you can utilize smart cards for login and authenticate with NTLM, but as others have pointed out, this makes somewhat of a mockery of the whole smart card deployment because (as I mentioned in a previous blog post) you could pass the hash and use NT hash directly.
All these are just appetizers before the main course. The most critical issue with NTLM is that it does not commonly provide mutual authentication. And while this is an issue by itself, it leads to the more severe issue of NTLM being susceptible to replay and man-in-the-middle attacks. This can happen whenever a user authenticates to a server via NTLM. If you can hijack the connection (with a physical intrusion or a compromised machine) and you simply relay the creds, then you can do whatever you want with any server in the network using the user’s credentials. Basically, the attack vector of relaying NTLM creds has been around from 2001 and is still very much exploitable.
One mitigation is to force SMB signing on all machines. But as this configuration can be hard to enforce throughout the network, and it only partially solves the problem as NTLM over HTTP is still exploitable. A very recent exploit using this NTLM issue (along with other issues) is Hot Potato - this weakness allows you to achieve local admin privileges on any Windows machine where you have code running with a guest account. One of the mitigations that Microsoft lists against these vulnerabilities is to keep network secure and states that these vulnerabilities are exploitable only when the network already has a major breach. With today's “assume breach” mentality this is not satisfactory in itself.
At this year's Black Hat conference, security researchers Hormazd Bilimoria and Jonathan Brossard showed how they can use NTLM relay to compromise a network from the internet with no compromised endpoints by fooling Internet Explorer (or Edge) into authenticating to a server not in the local intranet by using a rogue img tag. They also went so far as to show that the issue is with a specific DLL that is possibly used in a variety of applications (both MS and 3rd party) making them all unsecured. This means that even if Internet Explorer (or Edge) is miraculously patched, there are probably many vulnerable applications out there.
I hope you got the message that NTLM is risky and should be used with caution (if not totally restricted) in your organization’s network. In fact, some of the flaws are rooted so deep in the protocol that they are not patched until even some of the most recent Windows versions. So why is NTLM still around? It turns out that because it is a legacy protocol it is very hard to remove it from the network without breaking anything. Microsoft has a guide for restricting NTLM. The guide suggests to start by auditing all NTLM traffic, followed by analysis of servers and users that use NTLM, determining which use can be abandoned and which should be set as an exception after restricting NTLM.
In a later blog, I will discuss all the reasons why removing NTLM is so hard and how you could use User Entity and Behavior Analysis (UEBA) solutions to analyze and determine who uses NTLM, assess the risk in your network, and reduce the NTLM attack surface significantly.