Password Hunting Part 1
There are multiple locations we can search for passwords (hashed and clear-text) on a Linux machine. These passwords can be used for multiple things. Sometimes the passwords will show you a clear text password for an administrator user, or even the root user. Sometimes these passwords will be used to pivot to another user on the machine, then from there you can escalate your privileges. Other times, the passwords may be used to login to other services running on the machine. The possibilities are endless, but anytime you can find passwords on a machine, it’s usually good news. And always remember to try found passwords on everything.
Users and Password Hashes
The first thing I like to do is list out the contents of the /etc/passwd file. This usually doesn’t contain password hashes, but it contains a list of usernames on the machine. A lot of the users listed are actually system users that are required to run certain processes. To filter out actual users on the system, we can try running the command cat /etc/passwd | grep bash. This will list out users that have the /bin/bash shell set as their default.
As we can see, there are two main users on this system, root and user. This doesn’t mean we are limited to only these two users, but now we know these are users on the system with home directories and aren’t system processes.
Just from this alone, we can try to guess easy passwords for the users. If user is a sudo user, they have the ability to escalate their privileges to root. What if there was a system administrator and they were super lazy so they made their username and password user:user? Or user:password? These are things to consider when looking at users. Nothing is “too easy”. People get lazy and sometimes make things easier for themselves, but that also makes it easier for attackers. This is why it’s good to try everything.
The next thing I always check, but almost never works, is trying to list out the contents of the /etc/shadow file. This is a protected file that is only readable by the root user. It contains hashed versions of the passwords. If for some reason the owner of the machine decided to change the permissions on the /etc/shadow file so anyone could read it, then these hashes could be taken offline and cracked using a password cracker. Let’s say we are able to read the /etc/shadow file for some reason and we get the hash for the root user.
There are lots of tools out there such as hash-identifier that can help in identifying a has type. But it’s not always accurate. As you can see below, the hash-identifier program thinks we are dealing with a SHA-256 hash when really this is a SHA-512 hash.
How did I know this? If you look at the first part of the password hash, you will notice it starts with the string $6$. This is the identifier of the password hash. Below is a table of a few common password hashing algorithms you may see:
$1$ MD5$2a$ Blowfish$2y$ Blowfish$5$ SHA-256$6$ SHA-512
The next part of the password hash is called the salt. This will follow directly after the identifier. In this case, the salt is Tb/euwmk. Following the salt, there will be another $ character and the actual hashed password will be show. In this case it is
So, what do we make of this? Let’s try to crack this password using a powerful tool I like called HashCat. These are the steps I would follow to potentially crack this password. This should not be run in a virtual machine if possible. It should be run on an actual host machine:
First navigate to hashcat’s website to see what type of hash-type code we will be using.
I search the page for sha512 and see a match. The code we will be using is 1800.
I save a copy of the hash (including salt and identifier) in a text file called hash.txt
I locate a copy of wordlist. In this case we will use the crackstation.txt word list.
We then run the following command to crack the hash:
hashcat -m 1800 -a 0 -o cracked.txt ~/hash.txt ~/crackstation.txt --force -O
- We see the output below, and we have successfully cracked the password! The password is password123
We can use this new password to become the root user.
The above example is merely an example to give you an idea of how to deal with hashed passwords and why they can be useful. You probably won’t witness the exact scenario above, but it can happen.
An interesting privilege escalation method I saw one time in a CTF was I had a world-writeable /etc/passwd file, and I was able to get root by simply typing in these commands:
cp /etc/passwd /etc/passwd.bakecho root::0:0:root:/root:/bin/bash > /etc/passwdsumv /etc/passwd.bak /etc/passwd
Usually the /etc/passwd file will have an X after the username to signify that a password is necessary. In this case, we have just overwritten the entire file with a root user that does not require a password by omitting the X. In the example above, we make a copy of the original file, we overwrite it, we become root, then we restore the original file. This again is not a common thing to see in production Linux machines, but it is something to keep an eye out for.
This article is getting a little long so I’m going to split it into multiple parts.