NTLM is Microsoft’s mythological legacy authentication protocol. Although new and better authentication protocols have already been developed, NTLM is still very much in use – even the most recent Windows versions support NTLM, and its use is still required when deploying Active Directory.
While better solutions are already in use, the obvious question is why the NTLM protocol is still here? Basically, because NTLM is a legacy protocol, it is very hard to disable without causing damage to production systems. The challenge starts with determining which machines require the use of this function and which don’t. After mapping the usage, it is hard to determine how to move from NTLM usage to a more secure authentication protocol without breaking anything.
NTLM has two versions – NTLMv1 and NTLMv2. NTLMv2 suppose to offer better security than its previous version, and to some extent it does provides better defense against relay and brute force attacks, but does not completely block them. Our main conclusion from this situation is that the best way to protect your organization from NTLM vulnerabilities is in fact, not to use it! For a complete overview of NTLM vulnerabilities- continue your reading here.
This blog post will cover:
- NTLM authentication process
- How NTLMv2 is different than NTLMv1
- Common NTLM vulnerabilities and NTLMv2 answer for them
- How can you stop using NTLM
NTLM Server – Client Authentication Process:
The NTLMv1 protocol uses an NT Hash or KM hash (depending on its configuration), in a challenge/response exchange between the server and the client. The NTLM authentication flow is as follows:
- The client machine sends a request to connect to the server.>
- The server generates a random nonce to be encrypted by the client.
- The client machine encrypts the nonce with the password hash to prove knowledge of the password.
- The server validates the user’s identity by ensuring that the challenge was indeed created with the correct user/password. It does this either by using data from its own SAM database or by forwarding challenge-response pairs for validation in the domain controller.
How NTLMv2 is Different From NTLMv1:
NTLM v2 also uses this flow with a slight change. In NTLMv2, the client includes a timestamp, and a username together with the nonce in step 3 above. This helps mitigate offline relay attacks, but leaves NTLMv2 exposed to other NTLMv1 vulnerabilities, and therefore does not provide a satisfactory solution.
In addition, while NTLMv1 is using a 16-byte random number challenge, NTLMv2 provides a variable-length challenge.
Because it is so commonly used, it is important to be familiar with all of the NTLM vulnerabilities.
Security Issues in NTLMv1 protocol and NTLMv2 Answer:
The NTLM cryptography scheme is relatively weak, making it relatively easy to crack hashes and derive plaintext passwords. It’s easy enough for standard hardware to be able to crack an 8-character password in less than a day. This is for three main reasons:
- The hash is based on MD4, which is relatively weak.
- The hash is saved unsalted in a machine’s memory before it is salted and sent over the wire.
- A user must respond to a challenge from the target, which exposes the password to offline cracking. This prevents offline Relay attacks.
No mutual authentication:
This flaw exposes the protocol to a man-in-the-middle (MITM) attack. When a client communicates with a server, it does not validate the server’s identity (this is known as one-way authentication). A malicious actor with MITM capabilities can send malicious data to the client while impersonating the server.
These flaws are considered minor when you keep in mind the most critical NTLM flaw – which exposes servers in Active Directory environments to NTLM relay and remote code execution attacks.
In this attack, the attacker hijacks the client-server connection and spreads laterally to the entire system using the user’s credentials. While Microsoft has tried to develop mitigation techniques for this issue, all of those mitigation patches have been hacked. No NTLM version provides a solution for this issue, which means that all NTLM users (which is most likely almost all of you that have continued reading up until here) are at great risk for a devastating attack.
How can you stop using NTLM:
There’s a solution to all the challenges involved in abandoning NTLM –CalCom’s Hardening Solution (CHS). CHS learns your system and determines exactly which server can continue working without outages after disabling NTLM. It will alert regarding the potential impact when disabling the protocol. After you decide on your course of action based on CHS’s findings, CHS automatically implements your decision on the entire production environment, significantly reducing the potential for configuration drift. Learn more about it here.