Overview

The goal of this lab is to leverage the accounts discovered in the previous lab (Password Guessing) and crack additional passwords.

Useful Commands and Instructions

The id command can help identify what groups a user is in (this is how to identify a root user).

When examining the /etc/passwd file, there are indicators of what hashing algorithm is being used. Below is a screenshot showing the translation:

Source

The resource above also shows the positioning of the hash algorithm relative to other information. The order of elements (between colons) is:

1. Username
2. Hashed password ("Usually password format is set to $id$salt$hashed", make sure to see the image above for what the $id means for each hashing algorithm)
3. Last password change (lastchanged)
4. Minimum (number of days between password changes)
5. Maximum (number of days the password is valid)
6. Warn (how many days before password expiration that user is warned to change password)
7. Inactive (Number of days after password expires that account is disabled)
8. Expire (Date of expiration of the account)

Once you've copied the contents of /etc/passwd and /etc/shadow to your own system, you can utilize unshadow and john the ripper. Below is the command that I used to do so, and there's also a link to the unshadow documentation:

unshadow /home/champuser/week6/etc_passwd.txt /home/champuser/week6/etc_shadow.txt > /home/champuser/week6/parker.crack.password.db

Documentation

Now that we have the unshadow file, it can be used alongside a wordlist to crack the passwords. In the interest of testing/saving time, I pulled just one of the three users that was generated after this series of events. This new file was named "galadriel.crack.password.txt".

I then ran this file using JtR:

john --wordlist=/home/champuser/rockyou.txt /home/champuser/week6/galadriel.crack.password.txt

Note that in order to get the wordlist I first had to extract the file and then point JtR to the extracted file.

In this scenario, I ran into difficulty with JtR, so after a significant amount of troubleshooting I changed course and approached cracking hashes with the unshadowed users (boromir, gandalf.grey, and galadriel):

hashcat -m 1800 -a 0 -o cracked.txt /home/champuser/week6/boromir.gandalf.crack.password.txt /usr/share/rockyou.txt

The command above shows hashcat cracking the hashes from the unshadowed file, containing both Boromir and Gandalf's /etc/shadow entries merged with /etc/passwd. The -m is intended to specify the hash type. 1800 specifies "sha512crypt $6$, SHA512 (Unix)". This makes sense since the /etc/shadow entries specified "$6$". -a specifies attack mode, which when set to "0" means a straight attack mode. (See this documentation for more information/context on this) -o specifies the outfile--in this context, cracked.txt was the file the results are output to. After this, I specified the file path of the unshadowed file, and then finally, the file path to the wordlist. (Note that if these files are in the directory you're running the command in, you don't need to specify the file path).

I repeated this process with Galadriel's unshadowed file, yielding the same result at the end of each line in the output file, there's a plaintext password. I tested these passwords in the target environment and was able to log in via SSH with these passwords.

Reverse engineering the shadow file using Python

Here's the command I used to reverse engineer the shadow file using python:

python3 -c "from passlib.hash import sha512_crypt; print(sha512_crypt.hash('[PLAINTEXT_PASSWORD]',rounds=1000,salt='UvKLGar/VWtqFGCE'))"

Replace [PLAINTEXT_PASSWORD] with the plaintext password. Note that this script imports the SHA512 hashing algorithm, this would need to change should the shadow file use a different hashing algorithm. I ended up needing to add a ; to denote a new line and get this command working as expected.

Issues and Troubleshooting

My main point of failure in this lab involved John the Ripper. The syntax shown above has been checked against publicly available documentation, and I haven't been able to locate any solutions regarding the error output I've been getting. The scan searches for an incorrect hash type by default, and when I specify the proper format (what the 1800 designates in HashCat) the program fails to complete as expected.

UPDATE: After a brief conversation with a classmate and the professor, I was able to fix the JtR syntax so that it works as expected. The solution was to add an "=" from the --wordlist flag and connect it to the [WORDLIST_FILEPATH] parameter. This also allowed the command to run without specifying a hash type (ex. SHA512).

Questions/Reflection

This lab felt very different from anything else I've worked on before--I spent a considerable amount of time working with online documentation trying to troubleshoot John the Ripper and HashCat. Fortunately, I was able to get HashCat working properly and thus was able to retrieve the additional user account credentials. I ended up running the tools within the VM, which was inefficient at best--it took many hours to get the new account passwords, but it was ultimately successful. I spent time working with the different errors I got while using JtR, and even attempted recreating the processing of information, and unfortunately, nothing was yielding results with JtR. Pivoting to HashCat allowed me to be somewhat successful with this lab, and I intend to continue working with JtR and see if I can get it working properly.