# Password Files & Authentication
## Understanding the files `passwd` and `shadow`
{% hint style="info" %}
**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.
{% endhint %}
Previously in Linux user credentials used to be stored directly in the`passwd`file. 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.
{% hint style="warning" %}
Permissions: This file is usually `read-only` for users and owned by `root`.
{% endhint %}
### Reading the file `/etc/passwd`
Let's see what content we get when running the command on one of our virtual machines.
{% hint style="success" %}
cat /etc/passwd
{% endhint %}
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/shadow`of 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`.
{% hint style="info" %}
password `There are even tools like` unshadow`passwd` and `(part of JohnTheRipper) that allow us to recombine the` shadow files to then crack them quickly with`.`
{% endhint %}
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)
{% hint style="info" %}
**Image by Cornell University** **Wikipedia:** (**Data Encryption Standard**DES [) is an encryption algorithm, that is, a method to](https://es.wikipedia.org/wiki/Criptograf%C3%ADa) encrypt [information. DES underwent intense academic analysis and motivated the modern concept of](https://es.wikipedia.org/wiki/Cifrado_por_bloques) block cipher [and its](https://es.wikipedia.org/wiki/Criptoan%C3%A1lisis)cryptanalysis [. 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 its](https://es.wikipedia.org/wiki/Triple_DES)Triple DES [variant, although there are theoretical attacks. For some years now, the algorithm has been replaced by the new](https://es.wikipedia.org/wiki/Advanced_Encryption_Standard) AES
{% endhint %}
**(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](https://tobtu.com/lmntlm.php).
this link **As we can see the hashes generated for each password in LM format are**identical 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`.
{% hint style="success" %}
hashcat
{% endhint %}
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.
#### 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.
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:
{% hint style="info" %}
**Wikipedia**: The specific algorithm looks as follows. [\[LINK\]](https://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv1)
```
C = 8-byte server challenge, random
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
response = DES(K1,C) | DES(K2,C) | DES(K3,C)
```
{% endhint %}
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.
{% hint style="info" %}
**Example hash (From hashcat's hash page)**: [\[LINK\]](https://hashcat.net/wiki/doku.php?id=example_hashes)
u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c
{% endhint %}
{% hint style="success" %}
hashcat -m 5500 -a 3 ntlm\_v1\_hash
{% endhint %}
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.
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:
{% hint style="info" %}
NTLMv2 Hash: [\[LINK\]](https://hashcat.net/wiki/doku.php?id=example_hashes)
admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030
{% endhint %}
The algorithm can be seen in detail in the Wikipedia article, which provides additional information.
{% hint style="info" %}
**Wikipedia**: The specific algorithm looks as follows. [\[LINK\]](https://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv2)
```
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*
```
{% endhint %}
#### 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.*
{% hint style="warning" %}
**Download mimikatz from its repository:** [\[LINK\]](https://github.com/gentilkiwi/mimikatz/releases)
You must **disable Windows Defender**, since mimikatz is detected as a malicious file.
{% endhint %}
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.
{% hint style="success" %}
hashcat -m 1000 -a 3 hash
{% endhint %}
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`.
{% hint style="warning" %}
**Kerberos** is not within the scope of this lab and we will see it in detail later.
{% endhint %}
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.
{% hint style="info" %}
These labs are subject to modifications and corrections; the most up-to-date version is available online at [the following link](https://tzero86.gitbook.io/tzero86/).
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://tzero86.gitbook.io/tzero86/password-files.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.