The Security Risks of NTLM: Proceed with Caution
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 17 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 some of the best ways to mitigate these risks.
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 basically 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 still 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
- Server generates a random nonce to be encrypted by user
- User machine encrypts the nonce with the password hash to prove knowledge of the password
- 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
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 with 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 the hash 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 the 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.
No Mutual Authentication
Unlike Kerberos, when a client authenticates to a server using NTLM, it cannot validate the identity of the server. This means that a malicious actor with man-in-the-middle capabilities could send the client fake/malicious data while impersonating the server.
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 this configuration can be hard to enforce throughout the network, and it only partially solves the problem as NTLM over HTTP is still exploitable. One of the mitigations that Microsoft lists against these vulnerabilities is to simply keep the network secure, stating that these vulnerabilities are exploitable only when the network already has a major breach. With today’s “assume breach” mentality, this is not satisfactory by itself.
At the 2015 Black Hat conference in Vegas, security researchers Hormazd Billimoria 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.
Last year, Preempt alerted Microsoft to LDAP and RDP Relay vulnerabilities in NTLM, some of which failed to defend against credential forwarding. Microsoft acknowledged the issue – a video overview of the issues are here, and further reading can be found here.
I hope this helps drive 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, and ultimately determining which uses 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 difficult 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.
Editor’s note: a version of this blog was originally published Oct 20, 2016. The post has been updated as of Oct. 18, 2018.
Posted by Yaron Zinar on October 18, 2018 10:50 AM