Offsec AD (Part 5) : NTLM Authentication & Network Analysis

• NTLM (NT LAN Manager)
• Difference between NT, LM and NTLM
• Working Mechanism of NTLM Authentication
• NTLM Authentication via NTLMSSP
• Packet Analysis of NTLM Authentication
  • Type 1 (Negotiate) Packet
  • Type 2 (Challenge) Packet
  • Type 3 (Authenticate) Packet
• References
• Conclusion

NTLM (NT LAN Manager)

NTLM, short for NT LAN Manager, is an authentication protocol initially introduced in Windows NT 3.1 and continues to be supported in modern Windows versions for backward compatibility over Kerberos. It operates on a challenge-response mechanism, where the client and server engage in a series of handshakes to verify the client's identity. NTLM uses three distinct stages for authentication: Negotiation, Challenge, and Authentication. While NTLM is widely used, it is less secure compared to modern alternatives like Kerberos.

To refer more on NTLM protocol

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/

NTLM authentication is preferred over Kerberos in certain scenarios due to specific limitations or requirements. While Kerberos is generally the recommended authentication protocol for Windows-based networks, there are situations where NTLM may be more suitable:

1. Compatibility: NTLM is preferred in environments with non-Windows systems or legacy applications that do not support Kerberos. Kerberos requires all participating systems to be part of an Active Directory domain, and if that's not feasible, NTLM can be used for authentication.

2. External Trusts: In scenarios where there are external trusts between domains or forests, NTLM might be preferred, as Kerberos cannot traverse these trust relationships directly.

3. Mixed Environments: In heterogeneous environments where different operating systems and directory services are present, NTLM might be chosen due to its broader compatibility across platforms.

4. Certain Applications: Some applications or services have specific requirements that work better with NTLM authentication or have limited support for Kerberos. In such cases, NTLM might be the only viable option.

Difference between NT, LM and NTLM

Before we get deep into NTLM, I assure most of you would have some ambigious doubts over NT hash, LM hash, NTLM hash and Net-NTLM hash. You would have came across questions like "Are they same ?", "Aren't NTLM an another naming convention of NT ?" etc. NT, LM, and NTLM are different authentication protocols used in Windows operating systems for user authentication. But their hashes are called with different naming convention. To clarify this we will see about those three hashes and their use cases.

LAN Manager hash (aka LM hash) : LM, which stands for LAN Manager, is an old and now deprecated authentication protocol used in early versions of Windows, specifically Windows NT and Windows 95/98. It is based on a weak hashing algorithm that breaks the user's password into two uppercase 7-character halves of 14-character padded data and then DES encrypts each half separately. Due to its vulnerability to brute-force attacks, LM authentication is considered highly insecure and is no longer recommended or used in modern Windows systems. LM was turned off by default starting in Windows Vista/Server 2008.

NT Hash (aka NTLM hash) : NT is not an authentication protocol on its own, but rather it refers to the password hashing algorithm used in Windows NT-based systems (Windows NT, Windows 2000, Windows XP, etc.). When a user sets a password, Windows stores a hashed version of the password using the NT hashing algorithm. This hash can be obtained from the SAM hive on a Windows system, or the NTDS database on the Domain Controller. During the authentication process, the user's password is hashed again, and the resulting hash is compared to the stored NT hash to verify the user's identity. Since the NT hash is a one-way hash, it cannot be reversed to reveal the original password.

┌──(kali㉿kali)-[~/pwnersLab/pwner-desk2]
└─$ impacket-secretsdump local -sam sam -system system 
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] Target system bootKey: 0x13e37ffa21a4712b01ce7e8e4b250dc2
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:e2aafc937fe68c5c5af06429ad09feec:::
pwner.bravo:1001:aad3b435b51404eeaad3b435b51404ee:f82023dde118832a6c988ea81ac00719:::
                 <------------------------------> <------------------------------>
                                   |                           |
LM hash ----------------------------                           --------------------------- NT Hash
[*] Cleaning up... 

NOTE: You might see the same LM hash value for all Domain Users as well as Local Users, because the LM has not been generated by default. The hash above indicates that there is no LM hash for that user, but that there is an NTLM hash. Typically if you see lots of “404ee” at the end of the LM part you are up against a Windows 2008 (or later) domain which never required backwards compatibility. This is because LM hashes are very easy to crack and are now considered obsolete. For this reason they are disabled by default in newer installations. The file format still has them for backwards compatibility.

NTLMv1/v2 (NT LAN Manager v1/v2 aka Net-NTLM-v1/Net-NTLM-v2) : NTLM, short for NT LAN Manager, is an updated version of the LAN Manager authentication protocol. It provides enhanced security compared to LM and is still supported in modern Windows versions primarily for backward compatibility purposes over Kerberos. NTLM uses a challenge-response mechanism, where the client and server exchange messages to authenticate the user. Although NTLM is more secure than LM, it is still considered relatively weak compared to more modern authentication protocols like Kerberos.

NT Hash === NTLM Hash
NTLMv1/NTLMv2/Net-NTLMv1/Net-NTLMv2 Hash === Response generated for NTLM authentication
NTLM Hash !== NTLMv1/NTLMv2/Net-NTLMv1/Net-NTLMv2 Hash

Be clear we are going to discuss about NetNTLM v1/v2 hashes and its authentication protocol named NTLM. The naming convention would still confuse you a bit, but try hard to understand it. But still It's a good practice to always refer NTLM Hash as NT Hash.

Working Mechanism of NTLM Authentication

NTLM credentials are based on data obtained during the interaction based logon process while interacting with the specific service and consist of the respective domain name, user name, and a one-way hash of the user's password (NTLM hash). NTLM employs an encrypted challenge/response mechanism to authenticate users securely without transmitting their passwords over the network. Instead, the requesting system must perform a specific calculation to demonstrate its access to the protected NTLM credentials, ensuring a secure authentication process. This way the NTLM protocol avoids sending the password of the domain user within the network traffic.

To perform the NTLM authentication two types of interaction. Interactive Authentication and Non-Interactive Authentication. Interactive authentication involves a user actively providing their credentials (username and password) to log in to a system or application. In Interactive authentication the NTLM protocol requires two system, the one requesting authentication as Client and the Domain Controller which is validating the calculated NTLM hash with the stored NTLM hash in it.

In Non-interactive Logon, the whole scenario is different and it's a bit complex when compared to Interactive Logon. Non-Interactive Logon is a scenario where an already logged-on (had already performed interactive logon and has user's NT hash) domain user need to authenticate to a server to perform a desired action. This type of logon typically requires three system, the one requesting authentication as Client, the Server on which authentication is needed and the the Domain Controller which is validating the calculated NTLM hash with the stored NTLM hash in it.

Non-interactive logon, also known as pass-through authentication where the user's credentials are used without the user directly providing them interactively. This occurs in scenarios where a user's authentication credentials are forwarded from one system to another for accessing network resources or services, without requiring the user to re-enter their credentials.

But this is a layman's overview of how this NTLM authentication protocol works. There are many packet level mechanism being handled between the client and the server to establish a secure authentication. The Domain Controller can also query SAM registry hive or ntds.dit to get the NT/NTLM hash for the desired user.

NTLM Authentication via NTLMSSP

The NTLM protocol may seem simple when its viewed from the top level view. But it is complex as other protocols when it comes to protocol and its header level. NTLMSSP (NT LAN Manager Security Support Provider) is part of the Windows Security Support Provider Interface (SSPI), which is an API used for various security functions, including authentication. When a client (such as a user's computer) wants to access a resource on a server (like a file server or a domain controller), the NTLMSSP authentication process comes into play to establish a NTLM authentication. We will discuss more about SSPI later.

The NTLM authentication utilizes a challenge-response mechanism, comprising it into three messages:

• Type 1 (Negotiation)
• Type 2 (Challenge)
• Type 3 (Authentication)

Lets trigger a flow of NTLM Authentication via LDAP to fetch some users by providing valid domain user's creds.

Now we can clearly see the NTLM authentication flow for the above requested communication.

The flow of the NTLM authentication with these three types works a follows:

1. The client initiates the authentication process by sending a Type 1 (Negotiation) message to the server. This message includes a list of supported client features and requested server features.
2. The server responds with a Type 2 (Challenge) message, containing both agreed-upon features and a challenge generated by the server.
3. In response to the challenge, the client sends a Type 3 (Authentication) message, which includes various details about the client, such as the domain and username. The crucial part of the Type 3 (Authentication) message is the response to the challenge. These responses serve as proof to the server that the client user possesses knowledge of the account password. During the authentication process, a shared context is established between the two parties involved. This shared context encompasses a mutual session key, which plays a crucial role in subsequent signing and sealing operations.

Packet Analysis of NTLM Authentication

The NTLM packet follows a certain type for their headers. Based on the defined values in the header, the client and the server understands the flow during the authentication. Below are some fixed attributes of the packets which all message type of NTLM protocol should follow :

1. All the NTLM message headers begins with the NTLM Signature, which is the null-terminated ASCII string NTLMSSP (hexadecimal "0x4e544c4d53535000").
2. Second segment of the NTLM header is a long (32 bit unsigned) known as NTLM Message Type, which has the value for the message type.
   • Type 1 (Negotiation) = 0x00000001
   • Type 2 (Challenge) = 0x00000002
   • Type 3 (Authentication) = 0x00000003
3. The third segment are called Negotiate Flags which is of 32 bit, these flags are bit values which represents the attributes for the message type being sent by the client and the server.
   • Negotiate 56 = 0x80000000, Indicates that 56-bit encryption is supported.
   • Negotiate Key Exchange = 0x40000000, Indicates that the client will provide an encrypted master key in the "Session Key" field of the Type 3 message.
   • Negotiate 128 = 0x20000000, Indicates that 128-bit encryption is supported.
   • Negotiate 0x10000000 = 0x10000000
   • Negotiate 0x08000000 = 0x08000000
   • Negotiate 0x04000000 = 0x04000000
   • Negotiate Version = 0x02000000
   • Negotiate 0x01000000 = 0x01000000
   • Negotiate Target Info = 0x00800000, Indicates that the NTLM2 signing and sealing scheme should be used for protecting authenticated communications.
   • Request Non-NT Session = 0x00400000
   • Negotiate 0x00200000 = 0x00200000
   • Negotiate Identify = 0x00100000
   • Negotiate Extended Security = 0x00080000, Indicates that the NTLM2 signing and sealing scheme should be used for protecting authenticated communications.
   • Target Type Share = 0x00040000, Sent by the server in the Type 2 message to indicate that the target authentication realm is a share. Presumably, this is for share-level authentication.
   • Target Type Server = 0x00020000, Sent by the server in the Type 2 message to indicate that the target authentication realm is a server.
   • Target Type Domain = 0x00010000, Sent by the server in the Type 2 message to indicate that the target authentication realm is a domain.
   • Negotiate Always Sign = 0x00008000, Indicates that authenticated communication between the client and server should be signed with a "dummy" signature.
   • Negotiate Local Call = 0x00004000, Sent by the server to indicate that the server and client are on the same machine. Implies that the client may use the established local credentials for authentication instead of calculating a response to the challenge.
   • Negotiate OEM Workstation Supplied = 0x00002000, Sent by the client in the Type 1 message to indicate that the name of the domain in which the client workstation has membership is included in the message. This is used by the server to determine whether the client is eligible for local authentication.
   • Negotiate OEM Domain Supplied = 0x00001000, Sent by the client in the Type 1 message to indicate that the name of the domain in which the client workstation has membership is included in the message. This is used by the server to determine whether the client is eligible for local authentication.
   • Negotiate Anonymous = 0x00000800, Sent by the client in the Type 3 message to indicate that an anonymous context has been established. This also affects the response fields (as detailed in the "Anonymous Response" section).
   • Negotiate NT Only = 0x00000400
   • Negotiate NTLM key = 0x00000200, Indicates that NTLM authentication is being used.
   • Negotiate 0x00000100 = 0x00000100
   • Negotiate Lan Manager Key = 0x0000080, Indicates that the Lan Manager Session Key should be used for signing and sealing authenticated communications.
   • Negotiate Datagram = 0x0000040, Indicates that datagram authentication is being used.
   • Negotiate Seal = 0x0000020, Specifies that authenticated communication between the client and server should be encrypted (message confidentiality).
   • Negotiate Sign = 0x0000010, Specifies that authenticated communication between the client and server should carry a digital signature (message integrity).
   • Request 0x00000008 = 0x0000008
   • Request Target = 0x0000004, Requests that the server's authentication realm be included in the Type 2 message.
   • Negotiate OEM = 0x0000002, Indicates that Unicode strings are supported for use in security buffer data.
   • Negotiate UNICODE = 0x0000001, Indicates that Unicode strings are supported for use in security buffer data.

Type 1 (Negotiate) Packet

In the NTLM (NT LAN Manager) authentication protocol, a Type 1 packet, also known as the Negotiate message or Type 1 message, is the first message sent by the client (user's computer) when attempting to initiate the authentication process with the server (domain controller or target server). It is part of the NTLM challenge-response mechanism used to establish user identity and authenticate users in Windows network environments.

The Type 1 packet is named Negotiate because it includes a list of features supported by the client and requested from the server. The client uses this message to negotiate the authentication process and indicate which NTLM protocol features it supports. This allows the server to determine the appropriate authentication settings for the specific client.

The components of a Type 1 packet include:

1. NTLM Signature: A 4-byte field that identifies the message as an NTLM message. It is set to NTLMSSP in ASCII.
2. NTLM Message Type: A 4-byte field that specifies the message type. For the Type 1 packet, this field is set to 0x00000001.
3. Negotitate Flags: A 4-byte field that contains a bitmask representing various negotiation options and features supported by the client.
4. Domain Name: A variable-length field that contains the client's domain name. This field is optional in this type.
5. Workstation Name: A variable-length field that contains the client's workstation name. This field is optional in this type.
6. Version: A 8-byte field that specifies the NTLM version. This field is optional in this type.

The Type 1 packet is sent by the client to initiate the NTLM authentication process. Upon receiving the Type 1 packet, the server responds with a Type 2 (Challenge) packet containing a random challenge and additional information needed for the subsequent steps of the NTLM authentication process. The challenge-response mechanism ensures that the client and server can securely establish the user's identity without transmitting the actual password over the network.

Type 2 (Challenge) Packet

In the NTLM (NT LAN Manager) authentication protocol, a Type 2 packet, also known as the Challenge message or Type 2 message, is the response sent by the server (domain controller or target server) to the client (user's computer) after receiving the Type 1 (Negotiate) packet during the NTLM authentication process.

The Type 2 packet is named Challenge because it contains a challenge generated by the server. This challenge is a 8 byte random value that the client must use in the subsequent steps of the NTLM authentication process to prove its identity and complete the authentication.

The components of a Type 2 packet include:

1. NTLM Signature: A 4-byte field that identifies the message as an NTLM message. It is set to NTLMSSP in ASCII.
2. NTLM Message Type: A 4-byte field that specifies the message type. For the Type 2 packet, this field is set to 0x00000002.
3. Target Name: A variable-length field that contains the target server's name.
4. Negotiate Flags: A 4-byte field that contains a bitmask representing various negotiation options and features supported by the server.
5. NTLM Server Challenge: An 8-byte field that contains a random challenge generated by the server.
6. Context: An 8-byte field that is reserved for future use. This field is optional in this type.
7. Target Information: A variable-length field that contains additional information like NetBIOS, DNS names which required for the NTLM authentication process. This field is optional in this type.
8. Version: A 8-byte field that specifies the NTLM version. This field is optional in this type.

n NTLM, during the authentication process, the server (domain controller or target server) sends a Type 2 message to the client in response to the client's Type 1 message (Negotiate). The Type 2 message contains a challenge, and it may also include an SSPI (Security Support Provider Interface) context as part of the negotiation.

If the Negotiate Local Call flag is set in the Type 2 message, the client does not need to perform the usual NTLM challenge-response calculation. Instead, it adopts the SSPI context sent by the server in the Type 2 message. This means that the client utilizes the SSPI context provided by the server, effectively bypassing the need to calculate an appropriate response.

By adopting the SSPI context, the client can use existing security credentials or tokens, avoiding the need to calculate and generate a new response based on the challenge and its password hash. This mechanism is typically used for local authentication scenarios or when the client has already established a security context and does not need to perform the full NTLM challenge-response process.

Upon receiving the Type 2 packet, the client processes the challenge and combines it with its NTLM hash (aka NT hash, PS: don't get confused here) of the user's password to create a Type 3 packet (Authenticate) packet. The Type 3 packet is then sent back to the server, along with other authentication-related information, to complete the authentication process.

Type 3 (Authenticate) Packet

In the NTLM (NT LAN Manager) authentication protocol, a Type 3 packet, also known as the Authenticate message or Type 3 message, is the final message sent by the client (user's computer) to the server (domain controller or target server) to complete the NTLM authentication process.

The Type 3 packet contains the authentication response generated by the client, which includes the user's identity and proof of the user's knowledge of the password without actually sending the plaintext password over the network.

The components of a Type 3 packet include:

1. NTLM Signature: A 4-byte field that identifies the message as an NTLM message. It is set to NTLMSSP in ASCII.
2. NTLM Message Type: A 4-byte field that specifies the message type. For the Type 3 packet, this field is set to 0x00000003.
3. LM/LMv2 Response: A variable-length field that contains the LM response or LMv2 response, depending on the NTLM authentication settings and the client's negotiation.
4. NTLM/NTLMv2 Response: A variable-length field that contains the NTLM response or NTLMv2 response, which is based on the challenge provided by the server and the client's NTLM hash (NT hash) of the user's password.
5. Domain Name: A variable-length field that contains the client's domain name.
6. User Name: A variable-length field that contains the user's username.
7. Host Name: A variable-length field that contains the client's workstation name.
8. Session Key: An 8-byte field that is reserved for future use. This field is optional in this type.
9. Negotiate Flags: A 4-byte field that contains a bitmask representing various negotiation options and features used during authentication. Flags become optional here, as they reach the final phase of the NTLM authentication. This field is optional in this type.
10. Version: A 8-byte field that specifies the NTLM version. This field is optional in this type.

Upon receiving the Type 3 packet, the server validates the authentication response by performing the same calculations as the client using the challenge provided in the Type 2 (Challenge) packet and the user's NTLM hash (NT hash) stored in the SAM database or Active Directory's NTDS.dit.

If the calculated responses match, the server confirms the user's identity and grants access to the requested resources or services. The authentication process is complete, and the client is now authenticated and authorized to access the network resources.

NOTE: The LMv1/LMv2 and NTLMv1/NTLMv2 responses from Type 3 are security buffers containing encrypted data created from the user's NT has aka NTLM hash in response to the Type 2 challenge. The Target Name from Type 2 is a security buffer that holds the authentication realm to which the authenticating account belongs. For domain accounts, it represents the domain name, and for local machine accounts, it indicates the server name. The encoding of the target name can be either Unicode or OEM, depending on the agreed-upon encoding during negotiation.

References

The best RFC to refer more on NTLMv2 and response calculation - https://curl.se/rfc/ntlm.html

https://yougottahackthat.com/blog/339/what-is-aad3b435b51404eeaad3b435b51404ee

https://learn.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/

Conclusion

In conclusion, the NTLM (NT LAN Manager) authentication protocol has been a foundational component of Windows network environments, facilitating user authentication and secure access to resources for many years. Through our exploration of the NTLM authentication flow and packet analysis, we have gained insights into the challenge-response mechanism, where the server sends a challenge to the client, and the client responds with an authentication token to prove its identity. In our future blog posts, we will be covering few attack vectors which depends on the NTLM authentication flow. Stay tuned !