NT LAN Manager
||This article may require cleanup to meet Wikipedia's quality standards. (August 2010)|
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product, and attempts to provide backwards compatibility with LANMAN. NTLM version 2 (NTLMv2), which was introduced in Windows NT 4.0 SP4 (and natively supported in Windows 2000), enhances NTLM security by hardening the protocol against many spoofing attacks, and adding the ability for a server to authenticate to the client.
Microsoft no longer recommends NTLM in applications:
"Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms (RFC1321) for integrity, and it uses RC4 for encryption.
Deriving a key from a password is as specified in RFC1320 and FIPS46-2. Therefore, applications are generally advised not to use NTLM."
While Kerberos has replaced NTLM as the default authentication protocol in an Active Directory (AD) based single sign-on scheme, NTLM is still widely used in situations where a domain controller is not available or is unreachable. For example, NTLM would be used if a client is not Kerberos capable, the server is not joined to a domain, or the user is remotely authenticating over the web.
NTLM and Kerberos
Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains. Kerberos is typically used when a server belongs to a Windows Server domain, or if a trust relationship with a Windows Server Domain is established in some other way (such as Linux to Windows AD authentication).
NTLM is still used in the following situations:
- The client is authenticating to a server using an IP address
- The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust
- The client is authenticating to a server that doesn't belong to a domain
- No Active Directory domain exists (commonly referred to as "workgroup" or "peer-to-peer")
- Where a firewall would otherwise restrict the ports required by Kerberos (typically TCP 88)
In Windows Vista and above, neither LM nor NTLM are used by default. NTLM is still supported for inbound authentication, but for outbound authentication NTLMv2 is sent by default instead. Prior versions of Windows (back as far as Windows NT 4.0 Service Pack 4) could be configured to behave this way, but it was not the default.
NTLM is a challenge-response authentication protocol which uses three messages to authenticate a client in a connection oriented environment (connectionless is similar), and a fourth additional message if integrity is desired. First, the client establishes a network path to the server and sends a NEGOTIATE_MESSAGE advertising its capabilities. Next, the server responds with CHALLENGE_MESSAGE which is used to establish the identity of the client. Finally, the client responds to the challenge with an AUTHENTICATE_MESSAGE.
The NTLM protocol uses one or both of two hashed password values, both of which are also stored on the server (or domain controller), and which are password equivalent, meaning that if you grab the hash value from the server, you can authenticate without knowing the actual password. The two are the LM Hash (a DES-based function applied to the first 14 chars of the password converted to the traditional 8 bit PC charset for the language), and the NT Hash (MD4 of the little endian UTF-16 Unicode password). Both hash values are 16 bytes (128 bits) each.
The NTLM protocol also uses one of two one way functions, depending on the NTLM version. NT LanMan and NTLM version 1 use the DES based LanMan one way function (LMOWF), while NTLMv2 uses the NT MD4 based one way function (NTOWF).
The server authenticates the client by sending an 8-byte random number, the challenge. The client performs an operation involving the challenge and a secret shared between client and server, specifically one of the two password hashes described above. The client returns the 24-byte result of the computation. In fact, in NTLMv1 the computations are usually made using both hashes and both 24-byte results are sent. The server verifies that the client has computed the correct result, and from this infers possession of the secret, and hence the authenticity of the client.
Both the hashes produce 16-byte quantities. Five bytes of zeros are appended to obtain 21 bytes. The 21 bytes are separated in three 7-byte (56-bit) quantities. Each of these 56-bit quantities is used as a key to DES encrypt the 64 bit challenge. The three encryptions of the challenge are reunited to form the 24-byte response. Both the response using the LM hash and the NT hash are returned as the response, but this is configurable.
C = 8-byte server challenge, random K1 | K2 | K3 = NT-Hash | 5-bytes-0 R1 = DES(K1,C) | DES(K2,C) | DES(K3,C) K1 | K2 | K3 = LM-Hash | 5-bytes-0 R2 = DES(K1,C) | DES(K2,C) | DES(K3,C) response = R1 | R2
||This section may be confusing or unclear to readers. In particular, How come there is a shorter response if the server sends two 16-0bytes responses? It seems you refer to three responses: 1.the HMACMD5 of the server challenge , 2. a random client challenge, and 3. HMACMD5 of user and password. Please try to rephrase.. (December 2013)|
NTLMv2 sends two 16-byte responses to an 8-byte server challenge. The response is the HMAC-MD5 hash of the server challenge, a randomly generated client challenge, and an HMAC-MD5 hash of the user's password and other identifying information. The two responses differ in the format of the client challenge. The shorter response uses an 8-byte random value for this challenge. In order to verify the response, the server must receive as part of the response the client challenge. For this shorter response, the 8-byte client challenge appended to the 16-byte response makes a 24-byte package which is consistent with the 24-byte response format of the previous NTLMv1 protocol. In certain non-official documentation (e.g. DCE/RPC Over SMB, Leighton) this response is termed LMv2.
The second response sent by NTLMv2 uses a variable length client challenge which includes (1) the current time in NT Time format, (2) an 8-byte random value, (3) the domain name and (4) some standard format stuff. The response must include a copy of this client challenge, and is therefore variable length. In non-official documentation, this response is termed NTv2.
Both LMv2 and NTv2 hash the client and server challenge with the NT hash of the user's password and other identifying information. The exact formula is to begin with the NT Hash, which is stored in the SAM or AD, and continue to hash in, using HMAC-MD5, the username and domain name. In the box below, X stands for the fixed contents of a formatting field.
SC = 8-byte server challenge, random CC = 8-byte client challenge, random CC* = (X, time, CC, domain name) v2-Hash = HMAC-MD5(NT-Hash, user name, domain name) LMv2 = HMAC-MD5(v2-Hash, SC, CC) NTv2 = HMAC-MD5(v2-Hash, SC, CC*) response = LMv2 | CC | NTv2 | CC*
The NTLM2 Session protocol similar to MS-CHAPv2. It consists of authentication from NTLMv1 combined with session security from NTLMv2.
Briefly, the NTLMv1 algorithm is applied, except that an 8-byte client challenge is appended to the 8-byte server challenge and MD5 hashed. The least 8-byte half of the hash result is the challenge utilized in the NTLMv1 protocol. The client challenge is returned in one 24-byte slot of the response message, the 24-byte calculated response is returned in the other slot.
This is a strengthened form of NTLMv1 which maintains the ability to use existing Domain Controller infrastructure yet avoids a dictionary attack by a rogue server. For a fixed X, the server computes a table where location Y has value K such that Y=DES_K(X). Without the client participating in the choice of challenge, the server can send X, look up response Y in the table and get K. This attack can be made practical by using rainbow tables.
However, existing NTLMv1 infrastructure allows that the challenge/response pair is not verified by the server, but sent to a Domain Controller for verification. Using NTLM2 Session, this infrastructure continues to work if the server substitutes for the challenge the hash of the server and client challenges.
NTLMv1 Client<-Server: SC Client->Server: H(P,SC) Server->DomCntl: H(P,SC), SC Server<-DomCntl: yes or no NTLM2 Session Client<-Server: SC Client->Server: H(P,H'(SC,CC)), CC Server->DomCntl: H(P,H'(SC,CC)), H'(SC,CC) Server<-DomCntl: yes or no
NTLM is widely deployed, even on new systems, often for compatibility with older systems. But it remains vulnerable to a credentials forwarding attack, which is a variant on the reflection attack which was addressed by Microsoft security update MS08-068. Both attacks were discovered by Dominique Brezinski in 1997. For example, Metasploit can be used in many cases to obtain credentials from one machine which can be used to gain control of another machine.  The Squirtle toolkit can be used to leverage web site cross-site scripting attacks into attacks on nearby assets via NTLM.
In February 2010, Amplia Security discovered several flaws in the Windows implementation of the NTLM authentication mechanism which completely broke the security of the protocol allowing attackers to gain read/write access to files and remote code execution. One of the attacks presented included the ability to predict pseudo-random numbers/challenges/responses generated by the protocol. These flaws had been present in all versions of Windows for 17 years. The security advisory explaining the issues found included different fully working proof-of-concept exploits. All flaws were fixed by MS10-012.
- "Introduction", NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), retrieved 2010-08-15
- "Session Security Details", NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), retrieved 2010-08-15
- Takahashi, T (2009-12-17), "Reflecting on NTLM Reflection", FrequencyX Blog (IBM Internet System Security (ISS)), retrieved 2010-08-14
- How to enable NTLM 2 authentication, Support, Microsoft, 2007-01-25, retrieved 2010-08-14
- "Security Configuration", Microsoft Windows 2000 Security Hardening Guide, TechNet (Microsoft), retrieved 2010-08-14
- "Security Considerations for Implementers", NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), retrieved 2010-08-16
- "Microsoft NTLM", MSDN (Microsoft), retrieved 2010-08-15
- "Message Syntax | section 2.2", NT LAN Manager (NTLM) Authentication Protocol Specification (Microsoft), retrieved 2010-08-15
- "Connection-Oriented", NT LAN Manager (NTLM) Authentication Protocol Specification (22.214.171.124 ed.) (Microsoft), retrieved 2010-08-15
- "Connectionless", NT LAN Manager (NTLM) Authentication Protocol Specification (126.96.36.199 ed.) (Microsoft), retrieved 2010-08-15
- "NEGOTIATE_MESSAGE", NT LAN Manager (NTLM) Authentication Protocol Specification (188.8.131.52 ed.) (Microsoft), retrieved 2010-08-15
- "CHALLENGE_MESSAGE", NT LAN Manager (NTLM) Authentication Protocol Specification (184.108.40.206 ed.) (Microsoft), retrieved 2010-08-15
- "AUTHENTICATE_MESSAGE", NT LAN Manager (NTLM) Authentication Protocol Specification (220.127.116.11 ed.) (Microsoft), retrieved 2010-08-15
- "NTLM v1 Authentication", NT LAN Manager (NTLM) Authentication Protocol Specification (3.3.1 ed.) (Microsoft), retrieved 2010-08-15
- "NTLM v2 Authentication", NT LAN Manager (NTLM) Authentication Protocol Specification (3.3.1 ed.) (Microsoft), retrieved 2010-08-15
- What's New in Windows NT 4.0 Service Pack 4?
- Glass, Eric, "NTLM", Davenport, Source forge
- Varughese, Sam (February 2006). "Rainbow Cracking and Password Security". Palisade. Retrieved 2010-08-14.
- Chris Wysopal (2008-11-28). "Standing on Other’s Shoulders". Security Focus. Retrieved 2010-11-27.
- HD Moore. "MS08-068: Metasploit and SMB Relay".
- Kurt Grutzmacher (2008-08-08). "Nail the Coffin Shut, NTLM is Dead". Defcon 16.
- Hernan Ochoa and Agustin Azubel (2010-07-28). "Understanding the Windows SMB NTLM Weak Nonce vulnerability" (PDF). Blackhat USA 2010.
- Hernan Ochoa and Agustin Azubel. "Windows SMB NTLM Weak Nonce vulnerability Security Advisory".
- Online NTLM hash crack using Rainbow tables
- NT LAN Manager (NTLM) Authentication Protocol Specification
- Cntlm – NTLM, NTLMSR, NTLMv2 Authentication Proxy and Accelerator Personal HTTP(S) and SOCKS5 proxy for NTLM-unaware applications (Windows/Linux/UNIX)
- The NTLM Authentication Protocol and Security Support Provider A detailed analysis of the NTLM protocol.
- MSDN article explaining the protocol and that it has been renamed
- MSDN page on NTLM authentication
- Libntlm – a free implementation.
- NTLM Authorization Proxy Server software that allows users to authenticate via an MS Proxy Server.
- Installing NTLM authentication – NTLM set-up instructions for Samba and Midgard on Linux
- NTLM version 2 (NTLMv2) and the LMCompatibilityLevel setting that governs it
- Jespa – Java Active Directory Integration Full NTLM security service provider with server-side NETLOGON validation (commercial but free up to 25 users)
- ntlmv2-auth NTLMv2 API and Servlet Filter for Java
- Configuring an NTLM Proxy tunnel in corporate environments
- A ntlm message generator tool
- WAFFLE – Java/C# Windows Authentication Framework
- objectif-securite (Rainbow tables for ophcrack)