If a client needs to authenticate into a server successfully, the client needs to prove their identity. This is done by using a username and password. The client needs to present its username and password to the authentication server, and it will verify the identity. There are legacy protocols and systems that send this information in cleartext, even in an open network. Telnet is a good example of this. If someone is listening to traffic (packet capturing) on a Telnet session, they can easily capture a password as it is transmitted in cleartext.
Modern authentication protocols are well aware of these types of threats and use different technologies to encrypt credentials or create cryptographic hashes for identity verification. The cryptographic hash means a password string is transformed into a fixed-length digest using an algorithm.
Earlier in AD authentication section, we saw how Kerberos authentication works using hash values. When we use hash values, the authentication server compares the hash value submitted by the client with the hash value for the user password that is stored in its database. In the Windows environment, these password hashes are stored in three different places:
- The Security Account Manager (SAM) database
- Local Security Authority Subsystem Service (LSASS)
- The AD database
The SAM database stores usernames and New Technology (NT) hashes in a %SystemRoot%/system32/config/SAM file. This contains all the hash values for accounts that are local to the computer. The current version of SAM does not store LAN Manager (LM) hashes in its database file.
The very first password hash schema introduced by Microsoft was LM. It uses the Data Encryption Standard (DES) algorithm for hashing. This is a legacy-weak schema, and Microsoft highly recommends not using it. It doesn't support passwords larger than 15 ASCII characters, or passwords that are not case-sensitive. However, any new operating system released after Windows Vista supports the Advanced Encryption Standard (AES) algorithm for hashing.
Compared to the cleartext password, for an attacker, it is almost impossible to figure out the password based on the hash. Even if they are able to do it, it will take a lot of computing power and time. But, if they can find the hash value instead of retrieving the password, the hash value can be used to initiate a connection with the server on behalf of the original owner of the hash. This sounds easy, but in practice, it is still very difficult as these authentication protocols have their own mechanisms to prevent attackers from using someone else's hash value. If you consider Kerberos, it uses timestamps along with requests and responses to verify the authenticity of hashes. New Technology (LT), New Technology LAN Manager (NTLM) v1, and NTLM v2 also use a similar challenge-response mechanism to authenticate without revealing the password.
However, even hash values are not transmitted over directly. LSASS stores credentials in memory on behalf of users with active sessions. LSASS can store credentials in multiple forms, such as an NT hash, an LM hash, and Kerberos tickets. This is required in order to maintain active sessions and perform future authentications faster. This will clear up during the reboot, but it can be enough for the attacker to retrieve a hash value and use it to compromise the entire identity infrastructure. Microsoft introduced many features and techniques to protect the AD environment from pass-the-hash attacks, and in this section, we are going to look into them in detail.