NTLM Authentication

1. What is NTLM authentication?

NTLM (NT LAN Manager) refers to a family of proprietary authentication protocols from Microsoft.

All NTLM protocols authenticate users and computers based on a challenge/response mechanism. This involves the user proving to the server or domain controller that they know the password associated with the account - but without transmitting it over the network.

NTLM was introduced in 1993 with Windows NT 3.1 and replaced the previously used LM hash method due to glaring security gaps. Due to further security problems with the NTLM protocol, NTLMv2 was introduced with Windows NT 4.0 SP4 and the earlier version was then called NTLMv1.

Starting with Windows 2000, NTLM was replaced by Kerberos as the standard authentication protocol for Active Directory (AD) domains.

Despite known vulnerabilities, the various NTLM versions are still available on current IT systems for compatibility reasons. NTLMv2 is also still used for local logon, network logon for WORKGROUPS, some http servers and also for Single-Sign-On (SSO).

2. The NTLM authentication process

The NTLMv2 protocol uses an NT hash in a challenge/response exchange between the server and the client. The flow of NTLM authentication is as follows:

1. NEGOTIATE: The client machine sends a request to a server with the user name and other configuration information.
2. CHALLENGE: The server generates a random number and sends it to the client computer.
3. AUTHENTICATE: The client computer encrypts the random number using the DES algorithm and the NT hash of the password as a key to prove that it knows the password.
4. The server verifies the identity of the user by ensuring that the challenge was actually created with the correct user/password. To do this, it either uses the stored NT hash from its own SAM database or it forwards the challenge/response pair to the domain controller for validation.

3. How can NTLM authentication be attacked?

NTLM does not send passwords over the network that could be intercepted, but NTLMv1 is a very weak authentication protocol by today's standards. And while v2 is more secure than v1, it is still a far cry from its successor Kerberos.

Pass the Hash

With NTLM authentication, the hash of the password is a crucial element of authentication. So if an attacker finds out the user name and the password hash, he can start procedures directly with NTLM authentication. Knowledge of the actual password is not necessary.

This technique is known as Pass the Hash and has been around for more than 20 years.

For an attacker, the question arises as to how user names and password hash can be captured. User names are quite easy to obtain from the attacker's point of view, for example unencrypted in network traffic. Password hashes are also quite easy to obtain. On end-user systems, password hashes can be found in the file

C:\Windows\System32\config\SAM                                    

The SAM file can be read by any user with administrative privileges.

Likewise, the password hashes are also cached in memory. From there, they can be extracted with tools like Mimikatz.

On the server side, password hashes for domain controllers are stored in the file

C:\Windows\ntds\ntds.dit                                    

file. There, the hashes are vulnerable to DC Sync attacks. They trick a domain controller (DC) into synchronising its own password hashes with someone impersonating another DC.

But there are other ways to get hashes. Especially if you have direct access to the network, tools like Responder can be used quite effectively to get such hashes. .

Password hashes are also stored in the memory of a Remote Desktop Protocol (RDP) connection for the duration of the session. So if a user disconnects without logging off, the password hash will remain in memory for some time.

Recommended countermeasures include:

Brute force attacks

NTLM authentication is also vulnerable to brute force attacks because the hash algorithm that the protocol uses without a so-called salt. A salt adds a random string of characters to a password before it is hashed. Even if two users choose the same password, the password hashes will still differ.

With precalculated hashes of standard passwords and a rainbow table, viable brute-force attacks can be carried out if the password complexity and length are not chosen sufficiently (tip: >15 characters).

No support for multi-factor authentication

The NTLM authentication protocol does not support multi-factor authentication (MFA), so it is sufficient to retrieve a password hash. A second factor such as an authenticator app, a hardware OTP token or an SMS is generally not used.

NTLM relay attack

NTLM authentication is also vulnerable to NTLM relay attacks.

The user's client basically has no way to verify the identity of the server. Therefore, attackers can hang themselves between the client and the server and act as a man-in-the-middle.

Currently, it is also frequently checked during penetration tests, as vulnerabilities have been discovered in recent years that have made this attack vector viable again.

Other vulnerabilities

With NTLM, all lowercase letters in a password string are converted to uppercase before the hash value is created, which limits the possible complexity. As a result, it takes 2.5 hours to figure out an 8-character password given a known hash value (as of 2019, workstation with 8xGPU and HashCat).

Also, NTLMv1 uses a 16-byte random number for the challenge, which is not so random in practice after all.

In NTLMv2, on the other hand, it is a variable-length challenge, which is much stronger. Also, the encryption step in NTLMv2 adds a timestamp.

Both NTLMv1 and NTLMv2 use the hash function MD4, which is considered obsolete. From a cryptographic point of view, this is broken, but nevertheless, in the special use case with NTLM, it can still be considered quite stable for practical purposes.

4. Why is NTLM authentication still used?

Microsoft has already replaced NTLM with Kerberos as the standard authentication protocol in Windows 2000.

However, NTLM authentication is still supported by Windows for backward compatibility. There is still a lot of old software that uses NTLMv2 or even NTLMv1.

Many of the affected applications were developed in the late 1990s and early 2000s. Often the applications are no longer supported by the manufacturer or were programmed directly for a company as a special application.

5. Difference between the successor Kerberos and NTLM

One of the most important differences between NTLM and Kerberos is a modified authentication process.

The authentication process itself no longer runs as a two-step challenge/response, but is designed to be three-step.

Likewise, Kerberos has different cryptographic properties than NTLM. The hash function that NTLM uses to create the password hash has been replaced by an encryption function.

In summary, Kerberos is the clearly more secure protocol. But even Kerberos is not completely free of security problems.

6. Procedure to disable NTLM

As a strategy, I recommend a staged approach.

Audit: First, clarify which applications still need the NTLM protocol. A check via group policy Network security: Restrict NTLM: Audit NTLM authentication in this domain can easily be activated without disturbing the operation. Additional tools can also be used to find out the version of the protocol.

Hardening Clients: With this information, it can be checked whether the applications in question can be configured to exclusively use a stronger protocol (NTLMv2 or optimally Kerberos). Updates should be checked and prioritised accordingly.

Hardening Server: If possible, NTLMv1 and NTLMv2 should be completely disabled via group policy. It is possible to set up an exception list if applications cannot be updated and NTLM should still be required.

7. Can NTLM still be used safely?

The use of NTLM should be minimised or completely deactivated in the network. Companies that must continue to use NTLM mandatorily for compatibility reasons should consider the following points.

1. SMB signing: . To prevent attackers from launching simpler NTLM relay attacks, SMB signing should be enabled on all computers in the network.
2. Block NTLMv1: Since NTLMv1 is completely insecure. It should be completely blocked via the appropriate group policy.
3. LDAP/S Signing: . To prevent NTLM relay in LDAP, LDAP signing and LDAPS channel binding must be enabled on domain controllers.
4. Enhanced Protection for Authentication (EPA): . To prevent NTLM relay on web servers, all web servers (OWA, ADFS) should be configured to only accept requests with EPA.

Basically, the following further measures are also highly recommended. They lead to a hardening of the entire IT landscape.

• Ongoing and regular patching of all IT systems
• Activate Defender Windows Credential Guard
• Limit accounts with administrator rights
• No use of Remote Desktop Protocol (RDP) to manage clients
• Remote management from hardened jump hosts only.
• If necessary: Use Microsoft Local Administrator Password Solutions (LAPS).
• Restrict client-to-client communication, for example with a firewall to prevent lateral movement.