NTLM Authentication

Active Directory (AD) supports multiple authentication protocols and techniques to verify the identity of Windows systems and users. Over time, some of these mechanisms have been deprecated or replaced. For example, older protocols like WDigest were commonly used in legacy versions of Windows but are no longer enabled by default in modern systems.

From an offensive (red team) standpoint, understanding both modern and legacy authentication methods is critical. Attackers often succeed not by breaking the newest defenses, but by abusing older protocols that still exist for compatibility reasons. In this article, we focus on one of the most important legacy mechanisms still widely encountered in real-world environments: NTLM authentication.

NTLM (NT LAN Manager) authentication is typically used in situations where Kerberos cannot be applied. Common examples include:

• A client authenticating to a server using an IP address instead of a hostname.
• A user authenticating to a hostname that is not registered in DNS or not integrated with Active Directory.
• Third-party or legacy applications that do not support Kerberos and rely on NTLM instead.

Because NTLM acts as a fallback mechanism, it remains enabled in many environments—even when administrators are aware of its weaknesses. This makes NTLM a frequent target for attackers.

At a high level, NTLM authentication is a challenge–response protocol. While the internal process involves several steps, the core idea can be understood as follows:

1. NTLM Hash Creation

The client starts by computing a cryptographic hash of the user’s password, known as the NTLM hash. This hash is derived locally and never sent directly over the network.

2. Username Sent to the Server

The client sends its username to the target server to initiate authentication.

3. Server Challenge (Nonce)

The server responds with a random value called a nonce or challenge. This value is different for each authentication attempt.

4. Client Response

The client encrypts the nonce using the previously calculated NTLM hash. The result is called the NTLM response, which is sent back to the server.

5. Forwarding to the Domain Controller

The server forwards the following information to the Domain Controller (DC):

• Username
• Original nonce
• NTLM response from the client

6. Verification by the Domain Controller

Since the Domain Controller stores NTLM hashes for all domain users, it performs the same calculation:

• It encrypts the nonce using the stored NTLM hash of the user.
• It compares the result with the response received from the server.

7. Authentication Result

If the two values match, authentication is successful. Otherwise, the request is rejected.

From an attacker’s point of view, this process is valuable because the NTLM response can be captured and reused or attacked offline.

Like other cryptographic hash functions, the NTLM hash cannot be reversed to directly reveal the original password. However, NTLM relies on a fast hashing algorithm, which introduces a serious weakness.

Fast hashes are efficient for authentication—but also efficient for attackers performing brute-force or dictionary attacks.

With modern hardware such as GPUs:

• An 8-character password can potentially be cracked in a matter of hours.
• A 9-character password may fall within days under the right conditions.

This makes NTLM especially vulnerable when users rely on short or weak passwords.

Why NTLM Still Exists

Despite its well-known weaknesses, NTLM cannot simply be disabled in many enterprise networks. The reasons include:

• NTLM acts as a critical fallback authentication mechanism.
• Many legacy systems and third-party applications still depend on it.
• Fully migrating to Kerberos-only environments is often complex and risky.

From a red team perspective, this persistence is significant. NTLM remains a realistic and valuable attack surface, frequently abused through techniques such as relay attacks, credential capture, and offline password cracking.