NTLM Authentication

Overview

NTLM is a challenge-response authentication protocol used by Windows. It has been included in the Windows NT family since Windows NT 3.1 and is used for Integrated Windows Authentication over services such as SMB and HTTP. The password itself is not sent over the network. NTLM remains for compatibility, including local accounts, workgroups, and fallback when Kerberos cannot be used.

Terminology

• NT hash (NTHash): The MD4 hash of a password encoded as UTF-16LE (Unicode). It is a representation of the password stored by SAM or AD, not a network authentication protocol.
• NTLM protocol: An authentication method with three steps: Negotiate, Challenge, and Authenticate.
• NetNTLMv1/NetNTLMv2 (NTLMv1/NTLMv2 response): Challenge-response strings generated during network authentication. They are conventionally called “hashes,” but they are not reusable passwords.

Main Components

Component	Description
ServerChallenge	An eight-byte random value (nonce) sent in Type 2.
ClientChallenge	An eight-byte random value generated by the client.
Timestamp	The time in the NTLMv2 blob (Windows FILETIME).
TargetInfo	A set of Attribute-Value (AV) pairs, including server and domain names.
NTLMv2 Hash	A derived value using HMAC-MD5: HMAC-MD5(key=NTHash, msg=Uppercase(Username) + Domain).
NTProofStr	The core of the response, calculated with HMAC-MD5.
NTLMv2 Response	The concatenation `NTProofStr

Authentication Flow (Type 1/2/3)

1. Type 1 (Negotiate): The client offers available features.
2. Type 2 (Challenge): The server returns a random challenge.
3. Type 3 (Authenticate): The client uses NTHash to calculate and send a response to the challenge.

Visualizing Challenge-Response

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server
    C->>S: Type 1 (Negotiate)<br/>Flags, Domain/Workstation
    S->>C: Type 2 (Challenge)<br/>ServerChallenge, TargetInfo, Flags
    Note over C: Generate NTLMv2 response
    C->>S: Type 3 (Authenticate)<br/>User/Domain, NTLMv2 Response, MIC(optional)
    S->>S: Verify response and authorize

flowchart TB
    P[Password] --> U[UTF-16LE]
    U --> H[MD4 = NTHash]
    H --> V[HMAC-MD5 key]
    S[ServerChallenge] --> B[NTLMv2 Blob]
    C[ClientChallenge] --> B
    T[Timestamp] --> B
    TI[TargetInfo] --> B
    B --> R[HMAC-MD5 -> NTProofStr]
    R --> O[NTLMv2 Response = NTProofStr || Blob]

See NTHash and HMAC-MD5 for the calculations and implementation examples shown in the diagrams.

NTLMv1

• Pad the NT hash (NTHash) to 21 bytes, split it into three DES keys, and use them to encrypt the ServerChallenge.
• Without a ClientChallenge or timestamp, it is vulnerable to offline cracking and relay.
• This legacy method should be disabled where possible.

NTLMv2

• Use HMAC-MD5 with the NTLMv2 Hash as the key to generate a response. The NTLMv2 Hash is derived from NTHash and the user and domain information.
• Include the client challenge, timestamp, and target information (TargetInfo), as well as the server challenge.
• It is stronger than v1, but remains vulnerable to relay when controls such as SMB signing or channel binding are absent.

NTLM and Windows Versions

• NTLM was introduced in Windows NT 3.1 and included in later Windows NT systems (Windows 2000, XP, Vista, 7, 8, 10, 11, and Windows Server).
• It remains implemented for compatibility in Windows 11 and Windows Server 2022, and can be disabled or restricted by policy.

Authentication in Current Windows Environments

• Active Directory domain join: Kerberos is the default; NTLM remains as a fallback.
• Entra ID join (Azure AD join): Cloud authentication based on OAuth 2.0 and OpenID Connect is central, alongside key-based authentication such as Windows Hello for Business (WHfB).
• Local account: Local logon uses NTHash stored in SAM, while network authentication uses NTLM.

NTLM in Current Operations

• Domain environments prefer Kerberos. NTLM is used for local authentication, workgroups, and fallback when Kerberos fails, such as from a missing SPN, DNS problem, clock skew, or absent trust relationship.
• Recent Windows versions use NTLMv2 responses by default, but policy can still allow NTLMv1.
• Examples of hardening:
  • Disable NTLMv1 and LM.
  • Restrict or audit NTLM through Group Policy settings such as “Network security: LAN Manager authentication level” and “Restrict NTLM.”
  • Deploy SMB signing and Extended Protection for Authentication (EPA) or channel binding.