Password Files & Authentication

In this lab we will see how the passwd and shadow files are formed in Linux and SAM in Windows and how authentication is handled in these OSes.

image by pipedrive.com

Understanding the files passwd and shadow

Objective of the CEH course lab at UTN:

Within the environments of different OSes, we will find files that are very important regarding authentication, they are the file passwd and the shadow, from LINUX distributions or the SAM from Windows. The exercise here is to analyze and detail those files and describe them as best as possible.

Previously in Linux user credentials used to be stored directly in thepasswdfile. However, due to limitations and security reasons it now only stores account information, while the password hashes are stored in the shadow.

The file is commonly found at the following location /etc/passwd and its content is plain text. Generally read-only access is allowed since many utilities use its content to map IDs to the corresponding user accounts. Within it we can find a list of system accounts. For each account the following pieces of information are exposed: Username , Password, UID, GID, UserID Info, Home Dir, Command/Shell. Let's see what each one means and what the general structure of this file and its data looks like.

File structure /etc/passwd

We already mentioned that the passwd file stores information in plain text. That information is stored one entry per line. Each line delimits its fields using colons :.

Let's look at a diagram of the structure of each line.

Let's look at a description of what function each part serves:

1. Username: Commonly used for the login process, length between 1 and 32 characters.

2. Password: A character x that indicates that the password hash is stored in the file /etc/shadow.

3. UID (User ID): Each user is assigned a ID, with 0 reserved for root, those from 1 to 99 reserved for predefined accounts, those from 100 to 999 reserved for administrative and system accounts. Finally IDs greater than 1000 are assigned to users.

4. GID (Group ID): The primary group to which the user belongs, stored in /etc/groups.

5. UserID Info: Allows storing additional user information, such as the service name (service accounts) or details like User full name.

6. User Home Directory: The absolute path to the home folder of the user in question.

7. Command or Shell: Indicates the shell or command. Commonly it is a shell but that is not always the case.

Permissions: This file is usually read-only for users and owned by root.

Reading the file /etc/passwd

Let's see what content we get when running the command on one of our virtual machines.

cat /etc/passwd

we see that the results include a long list of administrative accounts, services and finally users.

Understanding the file /etc/shadow

We already mentioned that currently credentials in Linux largely reside in the /etc/passwd file, but we also mentioned that the password hash /etc/shadowof each user is stored in the file called

. Let's look in detail at the structure of this other file. /etc/passwd In the same way as in the /etc/shadow file, the data inside is also stored line by line. In fact each of the lines of this file corresponds 1 to 1 with those of the.

password There are even tools like unshadowpasswd and (part of JohnTheRipper) that allow us to recombine the shadow files to then crack them quickly with.

1. Username: John

2. The username. Encrypted Password: The encrypted password usually follows a pattern like this.

   1. $type$Salt$Hash Where the type

      1. $6$is the hash algorithm that was used to encrypt the password.

      2. $5$: Indicates the use of SHA-512.

      3. : Indicates the use of SHA-256.$2a$

      4. $1$: : Indicates the use of Blowfish.

      5. Indicates the use of MD5 Hash. $2y$:

   2. Indicates the use of Eksblowfish. The (Salt salt in English):

   3. is a value that is used to guarantee the randomness of hashing, so that the resulting hash is always different. Finally the: Hash value

3. The hash result generated for the encryption of our password. Last password change:

4. Represents a date in days, counting from January 1, 1970 to today. Minimum password age:

5. Normally set to zero indicating that there is no minimum established for password expiration. If it contains another value, it represents the number of days that must pass before changing the password. Maximum password age:

6. Number of days before the password expires. Warning period:

7. The number of days before the password expires. For example a value of 6 will remind the user to change the password 6 days before it expires. Inactivity period:

8. The number of days after the password has expired during which the user account will be disabled. Normally it is zero.Expiration date

9. : The date when the user account was effectively disabled.Unused (Reserved for future use)

: Currently ignored, kept for possible future uses. /etc/passwd and /etc/shadow So far we saw how the

files are composed and how information within them is organized and encrypted.

Understanding SAM (Security Account Manager) In Windows passwords are stored in the SAM file. This file is actually a database where Windows stores passwords in hashed form. To generate these hashes Windows has used different mechanisms across versions. In particular we will focus on the following:.

LM, NT-Hash(NTLM, NTLMv1 and NTLMv2)

LM Hash (LanMan Hash)

LM Hash is the old way Windows stored passwords and dates back to the 1980s. The main disadvantage of this hash is that it worked with a limited character set (14 characters), which made it very easy to crack. Internally the hashes are generated using a generally very weak mechanism and the character set length is not its only disadvantage.

Image by Cornell University Wikipedia: (Data Encryption StandardDES ) is an encryption algorithm, that is, a method to encrypt information. DES underwent intense academic analysis and motivated the modern concept of block cipher and itscryptanalysis . Today, DES is considered insecure for many applications. This is mainly because the 56-bit key size is short; DES keys have been broken in less than 24 hours. It is believed that the algorithm is practically secure in itsTriple DES variant, although there are theoretical attacks. For some years now, the algorithm has been replaced by the new AES

(Advanced Encryption Standard).

1. Let's quickly see how the LM algorithm operates: Conversion:

2. All lowercase letters of the password are converted to uppercase letters. Modification:

3. Null characters (NULL) are added to the password until reaching 14 characters. Division:

4. The password is split into two blocks, each of 7 characters. Key generation:

5. 2 DES keys are generated for each block.Encryption : Each block is encrypted with DES and a fixed plaintext with the value.

6. KGS!@#$% Generated Hash:

The hash is generated based on the concatenation of both DES-encrypted blocks.

Considering how easily it can be cracked, LM Hash was disabled by default with the release of Windows Vista and Windows Server 2008. However, backward compatibility for legacy systems is still maintained and it can be enabled manually via a Group Policy (GPO). We can see this hash in action using a tool like the one available online at.

this link As we can see the hashes generated for each password in LM format areidentical after conversion

, this is due to the first step performed by the algorithm, the conversion from lowercase to uppercase. If we look at the resulting hashes in NTLM format, we see that they are different for each password. Let's see how easy it is to crack that hash using a tool like.

hashcat

hashcat -m 3000 -a 3 hash

Inside the VM it took about 10 minutes to crack the password:

As we see the process of cracking LM hashes is relatively simple and fast.

NT Hash (NTLM, NTLMv1, NTLMv2)

Currently Windows uses a hashing mechanism known as NT Hash or NTLM Hash. There are several versions of this hash that have improved its security over time. Let's quickly look at the main characteristics of each version.

NTLM Protocol The NTLM protocol is a Challenge-Response type system which uses the exchange of 3 messages to authenticate the client and an optional fourth message for the integrity of the exchange. The hash has a length of 128 bits and works for both local accounts and Active Directory domain accounts.

Image by IONOS

NT Hash - NTLMv1

The algorithm for this protocol is quite simple for hash generation, and makes use of both types of hashes: LM Hash and NT Hash. This version 1 of NTLM is already deprecated and is currently maintained for backward compatibility with old systems.

Image by asecuritysite.com

The algorithm for this version of NTLM is quite simple to understand at a high level:

1. Let's quickly see how the LM algorithm operates: The password is converted to Unicode (UTF-16-LE).

2. All lowercase letters of the password are converted to uppercase letters. For each character a 0 (zero byte) is added

3. Hashing: Finally the MD4 algorithm is applied to the result of the previous process.

The specific algorithm can be consulted on Wikipedia, but for reference it looks like this:

Wikipedia: The specific algorithm looks as follows. [LINK]

C = 8-byte server challenge, random
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
response = DES(K1,C) | DES(K2,C) | DES(K3,C)

Let's see how we can crack this new hash using Let's see how easy it is to crack that hash using a tool like and an example hash.

Example hash (From hashcat's hash page): [LINK]

u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c

hashcat -m 5500 -a 3 ntlm_v1_hash

This time it took hashcat about 5 minutes to crack the hash.

As we can see, the cracking process for the NTLMv1 version is also relatively simple and fast.

NT Hash - NTLMv2

Version 2 of NTLM continues to use the NTLM challenge-response format protocol challenge-response that we saw before, but incorporates security and cryptographic improvements to make it more secure and replace NTLMv1. It also incorporates the use of HMAC-MD5 as the hashing algorithm and includes the domain name as a variable in the authentication process.

Image by Guang Ying Yuan, Advisory IT specialist at IBM.

1. Negotiation: The 8-byte challenge is generated and issued by the server.

2. Response: The following are generated 2 blocks of 16 bytes with HMAC-MD5 hashes as a response to the challenge. These response blocks also include a challenge generated on the client side, the password hash (HMAC-MD5) and other identifying information may be included.

   1. Short Response (shorter-response): In this response block the 8 bytes of the challenge from the client side and the 16 bytes from the block. This produces a 24-byte response block consistent with the format used in NTLMv1.

   2. Second Response: The second response block uses a challenge of variable length, which includes, among other things: the current time in NT Time, an 8-byte random value, the domain name and additional standard information. Considering that this response must include the challenge from the client side, its length will vary in each case.

The resulting hash can be seen in the following example obtained from hashcat's hash page:

NTLMv2 Hash: [LINK]

admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030

The algorithm can be seen in detail in the Wikipedia article, which provides additional information.

Wikipedia: The specific algorithm looks as follows. [LINK]

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*

Extracting hashes from SAM with Mimikatz

So far we have seen the different ways passwords are handled in Windows. To avoid ending the lab without learning a tool that allows us to interact with these hashes stored in SAM, let's see how we can extract these hashes from a Windows host using mimikatz and then crack them using Let's see how easy it is to crack that hash using a tool like. However, we will not go into detail on how to use mimikatz itself; rather we will quickly use it to dump the hashes. I may cover the use of mimikatz in another write-up in the future, since it is a very interesting tool.

Download mimikatz from its repository: [LINK]

You must disable Windows Defender, since mimikatz is detected as a malicious file.

The first step is to obtain a copy of the SAM file, for which we will use the Powershell terminal (as Admin) and copy the SAM and SYSTEM files to our working folder.

We should have something similar to this after performing that process:

Now we need to open a console, ideally as administrator, and navigate to the folder where we have our export and mimikatz.

The next step is to run mimikatz from the Windows terminal (PowerShell):

Now we must tell mimikatz that we want to extract the SAM file hashes and for that we must use the following command:

lsadump::sam /sam:C:\Users\Administrator\Desktop\mimikatz\x64\sam /system:C:\Users\Administrator\Desktop\mimikatz\x64\system

As we can see, mimikatz extracts the hashes present in the SAM database:

Finally we will again use our faithful friend Let's see how easy it is to crack that hash using a tool like to try to crack the password of the administrator. As we can see the hash is in NTLM format.

hashcat -m 1000 -a 3 hash

Hashcat again takes a few minutes to crack the hash.

End of the lab

Up to this point we have seen how password handling works in both Linux and Windows and how we can crack different types of hashes using mimikatz and Let's see how easy it is to crack that hash using a tool like. It is worth mentioning that there is another authentication protocol we have not seen in this lab called Kerberos which is commonly used for authentication against domains such as Active Directory.

Kerberos is not within the scope of this lab and we will see it in detail later.

It has been an extensive lab that has allowed me to study a lot about the topics covered, mainly about how authentication works in Windows, which I was not very familiar with.

These labs are subject to modifications and corrections; the most up-to-date version is available online at the following link.