Hubbry Logo
NTLMNTLMMain
Open search
NTLM
Community hub
NTLM
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
NTLM
NTLM
NTLM
View on Wikipedia
from Wikipedia

In a Windows network, NT (New Technology) LAN Manager (NTLM) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users.[1][2][3] NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. Whether these protocols are used or can be used on a system, which is governed by Group Policy settings, for which different versions of Windows have different default settings.

NTLM passwords are considered weak because they can be brute-forced very easily with modern hardware.[4]

Protocol

[edit]

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.[5][6][7][8]

  1. First, the client establishes a network path to the server and sends a NEGOTIATE_MESSAGE advertising its capabilities.[9]
  2. Next, the server responds with CHALLENGE_MESSAGE which is used to establish the identity of the client.[10]
  3. Finally, the client responds to the challenge with an AUTHENTICATE_MESSAGE.[11]

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 through a lack of salting 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 characters 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.[12]

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).[12][13]

NTLMv1

[edit]

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 = NTLM-Hash | 5-bytes-0
response = DES(K1,C) | DES(K2,C) | DES(K3,C)

NTLMv2

[edit]

NTLMv2, introduced in Windows NT 4.0 SP4[14] (and natively supported in Windows 2000), is a challenge-response authentication protocol. It is intended as a cryptographically strengthened replacement for NTLMv1, enhancing NTLM security by hardening the protocol against many spoofing attacks and adding the ability for a server to authenticate to the client.[1][15][16]

NTLMv2 sends two responses to an 8-byte server challenge. Each response contains a 16-byte HMAC-MD5 hash of the server challenge, a fully/partially 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 (CC2 in the box below), (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, CC2, 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*

NTLM2 Session

[edit]

The NTLM2 Session protocol is similar to MS-CHAPv2.[17] 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.[18]

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

Availability and use of NTLM

[edit]

Since 2010, Microsoft no longer recommends NTLM in applications:[19]

Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy checks (CRC) or MD5 for integrity, and 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.

Despite these recommendations, NTLM is still widely deployed on systems.[citation needed] A major reason is to maintain compatibility with older systems. However, it can be avoided in some circumstances.[how?]

Microsoft has added the NTLM hash to its implementation of the Kerberos protocol to improve interoperability (in particular, the RC4-HMAC encryption type). According to an independent researcher, this design decision allows Domain Controllers to be tricked into issuing an attacker with a Kerberos ticket if the NTLM hash is known.[20] Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains.[16] Kerberos is typically used when a server belongs to a Windows Server domain. Microsoft recommends developers neither to use Kerberos nor the NTLM Security Support Provider (SSP) directly.[21]

Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

Use of the NTLM Security Support Provider

[edit]

The NTLM SSP is used in the following situations:

  • The client is authenticating to a server that doesn't belong to a domain or no Active Directory domain exists (commonly referred to as "workgroup" or "peer-to-peer")
    • The server must have the "password-protected sharing" feature enabled, which is not enabled by default and which is mutually exclusive with HomeGroup on some versions of Windows.
    • When server and client both belong to the same HomeGroup, a protocol similar to Kerberos, Public Key Cryptography based User to User Authentication will be used instead of NTLM.[22] HomeGroup is probably the easiest way to share resources on a small network, requiring minimal setup, even compared to configuring a few additional users to be able to use password-protected sharing, which may mean it is used much more than password-protected sharing on small networks and home networks.
  • If the server is a device that supports SMB, such as NAS devices and network printers, the NTLM SSP may offer the only supported authentication method. Some implementations of SMB or older distributions of e.g. Samba may cause Windows to negotiate NTLMv1 or even LM for outbound authentication with the SMB server, allowing the device to work although it may be loaded with outdated, insecure software regardless of whether it were a new device.
  • If the server is a member of a domain but Kerberos cannot be used.
    • The client is authenticating to a server using an IP address (and no reverse name resolution is available)
    • 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
    • Where a firewall would otherwise restrict the ports required by Kerberos (typically TCP 88)

Use of protocol versions

[edit]

After it has been decided either by the application developer or by the Negotiate SSP that the NTLM SSP be used for authentication, Group Policy dictates the ability to use each of the protocols that the NTLM SSP implements. There are five authentication levels.[23]

  • Send LM & NTLM responses: Clients use LM and NTLM authentication, and never use NTLMv2 session security; DCs accept LM, NTLM, and NTLMv2 authentication.
  • Send LM & NTLM - use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLM response only: Clients use NTLM authentication only, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLMv2 response only: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLMv2 response only\refuse LM: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs refuse LM (accept only NTLM and NTLMv2 authentication).
  • Send NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2 authentication only, and use NTLMv2 session security if server supports it; DCs refuse LM and NTLM (accept only NTLMv2 authentication).

DC would mean Domain Controller, but use of that term is confusing. Any computer acting as server and authenticating a user fulfills the role of DC in this context, for example a Windows computer with a local account such as Administrator when that account is used during a network logon.

Prior to Windows NT 4.0 Service Pack 4, the SSP would negotiate NTLMv1 and fall back to LM if the other machine did not support it.

Starting with Windows NT 4.0 Service Pack 4, the SSP would negotiate NTLMv2 Session whenever both client and server would support it.[24] Up to and including Windows XP, this used either 40- or 56-bit encryption on non-U.S. computers, since the United States had severe restrictions on the export of encryption technology at the time. Starting with Windows XP SP3, 128-bit encryption could be added by installing an update and on Windows 7, 128-bit encryption would be the default.

In Windows Vista and above, LM has been disabled for inbound authentication. Windows NT-based operating systems up through and including Windows Server 2003 store two password hashes, the LAN Manager (LM) hash and the Windows NT hash. Starting in Windows Vista, the capability to store both is there, but one is turned off by default. This means that LM authentication no longer works if the computer running Windows Vista acts as the server. 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.[25]

Weakness and vulnerabilities

[edit]

NTLM remains vulnerable to the pass the hash attack, which is a variant on the reflection attack which was addressed by Microsoft security update MS08-068. 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.[3][26] The Squirtle toolkit can be used to leverage web site cross-site scripting attacks into attacks on nearby assets via NTLM.[27]

In February 2010, Amplia Security discovered several flaws in the Windows implementation of the NTLM authentication mechanism which 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 and challenges/responses generated by the protocol. These flaws had been present in all versions of Windows for 17 years. The security advisory explaining these issues included fully working proof-of-concept exploits. All these flaws were fixed by MS10-012.[28][29]

In 2012, it was demonstrated that every possible 8-character NTLM password hash permutation can be cracked in under 6 hours.[30]

In 2019, this time was reduced to roughly 2.5 hours by using more modern hardware.[4][31] Also, Rainbow tables are available for eight- and nine-character NTLM passwords. Shorter passwords can be recovered by brute force methods.[32]

In 2019, EvilMog[33][34] published a tool called the ntlmv1-multitool[35] to format NTLMv1 challenge responses in a hashcat compatible cracking format. With hashcat and sufficient GPU power the NTLM hash can be derived using a known plaintext attack by cracking the DES keys with hashcat mode 14000 as demonstrated by atom[36] on the hashcat forums.

Note that the password-equivalent hashes used in pass-the-hash attacks and password cracking must first be "stolen" (such as by compromising a system with permissions sufficient to access hashes). Also, these hashes are not the same as the NTLMSSP_AUTH "hash" transmitted over the network during a conventional NTLM authentication.

Compatibility with Linux

[edit]

NTLM implementations for Linux include Cntlm[37] and winbind (part of Samba)[38] allow Linux applications to use NTLM proxies.

FreeBSD also supports storing passwords via Crypt (C) in the insecure NT-Hash form.[39]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

NTLM

View on Grokipedia
from Grokipedia
NTLM, or NT LAN Manager, is a suite of challenge-response authentication protocols developed by for use in Windows operating systems and networks, providing mechanisms for user and computer , message integrity, and session confidentiality without transmitting in clear text. It authenticates clients to servers by having the server issue a random challenge, which the client encrypts using a hash of the user's , allowing verification against a or local account database. Originally introduced with , NTLM has evolved through multiple versions but remains a legacy protocol, with Kerberos preferred for modern environments due to its stronger security features. The protocol family includes earlier variants like (LM) v1 and v2, which used weaker DES-based , and the more secure NTLM v1 and v2, with NTLMv2 incorporating enhanced hashing and to mitigate vulnerabilities such as offline brute-force attacks and replay/relay attacks, but remaining vulnerable to pass-the-hash attacks. NTLM operates within the Security Support Provider Interface (SSPI) framework, implemented via the MSV1_0.dll library, and is invoked when applications request the "Negotiate" package, which falls back to NTLM if Kerberos fails. It supports both local logons on standalone systems and network authentication in workgroups or domains, particularly for legacy or non-Microsoft applications that do not support Kerberos. Despite its widespread historical use, NTLM has known security weaknesses, including susceptibility to offline cracking and relay attacks, prompting to recommend auditing and restricting its usage through tools like NTLM audit policies and Extended Protection for Authentication. In recent developments, has deprecated NTLM, with NTLMv1 fully removed in version 24H2 and 2025, while NTLMv2 is no longer under active development but continues to function for . Administrators are encouraged to transition to Kerberos or other modern protocols to enhance , with ongoing support for NTLM limited to essential legacy scenarios.

Overview

Introduction

NTLM, or NT LAN Manager, is a suite of challenge-response authentication protocols developed by Microsoft for securing communications within Windows-based networks. It enables the authentication of users and computers without transmitting passwords directly over the network, instead relying on encrypted responses to server-generated challenges derived from password hashes. As a security package, NTLM provides core functions of authentication to verify identities, integrity to ensure data has not been tampered with, and confidentiality through optional session encryption. In ecosystems, NTLM plays a key role in facilitating secure access to resources, particularly in workgroup scenarios or on non-domain-joined systems where more modern protocols like Kerberos may not apply. It is commonly integrated with protocols such as (SMB) for file sharing, (RPC) for distributed services, and HTTP for web-based authentication, allowing seamless verification in heterogeneous or legacy setups. This integration supports remote user logons and protects network communications in environments like local area networks. Originating as an enhancement to the earlier authentication system, NTLM has evolved into versions including NTLMv1 and NTLMv2 to address security limitations. As of November 2025, it is a deprecated legacy protocol, with NTLMv1 removed in version 24H2 and 2025, and NTLMv2 no longer under active development but functional for . Despite recommendations to minimize its use in favor of Kerberos, NTLM continues to authenticate in specific legacy contexts.

History and Development

The NTLM authentication protocol originated from the (LM) authentication mechanism developed by in the late 1980s. , released in version 1.0 in 1987, was designed to provide network authentication for and OS/2-based systems using the (SMB) protocol over NetBEUI. This early protocol relied on weak challenge-response methods to secure and printer access in local area networks, but its design prioritized compatibility over robust security. Microsoft introduced NTLM with the release of in July 1993, positioning it as a significant upgrade to address the vulnerabilities in LM hashing, such as the use of a simplified DES-based encryption that limited passwords to 14 characters and upper-case only, making them susceptible to brute-force attacks. NTLM adopted stronger cryptographic elements, including the hashing algorithm for password storage and DES for key derivation in its challenge-response process, enabling better protection for domain and workgroup authentication in enterprise environments. These influences from DES and were chosen for their availability and performance on the hardware of the era, though they later contributed to ongoing security concerns. NTLM version 1 (NTLMv1) was introduced with and continued in subsequent versions. Optional support for NTLM version 2 (NTLMv2) was added in Service Pack 4 in 1998, incorporating enhanced session features while maintaining with earlier NT systems. To further bolster resistance against replay and offline attacks, NTLMv2 was introduced natively in in February 2000, replacing weaker DES operations with HMAC-MD5 for key generation and adding timestamping and elements. Microsoft's support for NTLM has evolved toward deprecation amid recommendations for more secure alternatives like Kerberos. Beginning in the early 2010s, Microsoft advised developers to avoid NTLM in new applications, citing its cryptographic weaknesses, and by 2018, official guidance urged the retirement of legacy variants like NTLMv1 through auditing and policy enforcement. Partial deprecation announcements continued into the 2020s, with tools introduced to block NTLM usage in Windows 7 and Server 2008 R2. In October 2023, Microsoft announced plans to deprecate all NTLM variants, followed by official deprecation in June 2024. As of November 2025, NTLMv1 is removed from Windows 11 version 24H2 and Windows Server 2025, while NTLMv2 remains available only for essential legacy compatibility but is no longer under active development.

Protocol Fundamentals

Message Types and Structure

The NTLM authentication protocol employs three primary message types exchanged between the client and server to establish a secure session: the Type 1 Negotiate message, the Type 2 Challenge message, and the Type 3 Authenticate message. These messages form the core of the protocol's handshake, with each type building upon the previous to negotiate capabilities and verify identity. The protocol specifies a binary format for all messages, using little-endian byte order for multi-byte values and supporting either OEM (ANSI) or Unicode (UTF-16LE) character encoding based on negotiation flags. All NTLM messages share a common fixed-length header consisting of an 8-byte ASCII signature "" followed by a 4-byte message type identifier. This header is immediately followed by variable-length sections, which include buffers for strings (such as domain and username) and other fields like flags and challenges. buffers are structured as 8-byte descriptors containing length, maximum length, and offset to the actual data, allowing flexible positioning of elements to optimize size and alignment. The may also include optional fields like version information if negotiated. The Type 1 Negotiate message (message type 0x00000001), sent from the client to the server, initiates the process by advertising the client's supported features. Its includes a 4-byte NegotiateFlags field specifying protocol options, followed by optional security buffers for the client's and workstation name (in OEM encoding by default). If the NTLMSSP_NEGOTIATE_VERSION flag is set, an 8-byte Version structure is appended, containing the protocol version, but this is typically zeroed otherwise. This message lacks any response data, focusing solely on capability negotiation. The Type 2 Challenge message (message type 0x00000002), sent from the server to the client, responds to the negotiation by confirming supported features and providing a challenge for . Its payload begins with an optional TargetName security buffer (8 bytes descriptor plus variable data) representing the server's realm, such as a domain or server name, encoded in the negotiated character set. This is followed by the 4-byte NegotiateFlags, an 8-byte ServerChallenge (a random 64-bit nonce generated by the server to prevent replay attacks), an 8-byte Reserved field (set to zero), and an optional TargetInfo security buffer. The TargetInfo block contains a sequence of attribute-value (AV) pairs, each prefixed by a 2-byte type identifier and 2-byte length, terminated by an MsvAvEOL (type 0x00) entry; these pairs may include details like channel bindings or timestamps for enhanced security context. A Version structure may follow if negotiated. The Type 3 Authenticate message (message type 0x00000003), sent from the client to the server, completes the by supplying proof of identity in response to the challenge. Its includes security buffers for the LM and NT challenge responses (each 8-byte descriptors plus 8- to 16-byte opaque response fields), domain name, username, and workstation name (encoded per ), followed by an optional SessionKey buffer (for if requested), the 4-byte NegotiateFlags, an optional TargetInfo buffer (echoing or extending the server's), and a Version structure if applicable. This message encapsulates the client's credentials indirectly through challenge-response mechanisms without transmitting passwords. Central to all messages are the NegotiateFlags, a 32-bit bitfield that dictates protocol behavior, such as , features, and target types. Key flags include NTLMSSP_NEGOTIATE_UNICODE (bit 0, 0x00000001), which requests UTF-16LE encoding for strings if set (mutually exclusive with NTLMSSP_NEGOTIATE_OEM, bit 1, 0x00000002); NTLMSSP_REQUEST_TARGET (bit 2, 0x00000004), requesting the server's target name; NTLMSSP_NEGOTIATE_SIGN (bit 4, 0x00000010) and NTLMSSP_NEGOTIATE_SEAL (bit 5, 0x00000020) for message signing and sealing; NTLMSSP_NEGOTIATE_KEY_EXCH (bit 26, 0x4000000), enabling explicit exchange in the Type 3 message; and NTLMSSP_NEGOTIATE_TARGET_INFO (bit 29, 0x20000000), indicating the presence of the TargetInfo block. Other flags specify target types (e.g., NTLMSSP_TARGET_TYPE_DOMAIN, bit 22, 0x00400000) or request version negotiation (NTLMSSP_NEGOTIATE_VERSION, bit 30, 0x40000000). Unused or reserved bits must be zero. The flags in Type 2 reflect the intersection of client requests and server capabilities.
Flag NameBit PositionValueDescription
NTLMSSP_NEGOTIATE_UNICODE00x00000001If set, strings use (UTF-16LE); otherwise, OEM encoding.
NTLMSSP_REQUEST_TARGET20x00000004Requests the server to include a TargetName in the Type 2 message.
NTLMSSP_NEGOTIATE_SIGN40x00000010Requests message integrity via signing.
NTLMSSP_NEGOTIATE_SEAL50x00000020Requests message confidentiality via sealing.
NTLMSSP_NEGOTIATE_KEY_EXCH260x4000000Requests the client to provide an encrypted in Type 3.
NTLMSSP_NEGOTIATE_TARGET_INFO290x20000000Indicates the TargetInfo block is present and populated.
NTLMSSP_NEGOTIATE_VERSION300x40000000Requests inclusion of the Version structure for protocol identification.
This table highlights representative flags that influence message structure and encoding, establishing the protocol's flexibility without delving into cryptographic details.

Authentication Mechanism

The NTLM authentication mechanism follows a three-phase challenge-response exchange consisting of the Type 1 Negotiate message from the client, the Type 2 Challenge message from the server, and the Type 3 Authenticate message from the client. The client initiates the process by sending the Type 1 message, which specifies negotiation flags for supported protocol features, including preferences and capabilities, using the OEM character set by default. The server then responds with the Type 2 message, which includes a random 8-byte nonce (the challenge) and its supported flags, enabling the client to compute an appropriate response. Finally, the client transmits the Type 3 message containing the challenge responses, , username, and workstation details, allowing the server to validate the authentication attempt. At its core, the challenge-response principle ensures secure authentication without exposing the user's password in . The server generates and sends the nonce to uniquely identify the session and resist replay attacks, while the client proves possession of the password by computing a response value based on the nonce and a function of the password-derived secret. The server independently computes the expected response using its copy of the user's credentials and compares it to the client's submission; a match confirms authenticity. This approach embeds NTLM messages within the packets of an underlying application protocol, such as SMB or HTTP, for transport. Following successful , both parties derive a shared from the password-based secret and elements exchanged during , including the challenge nonce. This key enables optional session security features, such as message signing for and (sealing) for in follow-on communications. Negotiation flags in the Type 1 and Type 2 messages dictate the for all string fields across the exchange; mutual support for the flag results in UTF-16 little-endian encoding, enhancing , whereas absence of this flag defaults to the OEM character set. The OEM fallback assumes an agreement on the specific between client and server to ensure compatibility. Error handling in NTLM negotiation primarily involves fallback mechanisms for mismatched flags, with the protocol defaulting to conservative options like OEM encoding when Unicode is not supported, rather than explicit error codes within the messages themselves. Any negotiation failures or invalid responses are typically propagated as errors by the hosting application protocol, prompting retries or alternative authentication paths if configured.

Protocol Versions

NTLMv1

NTLMv1, the original version of the NTLM authentication protocol, was introduced as the default mechanism in Windows NT 3.1 through Windows Server 2003, relying on DES-based LAN Manager (LM) hashes and NT hashes for challenge-response authentication. It employs weak cryptographic primitives, including DES for LM operations and MD4 for NT password hashing, which form the baseline for subsequent enhancements in later versions. In NTLMv1, the client computes two responses to the server's 8-byte random challenge: the LM response and the NT response. The LM response is derived from the LM one-way function (LMOWF), which processes the uppercase password (truncated to 14 characters, padded if shorter) by splitting it into two 7-byte halves. Each half is used as a DES key (with odd parity adjustment) to encrypt the fixed 8-byte magic string "KGS!@#$%", producing two 8-byte outputs that are concatenated to form the 16-byte ResponseKeyLM. To generate the 24-byte LM response, this key is padded with five zero bytes to 21 bytes, split into three 7-byte segments (each adjusted for odd parity), and each segment encrypts the 8-byte server challenge using DES, with the results concatenated. The NT response uses the NT one-way function (NTOWF), computed as the hash of the representation of the full , yielding a 16-byte ResponseKeyNT. Similar to the LM response, the 24-byte NT response is produced by padding ResponseKeyNT to 21 bytes with zeros, splitting into three 7-byte DES keys (with parity), and encrypting the server challenge three times, concatenating the outputs. If the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set (indicating NTLMv1 with session security), the NT response instead encrypts the first 8 bytes of an hash of the concatenated server challenge and an 8-byte client challenge. The LM response may be replaced with the client challenge padded to 24 bytes in this mode. The session base key in NTLMv1 is derived directly from the NTOWF by applying again, resulting in an 16-byte key used as the foundation for message signing and sealing operations. Signing employs this key (or a derived version) with DES or for integrity checks, while sealing uses encryption based on the key exchange key (typically the ResponseKeyNT or ResponseKeyLM, depending on available responses) to provide . These derivations enable limited session but expose the protocol to key compromise if responses are intercepted. NTLMv1 has inherent limitations that undermine its , including a fixed 8-byte challenge size that limits and facilitates precomputation attacks. It lacks , allowing servers to impersonate clients without verification, and omits timestamps or nonces, making it susceptible to replay attacks where captured responses can be reused. Additionally, the LM component's 14-character limit and DES usage severely weaken resistance to brute-force and attacks.

NTLMv2

NTLMv2, an enhanced version of the NTLM authentication protocol, was first made available via Service Pack 4 in 1997 and received native support in Windows 2000. It requires the client to set the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag (0x00080000) in the NEGOTIATE_MESSAGE to indicate support, which the server echoes back in the CHALLENGE_MESSAGE if compatible. This version addresses vulnerabilities in NTLMv1 by incorporating stronger , including HMAC-MD5 for key derivation and response generation, replacing the weaker DES-based computations. The core of NTLMv2 authentication lies in its response structure, computed during the AUTHENTICATE_MESSAGE. The NTLMv2 hash, serving as the effective password hash, is derived as follows:

NTLMv2_Hash = HMAC-MD5(NT_Hash, UNICODE(Uppercase(Username) + Domain))

NTLMv2_Hash = HMAC-MD5(NT_Hash, UNICODE(Uppercase(Username) + Domain))

where NT_Hash is the MD4 hash of the Unicode password, and Username and Domain are concatenated after uppercasing only the username. The NTLMv2 response then combines a proof string with a challenge structure (blob). The proof string (NTProofStr) is:

NTProofStr = HMAC-MD5(NTLMv2_Hash, ServerChallenge + Temp)

NTProofStr = HMAC-MD5(NTLMv2_Hash, ServerChallenge + Temp)

Here, ServerChallenge is the 8-byte challenge from the server, and Temp is a including a 1-byte response version (0x01), a 1-byte high response version (0x01), 6 zero bytes, an 8-byte client-generated (in FILETIME format), an 8-byte client nonce (client challenge), 4 zero bytes, the target information (AV pairs provided by the server), and 4 trailing zero bytes. The full response is NTProofStr concatenated with Temp, ensuring the proof binds to the dynamic elements without revealing the hash. This structure approximates HMAC-MD5(NT_Hash, Uppercase(Username) || ClientChallenge || Blob), where Blob encapsulates the timestamp and target AV pairs for contextual binding. The client challenge, an 8-byte random nonce, and the provide mutual elements and replay protection; the server verifies the 's recency and the client's knowledge of the challenge, while the target (e.g., server name, domain) ties the response to the specific . For session , the session base key is derived as:

SessionBaseKey = HMAC-MD5(NTLMv2_Hash, NTProofStr)

SessionBaseKey = HMAC-MD5(NTLMv2_Hash, NTProofStr)

This key enables stronger message signing using HMAC-MD5 (with sequence numbers for ) and sealing via (with keys derived from the session base key), offering improved against modification and compared to NTLMv1's weaker mechanisms.

NTLM2 Session Security

NTLM2 session , also known as extended session , is an optional layer added to NTLMv1 to provide message through signing and confidentiality through sealing, without altering the core process of NTLMv1. It is negotiated in the NTLM NEGOTIATE_MESSAGE via the NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY (0x00080000), which enables the use of stronger key derivation for session , and often in conjunction with the NTLMSSP_NEGOTIATE_LM_KEY (0x00000080) to utilize the LM key for during . This mechanism operates in a half-duplex mode when using NTLMv1, meaning signing and sealing alternate directions rather than supporting full-duplex simultaneously. The key exchange process begins with the client generating a random 16-byte ExportedSessionKey upon receiving the CHALLENGE_MESSAGE. To securely share this key with the server, the client encrypts the first 8 bytes of the ExportedSessionKey using the LM session key—derived from the client's LM hash truncated to 8 bytes for DES encryption—and includes the resulting 8-byte in the EncryptedRandomSessionKey field of the AUTHENTICATE_MESSAGE. The server, possessing the same LM session key from the verified LM challenge response, decrypts this field to recover the first 8 bytes; the full 16-byte is then reconstructed by appending 8 zero bytes to these decrypted bytes if necessary, though in practice, the random generation ensures the full key's entropy. This approach leverages the shared LM key without requiring NTLMv2's enhanced challenge-response computations. Message signing for integrity uses a derived signing key based on the ExportedSessionKey. The client-to-server signing key (ClientSignKey) is computed as the MD5 hash of the ExportedSessionKey concatenated with the magic constant "session key to client-to-server signing key magic constant" (a 20-byte ASCII string). ClientSignKey=MD5(ExportedSessionKey∥"session key to client-to-server signing key magic constant")\text{ClientSignKey} = \text{MD5}(\text{ExportedSessionKey} \parallel \text{"session key to client-to-server signing key magic constant"}) The server-to-client signing key is derived analogously using "session key to server-to-client signing key magic constant". Signing involves computing a 16-byte (MAC) by DES-encrypting a sequence number and buffer with keys derived from the signing key, ensuring tamper detection for subsequent protocol messages. For confidentiality, sealing employs encryption with a derived sealing key. The sealing key (SealKey) depends on negotiated key strengths: if NTLMSSP_NEGOTIATE_128 (0x20000000) is set, SealKey is the full 16-byte ExportedSessionKey; for NTLMSSP_NEGOTIATE_56 (0x8000000), it uses the first 7 bytes plus parity for a 56-bit effective key; otherwise, the first 5 bytes are used for 40-bit. This base is then processed with using mode-specific magic constants, such as "session key to client-to-server sealing key magic constant" for client-side operations. ClientSealKey=MD5(ExportedSessionKey∥"session key to client-to-server sealing key magic constant")\text{ClientSealKey} = \text{MD5}(\text{ExportedSessionKey} \parallel \text{"session key to client-to-server sealing key magic constant"}) Encryption reinitializes the state with this SealKey and a per-message sequence number to handle potential in connectionless modes. This session security enhances NTLMv1 compatibility by adding protections atop legacy authentication, commonly implemented in older Windows versions (e.g., SP4 and later) for protocols like SMB to enable signing without mandating NTLMv2's full protocol upgrade. It supports anonymous or guest logons only without security, disabling signing and sealing in those cases to prevent exposure.

Implementation and Usage

NTLM Security Support Provider

The NTLM Security Support Provider (SSP), implemented in the msv1_0.dll , serves as a core component within the Windows Security Support Provider Interface (SSPI) framework, enabling , , and services for distributed applications. It operates as a security package that the Local Security Authority (LSA) loads by default, allowing protocols to perform challenge-response without direct access to underlying credentials or session keys. Initialization of the NTLM SSP begins with the AcquireCredentialsHandle function, which obtains a handle to the credentials of a principal, such as a logged-on user, for subsequent operations. This handle is then used in calls to InitializeSecurityContext on the client side or AcceptSecurityContext on the server side to iteratively build a context through token exchanges, establishing and optional session features like signing and . The NTLM SSP integrates seamlessly into Windows protocols via SSPI calls, providing a protocol-agnostic interface for secure communications; for example, it supports authentication in (SMB) for , HTTP Negotiate for web access, and (RPC) or (DCOM) services. Configuration of the NTLM SSP occurs through registry settings under the HKLM\SYSTEM\CurrentControlSet\Control\Lsa key, where administrators can adjust SSP ordering, enable restrictions on NTLM usage, and specify parameters like minimum session security levels via subkeys such as MSV1_0. In environments where Kerberos authentication is unavailable or fails, such as in workgroup configurations or non-domain-joined scenarios, the NTLM SSP acts as the default fallback mechanism to ensure compatibility and continued access. It supports both NTLMv1 and NTLMv2 protocols within this framework.

Version Deployment and Availability

NTLMv1, introduced as the initial version of the protocol, was deployed in early Windows operating systems including through , where it served as the primary authentication mechanism for domain and local logons. However, due to its security limitations, NTLMv1 support became legacy in subsequent releases; it was disabled by default starting with and , though it remained available for until its removal in version 24H2 and Windows Server 2025. In contrast, NTLMv2 has been the default authentication variant since , with native support added in that OS and retrofitted to via 4; and later versions enforce NTLMv2 responses by default for enhanced session security, requiring it for features like certain remote desktop connections and protocols. NTLMv1 continues to be available in and for compatibility, but has been removed from version 24H2 and Windows Server 2025. NTLMv2 remains available across , (including 24H2), and , integrated through the NTLM Support Provider (SSP), though administrators can restrict usage via policy settings. In practical deployment, NTLM serves primarily as a fallback mechanism when Kerberos authentication fails, such as in intra-domain scenarios where domain controllers are unreachable or misconfigured. It is commonly used for extranet HTTP in web applications employing the Negotiate protocol, particularly in mixed-trust environments without full Kerberos ticket-granting support. Legacy SMB shares also rely on NTLM for client-server in workgroup configurations or when accessing older file servers, ensuring compatibility with pre-Active Directory systems. Negotiation between NTLM versions occurs during the initial handshake, influenced by server-side policies; for instance, the setting "Network security: authentication level" allows administrators to mandate NTLMv2 only (e.g., by selecting "Send NTLMv2 response only. Refuse LM & NTLM"), blocking weaker variants like NTLMv1 and enforcing stronger across domain-joined devices. As of November 2025, NTLMv2 remains enabled by default in , (including version 24H2), and to support legacy applications and devices, but its use is increasingly restricted in modern infrastructures. In cloud environments like Azure (Azure AD), NTLM is largely unsupported for services such as Azure Files, where authentication falls back to Kerberos or identity-based methods, prompting hybrid setups to migrate away from it. Usage has declined significantly since 2010, driven by Microsoft's preference for Kerberos in domains and ongoing deprecation efforts, yet NTLM persists in air-gapped networks isolated from domain infrastructure and mixed environments with legacy hardware, where full Kerberos deployment is impractical.

Deprecation and Modern Alternatives

Microsoft has pursued the deprecation of NTLM through a series of milestones aimed at reducing its usage and eventually eliminating it from Windows environments. Auditing and restriction policies for NTLM were first introduced in and , allowing administrators to monitor and limit NTLM authentication traffic. These capabilities were expanded in subsequent versions, with enhanced auditing features becoming available in and later. In June 2024, officially deprecated all versions of NTLM, announcing that it is no longer under active development. For version 24H2 and 2025, NTLMv1 was removed entirely, with default auditing of NTLMv1 usage enabled starting in late August 2025 for version 24H2 clients and the rollout of 2025 beginning in November 2025, culminating in a default block of NTLMv1 via update in October 2026. Full disablement options for NTLM, including NTLMv2, are configurable through and registry settings in [Windows 11](/page/Windows 11), enabling organizations to prohibit NTLM authentication domain-wide. The primary reasons for deprecating NTLM include its persistent vulnerabilities, such as susceptibility to attacks and pass-the-hash exploits, which undermine modern architectures. Additionally, NTLM is incompatible with zero-trust models due to its lack of , absence of certificate-based validation, and reliance on weaker challenge-response mechanisms that do not align with contemporary requirements for explicit verification at every access point. As the primary alternative, recommends Kerberos, a ticket-based protocol that provides and is the default in environments since Windows 2000. For transport-layer , TLS (particularly TLS 1.3) should be used to encrypt communications, such as in LDAPS or , replacing NTLM's insecure fallback role. In web and cloud scenarios, OAuth 2.0 with JWT tokens via offers scalable, token-based authorization without NTLM's limitations. To facilitate the transition, provides tools like Windows Local Administrator Password Solution (LAPS), which automates the randomization and secure management of local administrator passwords, reducing reliance on domain credentials that might trigger NTLM in lateral movement scenarios. For (RDP) sessions, Restricted Admin mode prevents the forwarding and storage of domain credentials on remote systems, mitigating NTLM-related risks by enforcing network-level logons and limiting exposure during administrative access. Looking ahead, plans a phased elimination of NTLM support, with mandatory disabling in Microsoft Entra Domain Services as a already, and broader enforcement expected across Azure and hybrid environments by mid-2026 to align with zero-trust principles.

Security Analysis

Known Vulnerabilities

One of the most prominent vulnerabilities in NTLM is the Pass-the-Hash (PtH) attack, which enables adversaries to reuse stolen NTLM password hashes to authenticate to remote systems without knowledge of the password. This technique exploits the design of NTLM, where hashes serve as proof of identity in challenge-response exchanges, and has been feasible since NTLMv1 due to the static nature of the hashes until password changes occur. Tools like facilitate PtH by extracting NTLM hashes from LSASS process memory, allowing lateral movement across Windows networks. NTLM relay attacks represent another critical flaw, where an attacker intercepts authentication messages and forwards them to target services like SMB or RDP to impersonate the victim. These attacks thrive on NTLM's lack of inherent and are especially potent against NTLMv1, as it does not enforce message signing, though partial mitigations exist via SMB signing requirements. Even in NTLMv2, remains viable if signing is disabled or bypassed, enabling or unauthorized access. Recent analyses as of 2025 highlight a "" in NTLM techniques, including low-privilege HTTP-to-LDAP relaying and bypasses of default protections in services like Exchange and AD CS. A specific tampering in NTLMv2, identified as CVE-2019-1040, allows man-in-the-middle attackers to bypass the Message Integrity Code (MIC) protection, enabling modification of messages without detection. This flaw, exploitable over HTTP, leverages weaknesses in PKCS#7 padding validation to recover hashes or alter fields like target information, facilitating advanced relay scenarios and remote code execution in affected Windows versions. Version-specific weaknesses exacerbate NTLM's risks: in NTLMv1, the LM hash's reliance on DES encryption permits efficient attacks, as the 56-bit key length and password splitting into uppercase 7-character halves allow precomputed lookups for millions of common passwords in seconds using modern hardware. For NTLMv2, weak server nonce generation in SMB implementations enables prediction attacks, including replay of timestamped responses if the attacker's knowledge of system time allows simulation of valid challenges. Historical CVEs highlight early NTLM flaws, such as those enabling LM downgrades where attackers force fallback to the weaker LM/NTLMv1 protocol, exposing systems to brute-force cracking. Additionally, MS08-068 addressed SMB vulnerabilities tied to NTLM credential reflection, allowing remote code execution via relayed authentication without valid credentials. In 2025, several new NTLM vulnerabilities were disclosed and patched by , underscoring ongoing risks despite deprecation efforts. CVE-2025-24054 involves NTLM hash disclosure via spoofing, allowing attackers to capture NTLMv2 hashes with minimal user interaction and was exploited in the wild prior to its March 2025 patch. CVE-2025-54918 enables over the network due to improper in Windows NTLM. Additionally, CVE-2025-59214 is a zero-click leak that bypasses prior patches, exposing NTLM hashes on fully updated systems as of October 2025.

Mitigation and Best Practices

To mitigate risks associated with NTLM authentication, organizations should implement Group Policy Objects (GPOs) to restrict its use, starting with auditing to assess dependency before enforcement. The "Network security: Restrict NTLM: Audit NTLM authentication in this domain" policy, located under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options, enables logging of all NTLM authentication attempts on domain controllers without blocking them, allowing administrators to identify reliant applications and services. Similarly, the "Network security: Restrict NTLM: Audit incoming NTLM traffic" policy audits incoming NTLM traffic from clients and member servers, while the "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" policy audits or denies outbound NTLM attempts to prevent credential exposure. Once audited, these can be escalated to "Deny all" modes to block NTLM domain-wide or for specific traffic directions, with exceptions added via the "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication" policy for legacy systems. For finer control, registry modifications provide direct disablement options. Setting the DWORD value RestrictReceivingNTLMTraffic to 2 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 denies all incoming NTLM traffic to the local server, while RestrictSendingNTLMTraffic=2 under the same path blocks outgoing NTLM to remote servers. These changes correspond to the deny options in the aforementioned GPOs and should be tested in non-production environments to avoid disrupting compatible applications. Monitoring can be enhanced by reviewing Event ID 4624 in the Security event log, where the "Authentication Package" field lists "NTLM" for NTLM-based logons, providing visibility into usage patterns. Best practices emphasize transitioning away from NTLM toward stronger protocols while layering defenses. Enforce Kerberos authentication by configuring the "Network security: LAN Manager authentication level" GPO to "Send NTLMv2 response only. Refuse LM & NTLM," which rejects weaker NTLM variants and prompts fallback to Kerberos where possible. For HTTP-based services, enable Extended Protection for Authentication (EPA) to bind NTLM credentials to the TLS channel, mitigating man-in-the-middle relay attacks; this is configurable via IIS settings or application-specific policies like in Exchange Server. On file shares, require SMB 3.0 signing and encryption through GPOs such as "Microsoft network client: Digitally sign communications (always)" and ": Server SPN target name validation level," which prevent NTLM relay by verifying message integrity and encrypting traffic. Additionally, rotate user credentials frequently—ideally every 90 days or less—to limit the window for offline attacks on captured NTLM hashes, combined with enforcing complex password policies. Tools like Microsoft Defender for Identity provide automated monitoring by analyzing NTLM traffic for anomalies, such as relay attempts, and generating alerts based on event logs from domain controllers. Third-party tools, including from SpecterOps, enable attack path analysis to visualize NTLM-dependent routes, helping prioritize remediation. For testing NTLM reliance, deploy auditing scripts like those in to parse Event ID 4624 logs and enumerate NTLM usage across the environment, or use built-in GPO auditing to simulate blocks and measure impact before full deployment.

Cross-Platform Compatibility

Integration with Linux and Unix

Samba provides comprehensive support for NTLMv1 and NTLMv2 authentication in its smbclient tool and smbd/nmbd server daemons on and Unix systems, enabling interoperability with Windows networks for file and print sharing via the SMB/CIFS protocol. This support originated in early Samba releases, with encrypted password authentication (enabling NTLM over LM) becoming the default in version 3.0.0 released in 2003, and NTLMv2 handling refined in subsequent versions to match Windows behaviors. Configuration of NTLM in is managed through the smb.conf file, where parameters control versions and compatibility. For instance, setting ntlm auth = yes allows the server to accept NTLMv1 alongside NTLMv2, though this is deprecated in Samba 4.13 and later due to security concerns; the default is now restricted to NTLMv2 via . On the client side, client ntlmv2 auth = yes (default since Samba 3.0) enforces NTLMv2 usage in tools like smbclient, disabling weaker NTLMv1 and LANMAN variants. These settings ensure secure negotiation while supporting legacy environments. In Active Directory-integrated setups, Samba's Winbind daemon facilitates domain user authentication on /Unix hosts, preferring Kerberos for modern clients but falling back to NTLM for legacy Windows systems unable to use Kerberos tickets. Winbind integrates with PAM and NSS for seamless user mapping, allowing NTLM-only authentication in mixed-domain scenarios where Kerberos is unavailable. This fallback is configured via smb.conf security modes like security = ads and Winbind options in /etc/nsswitch.conf. Key utilities for NTLM operations include ntlm_auth, a helper program for verifying NTLM credentials against domain backends like Winbind or tdbsam, often used in proxy or custom scripts. For mounting SMB shares with NTLM, the cifs-utils package provides mount.cifs, supporting options like sec=ntlm or sec=ntlmv2 to specify authentication types during filesystem mounts. These tools enable testing and practical use of NTLM in non-Windows environments. Challenges in NTLM integration on /Unix include differences in string handling compared to Windows, where NTLM expects UTF-16 encoding; mismatches can lead to failures with non-ASCII usernames or passwords unless properly configured via client charset options in smb.conf. Additionally, in mixed Windows- networks, NTLM's susceptibility to relay attacks persists if signing is not enforced, as attackers can intercept and reuse credentials across SMB connections.

Support in Other Operating Systems

macOS provides native support for NTLMv2 authentication through its SMB implementation, enabling secure over SMB. This support integrates with the system's for credential storage and management, allowing users to authenticate to Windows-based SMB shares without repeated prompts. For instance, macOS clients can negotiate NTLMv2 sessions with servers supporting SMB2 and higher, ensuring compatibility in mixed environments while favoring Kerberos when available. On mobile platforms, NTLM support is limited and primarily occurs through enterprise (MDM) configurations for authentication. In and , configuration profiles can enable NTLM-based methods like MSCHAPv2 within EAP-PEAP for enterprise networks, though this is typically restricted to supervised devices in corporate settings. Similarly, Android Enterprise allows NTLM via MDM-deployed profiles using EAP methods that rely on NTLM hashes, such as for connecting to legacy Active Directory-integrated networks. However, both platforms discourage direct NTLM use in applications due to concerns, recommending certificate-based alternatives like EAP-TLS instead. Embedded and IoT systems often incorporate NTLM for legacy compatibility, particularly in printing and scanning devices. For example, HP JetDirect-enabled printers support NTLM authentication for IPP and SMB-based workflows, such as scanning to network folders on Windows shares, though many older models are limited to NTLMv1 due to hardware constraints. With the removal of NTLMv1 support in Windows 11 version 24H2 and Windows Server 2025, these older NTLMv1-limited devices may face compatibility issues with newer Windows clients unless upgraded or configured to use NTLMv2 or alternative protocols. This enables interoperability with enterprise print servers but requires careful configuration to avoid exposing weaker authentication variants. Third-party systems extend NTLM support through specialized integrations. Cisco Identity Services Engine (ISE) utilizes NTLM, particularly NTLMv1 via MSCHAPv2, for supplicant authentication in network access control scenarios, allowing seamless integration with for 802.1X environments. includes native NTLM authentication in its SMB services, configurable via properties like lm-compatibility-level to handle NTLMv1 and v2 sessions with Windows domains. Earlier implementations relied on Sun ports for additional tools like ntlm_auth, but modern Solaris versions provide built-in support. Interoperability challenges with NTLM, especially v2, frequently arise from in validation, where discrepancies exceeding five minutes between client and server clocks can cause failures. Additionally, message parsing issues stem from NTLM's little-endian byte order, leading to errors in non-Windows implementations that fail to correctly interpret flags or offsets without proper handling. These problems underscore the need for synchronized time sources and endianness-aware protocol stacks in cross-platform deployments.

References

  1. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4
  2. https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview
  3. https://learn.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm
  4. https://www.varonis.com/blog/closer-look-pass-hash-part-iii-ntlm-will-get-hacked
  5. https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server
  6. https://support.microsoft.com/en-us/topic/upcoming-changes-to-ntlmv1-in-windows-11-version-24h2-and-windows-server-2025-c0554217-cdbc-420f-b47c-e02b2db49b2e
  7. https://help.fdos.org/en/hhstndrd/network/history.htm
  8. https://download.microsoft.com/download/0/3/4/034A8114-5DA1-4C65-8581-C48EDD189437/%5BMS-FSSO%5D.pdf
  9. https://support.microsoft.com/en-us/topic/security-guidance-for-ntlmv1-and-lm-network-authentication-da2168b6-4a31-0088-fb03-f081acde6e73
  10. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/464551a8-9fc4-428e-b3d3-bc5bfb2e73a5
  11. https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/ntlm-user-authentication
  12. https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-ntlm-2-authentication
  13. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/5e550938-91d4-459f-b67d-75d70009e3f3
  14. https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/retire-those-old-legacy-protocols/259396
  15. https://techcommunity.microsoft.com/blog/windowsitproblog/the-evolution-of-windows-authentication/3926848
  16. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/907f519d-6217-45b1-b421-dca10fc8af0d
  17. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b34032e5-3aae-4bc6-84c3-c6d80eadf7f2
  18. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/99d90ff4-957f-4c8a-80e4-5bfe5a9a9832
  19. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/801a4681-8809-4be9-ab0d-61dcfe762786
  20. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/83f5e789-660d-4781-8491-5f8c6641f75e
  21. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/033d32cc-88f9-4483-9bf2-b273055038ce
  22. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/c50a85f0-5940-42d8-9e82-ed206902e919
  23. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/d1c86e81-eb66-47fd-8a6f-970050121347
  24. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/d86303b5-b29e-4fb9-b119-77579c761370
  25. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/524cdccb-563e-4793-92b0-7bc321fce096
  26. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/bf39181d-e95d-40d7-a740-ab4ec3dc363d
  27. https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/security-support-provider-interface-architecture
  28. https://learn.microsoft.com/en-us/windows/win32/secauthn/using-security-packages
  29. https://learn.microsoft.com/en-us/windows/win32/secauthn/acquirecredentialshandle--ntlm
  30. https://learn.microsoft.com/en-us/windows/win32/secauthn/initializesecuritycontext--ntlm
  31. https://learn.microsoft.com/en-us/windows/win32/secauthn/acceptsecuritycontext--ntlm
  32. https://learn.microsoft.com/en-us/azure/storage/files/files-smb-protocol
  33. https://www.microsoft.com/en-us/download/details.aspx?id=36036
  34. https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=HackTool:Win32/Mimikatz.I
  35. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-to-configure-protected-accounts
  36. https://www.microsoft.com/en-us/msrc/blog/2024/12/mitigating-ntlm-relay-attacks-by-default
  37. https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429
  38. https://posts.specterops.io/the-renaissance-of-ntlm-relay-attacks-everything-you-need-to-know-abfc3677c34e
  39. https://nvd.nist.gov/vuln/detail/CVE-2019-1040
  40. https://www.cve.org/CVERecord?id=CVE-2019-1040
  41. https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/prevent-windows-store-lm-hash-password
  42. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change
  43. http://media.blackhat.com/bh-us-10/presentations/Ochoa_Azubel/BlackHat-USA-2010-Ochoa-Azubel-NTLM-Weak-Nonce-slides.pdf
  44. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level
  45. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-068
  46. https://nvd.nist.gov/vuln/detail/CVE-2025-24054
  47. https://www.cve.org/CVERecord?id=CVE-2025-54918
  48. https://cymulate.com/blog/ntlm-leak-cve-2025-59214/
  49. https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
  50. https://www.samba.org/samba/docs/current/man-html/ntlm_auth.1.html
  51. https://learn.microsoft.com/en-us/intune/intune-service/configuration/wi-fi-settings-ios
  52. https://developer.android.com/guide/topics/connectivity/wifi-enterprise
  53. https://www.securew2.com/blog/complete-guide-to-android-802-1x
  54. https://h30434.www3.hp.com/t5/Printers-Archive-Read-Only/When-authenticating-to-a-Windows-share-for-network-scans/td-p/5125618
  55. https://community.cisco.com/t5/network-access-control/cisco-ise-3-1-patch3-speaks-with-active-directory-using-ntlmv1/td-p/4667092
  56. https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-smb/managing-smb-configuration-properties.html
  57. https://docs.oracle.com/cd/E88353_01/html/E37839/ntlm_auth-1.html
  58. https://success.skyhighsecurity.com/Knowledge_Base_-_Support/Skyhigh_Security_Secure_Web_Gateway_%28SWG%29/SWG_%28On-Prem%29/Troubleshooting_NTLM
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.