Confusion clearing of LM, NT, NTLM, NTLMv1/v2, Net-NTLMv1/v2
The blog is going to be long, please have patience to read everything. I am assuring you that once you read this fully, your all confusion will be cleared.
There are lots of talks about the above hashes. People always fall in a confusion state about those hashes while conducting AD pentest and why are not they? Because there is no where in the internet that someone would clear this. Luckily I found some blog posts where they clear it. My aim is, I will clear this in more granular way so that everything will be more clear now after reading this.
Let me first clear you what are the same thing but calling it differently.
NT hash is same as NTLM hash. NTLM is the protocol and it includes NTLMv1 and NTLMv2.
Again, NTLMv1 is same as Net-NTLMv1 and NTLMv2 is same as Net-NTLMv2.
Now let’s discuss what is use where:
LM and NTLM hash is stored in SAM database in non domain joinded windows system. And in AD, the same is stored in ntds.dit file. Their location as follows:
In Windows system:
Location: %SystemRoot%\System32\config\SAM
In AD:
Location: %SystemRoot%\NTDS\NTDS.ditUsing the tool like mimikatz you can extract hashes from these two files or lsass memory. From Windows ≥ 8.1 its not possible to extract password in clear text from sam/ntds.dit/lsass.
NTLMv1/V2 (aka, Net-NTLMv1/v2) are used in network authentication. Client-Server communication. For example, you are trying to connect to a share folder in a server.
Using tools like responder or inveigh you can intercept the NTLMv1/v2 aka, Net-NTLMv1/v2 hashes.
Now let’s discuss if we get the hash then what kind of attack we could further perform against other hosts.
If we get the LM or NTLM hash from sam/lsass/ntds.dit file then we can later perform pass-the-hash attack. Using the tool like Evil-Winrm and crackmapexec we can provide the username and password hash to connect with the machine. Also we can crack the hash in offline to connect with the machine via rdp or physically.
If we manage to intercept the NTLMv1/v2 aka, Net-NTLMv1/v2 hashes then we will be able to perform ntlm relay attack.
Upto above is the main motive of this post. Now if you would like to learn more about the protocols, then read below:
Windows passwords attacks. What is LM and NTLM?
Windows store its password on SAM database as I told earlier. Now how sam will store password’s hash whether it is LM or NTLM format, depends on the policy. Modern windows system does not allow LM because of its greatest flaws.
You cannot copy the sam database when windows is running because of windows kernel restriction over sam db. Sam db location is %systemroot%\system32\config\sam
The copy of sam db is also loaded in memory thats why offline attack is possible. For example, with admin privilege we can dump registry hive and system key and crack the hash offline using impacket-secretsdump tool. Also mimikatz can be used to dump the hash from memory as well.
System key is 128 bit encryption key that are used to protect the sam db when windows is not running. When windows is booted up then this syskey is used to decrypt the sam db then load the hashes to the memory. Then LSA get to access there.
Blank password for lm and ntlm:
LM hash: aad3b435b51404eeaad3b435b51404ee
NTLM hash: 31d6cfe0d16ae931b73c59d7e0c089c0
When no password is set then the above hash you will get. This means user did not set any password.
Now let’s know how LM worked:
When the password length is 14 character or less then both LM and NTLM hash are generated. Here is the process. Say your password is mypass. It is first converted to all uppercase like MYPASS. Then length is validated. As the above password is 6 character long then more 8 null bytes are added for padding. Now including null bytes the password character is now 14 characters or bytes. Now it is divided by 2, then it becomes 7 bytes each. Then it is fed into DES algorithm (more on this later) to produce 8 bytes of hash for both side. Then both the 8 bytes are concatenated to produce 16 bytes hexadecimal hash. You may think that why 32 characters long the hash is where as 16 bytes we got. See below explanation.
31d6cf….. till 32 characters.
444444
As you can see we need 2 string (which is the first 3 & second 1) to match 8 bits (4+4) which is 1 byte. So for 1 byte we need 2 string, thus for 16 bytes we will need 32 characters. Thats why hashes are 32 characters long. In hexadecimal it is written as 4+4 instead of direct 8.
In details of how LM worked:
The LM hash (LAN Manager hash) algorithm is an old and relatively insecure method of password hashing primarily used in early versions of Microsoft Windows operating systems, up to Windows XP. It has since been deprecated due to its vulnerability to various attacks. Nevertheless, here’s an explanation of how the LM hash algorithm works based on the steps you provided:
- Convert All Lowercase to Uppercase: The first step involves converting the password to uppercase characters. This step ensures that the password is not case-sensitive, as the LM hash is not case-sensitive.
- Pad Password to 14 Characters with NULL Characters: The password is padded to a fixed length of 14 characters using NULL characters (often represented as ‘0x00’ in hexadecimal).
- Split the Password into Two 7-Character Chunks: The 14-character password is divided into two 7-character chunks.
- Create Two DES Keys from Each 7-Character Chunk: Each 7-character chunk is used to create two 56-bit DES encryption keys. This step involves manipulating the bits in the chunk to generate the keys.
- DES Encrypt the String “KGS!@#$%” with These Two Chunks: The string “KGS!@#$%” is encrypted separately using each of the two DES keys derived from the 7-character chunks. The result of this encryption is two separate ciphertexts.
- Concatenate the Two DES Encrypted Strings (LM Hash): Finally, the two ciphertexts obtained in the previous step are concatenated to create the LM hash. This LM hash is often stored or transmitted for authentication purposes.
The key weaknesses of the LM hash algorithm are as follows:
- It converts passwords to uppercase, which reduces the effective character set, making it susceptible to brute force attacks.
- It pads passwords with NULL characters, which adds known values to the password.
- It splits passwords into two 7-character chunks, making it vulnerable to rainbow table attacks.
- DES encryption is used, which is now considered weak and susceptible to various attacks.
Due to these weaknesses, the LM hash is considered highly insecure, and it’s no longer used in modern Windows operating systems. Instead, more secure hashing algorithms like NTLM (New Technology LAN Manager) or the use of strong password hashing methods like bcrypt, scrypt, or Argon2 are recommended for password storage and authentication.
Creating LM and NTLM hash:
AAD3B435B51404EE
This portion is added when the password is less than 14 character long, to make it 32 characters.
When my password is 15 character long, then no lm hash is created right? Then how ntlm is calculated? and then what is the LM:NTLM format?
Yes correct. In Windows systems, when a password is 15 characters or longer, the LM (LAN Manager) hash is not generated or generated in the below LM:LM format. However, the NTLM (New Technology LAN Manager) hash is still calculated.
When you see the above format, then this means the password is 15+ character long. Other than this, you will see, no LM. Only NTLM you would see. See picture below.
When the password is 15 characters or longer, Windows uses a different method called NTLMv2 (latest windows), which is more secure than the older NTLM and LM hashing methods. NTLMv2 includes a challenge-response mechanism and HMAC-MD5 encryption for password hashing.
In NTLMv2, the password is not directly hashed into a single value like in LM or NTLM, but it is used in combination with other information, including a random challenge from the server, to create the NTLMv2 response. The exact details of the NTLMv2 calculation are more complex and involve multiple steps.
As for the LM:NTLM format, if the password is 15 characters or longer and NTLMv2 is used, you won’t have a simple LM hash. Instead, you’ll only have the NTLMv2 hash, which is a hexadecimal string representing the result of the NTLMv2 hashing process.
The format of the NTLM hash remains unchanged, typically 32 characters in hexadecimal format.
So, if your password is 15 characters or longer, you will only have the NTLMv2 hash, and there won’t be an LM hash involved. The format would be something like:
NTLMv2 hash: 1234567890abcdef1234567890abcdef
Please note that the actual hash value will be a long hexadecimal string and will vary depending on the specific password and challenge used during authentication.
LSA secrets:
HKEY_LOCAL_MACHINE\Security\Policy\Secrets registry key
LSA secrets — local security authority secrets is the another password storage in windows operating system. Windows stores service account passwords, cached credentials and some other important credentials on lsa secrets. Tools like mimikatz are used by the attacker to dump passwords from lsa secrets.
Only system account has the access to touch lsa but using mimikatz we could manipulate this to system account and got our job done.
LSA Secrets, short for “Local Security Authority Secrets,” is a feature in the Windows operating system that allows applications and services to store sensitive information securely. It’s primarily used to store credentials, encryption keys, and other sensitive data that should be protected from unauthorized access.
LSA Secrets is managed by the Local Security Authority (LSA) component in Windows, which is responsible for security-related tasks, including authentication and access control. LSA Secrets are stored in the Windows Registry under the following key:
HKEY_LOCAL_MACHINE\\SECURITY\\Policy\\SecretsApplications and services can leverage LSA Secrets to store information such as:
- Service Account Passwords: Windows services often run under specific user accounts. The passwords for these accounts can be stored in LSA Secrets to ensure they are not easily accessible.
- Credential Manager: Windows Credential Manager uses LSA Secrets to securely store and manage user credentials, such as usernames and passwords, for various applications and network resources.
- Certificate Private Keys: LSA Secrets can also store private keys associated with certificates, providing an additional layer of protection for these sensitive cryptographic assets.
- Application Secrets: Custom applications and services can use LSA Secrets to store application-specific secrets or configuration data that needs to be protected.
Access to LSA Secrets is heavily restricted, and only authorized processes and services should be able to access this information. It’s an essential component of Windows security, ensuring that sensitive data is stored securely and that only trusted entities can access it.
It’s important to note that tampering with LSA Secrets or attempting to extract information from it without proper authorization can lead to security breaches and is a violation of Windows security policies. Therefore, it’s crucial to use LSA Secrets responsibly and in accordance with best security practices.
The Local Security Authority (LSA) in Windows can store various types of credentials and secrets, including remote access credentials. Remote access credentials typically refer to the credentials (username and password) that are used to connect to remote resources or systems, such as network shares, remote servers, or other network-attached devices.
Here are some common scenarios where remote access credentials might be stored by the LSA:
- Network Share Access: When you connect to a network share on another computer, Windows can cache the credentials used for that share so that you don’t have to enter them every time you access it.
- Remote Desktop (RDP) Credentials: If you use Remote Desktop to connect to remote computers, the credentials you use for those connections can be stored in the Windows Credential Manager, which is managed by LSA.
- VPN Connections: When you configure a VPN connection, the VPN client may store your username and password securely in LSA Secrets so that it can establish the connection on your behalf.
- Wireless Network Credentials: Windows can store the credentials for Wi-Fi networks you connect to so that you can automatically reconnect without re-entering the password.
- Saved Web Passwords: Web browsers often use the Windows Credential Manager to securely store passwords for websites you log in to, which can be considered a form of remote access credentials.
It’s important to note that these credentials are stored securely and encrypted within the LSA Secrets, and they are typically protected by your Windows login credentials. Access to these credentials usually requires administrative privileges on the computer.
As always, it’s essential to use strong, unique passwords for your remote access credentials and to keep your system and applications updated to protect against security vulnerabilities. Additionally, regularly review and manage the stored credentials to ensure the security of your systems and data.
Now let’s know how NTLM works:
- The client sends an authentication request to the server they want to access.
- The server generates a random number and sends it as a challenge to the client.
- The client combines their NTLM password hash with the challenge (and other known data) to generate a response to the challenge and sends it back to the server for verification.
- The server forwards the challenge and the response to the Domain Controller for verification.
- The domain controller uses the challenge to recalculate the response and compares it to the original response sent by the client. If they both match, the client is authenticated; otherwise, access is denied. The authentication result is sent back to the server.
- The server forwards the authentication result to the client.
Note that the user’s password (or hash) is never transmitted through the network for security.
Note: The described process applies when using a domain account. If a local account is used, the server can verify the response to the challenge itself without requiring interaction with the domain controller since it has the password hash stored locally on its SAM.
Thanks. Now I hope all of your confusion clears. If you find this useful, please consider to subscribe below.
LinkedIn:
https://www.linkedin.com/in/md-mahimbin-firoj-7b8a5a113/
YouTube:
