May 02, 2022
Authentication hashes are stored and kept by operating systems. Really, they are just hashed values of passwords. It might be possible to brute force these, but oftentimes you would need some sort of privileged permissions in order to obtain them, so it is somewhat of a more difficult task.
Windows Authentication Hashes
In the case of modern Windows based operating systems, we have something called NThash as the hashing format. Devices running Windows store passwords of their users (or services) in this format. You’ve also probably heard of the term NTLM. The LM part refers to the older version of the Windows password hashing format. Thus, NT + LM → NTLM.
Historically, the NT was used with Windows NT to indicate that the system was not built on the MS-DOS, it also meant “New Technology” (at least in the beginning).
Generally, we would go on about these in a different way. We could maybe get those NTLM hashes by dumping the SAM db on our Windows machine from the Active Directory db – called NTDS.dit, or by using a tool such as Mimikatz. We can also get away with just doing the “pass the hash” attack instead of cracking the said hashes, but if there’s a bad password policy in place, cracking of those hashes is a bit more feasible.Example:
Let’s do a quick example, now that we’re a bit more familiar with the NTLM hashes!
We want to figure out the value of the following hash:
First, we ask John what formats does it know, so we specify:
Since John is familiar with both of the hash types we need, we go for it (using what we learned about John previously).
We tell John which format we want, and give it a wordlist – as we did before.
john --format=NT --wordlist=/usr/share/wordlists/rockyou.txt hashNT.txt
**hashNT.txt is just a file where we’ve added our NT hash**
In the blink of an eye, john returns the output, e.g. the cracked hash – baboon
We can check this for ourselves easily, for example here.
Of course, this was extremely fast mostly due to the fact that we’ve got an easy word here, but the principle remains the same.
Note that only the root user can view these hashes, so you would need to have a way of escalating your privileges to root before trying to crack hashes in the shadow file.
Since john can be quite picky with file formats, in order for it to understand the data that we’re giving it we have to combine the /etc/shadow files with /etc/passwd file. Luckily, John has an in-built tool that’s called unshadow.
The syntax for unshadow looks like this:
unshadow <path_to_password> <path_to_shadow>
Since in both passwd and shadow files one line corresponds to one user/user account in the system, we can either use unshadow on the whole shadow file (but then we need the whole passwd file) or we can find the corresponding lines from each of them.
Let’s see how this works in practice.
(the greater than sign tells john to use the two .txt’s and join them into a new one, called unshadowed.txt, something which we can operate on)
Our end result is the unshadowed.txt file, which looks like this:
Now, all that’s left for us to do is what we’ve been doing so far, and feed this to John – the way we learned.
We try first without specifying the format, since we’ve already made everything john-ready with our unshadowed.txt, but as we can see from the image above, john doesn’t like this so it can’t help us.
We know from the hash that its crypt (3) so we give john the format value of crypt, and try again:
As we can see the password for the root user is olive. On the right-hand side we can see some attempts that John has made before guessing correctly. One row below our result we can also see that it took 32 seconds – not bad!
Please note that the crypt (3) is a generic format and it is considered to be special, as its main purpose is to support any type of hash a system would support - even if its an unknown to john. In real systems, you should expect to see much more secure hashing algorithms used, like SHA256, SHA512, or SHA3.
(We used a burner VM for our testing purposes, so we didn’t care that much about security. Also, please note that the crypt (3) is a generice)
For example if the username is peter, some possibilities could include:
This is also known as word mangling. John is really just creating its own dictionary based on the data that has been given, and then it applies some rules to it. In this way, it exploits poor passwords that could be based on usernames, services, etc.
Some basic syntax when using single crack mode would look like this:
john --single --format=<format> <path_to_file>
with the --single telling John that we want to use single crack mode.
Before we show our example, please note that for John to understand our input, we need to add a prefix to our hash – our username.
We have our example hash, a SHA256 hash to be precise:
And we know it belongs to the user hacker, so we say:
We tell John:
john --single --format=raw-sha256 singlecrackmode.txt
(Where singlecrackmode.txt is just a one-liner containing hacker:1b3a10657a23bdd02d5262f375d5255a045b6ccfca4082ecaf7b0c1efea3dfad)
Almost immediately, john has figured out that our user with the username hacker, has h4cker for their password.
In this article we’ve covered some more options John has to offer – cracking authentication hashes for both Windows and Linux-based operating systems, as well as the single crack mode. Nevertheless, we still have interesting stuff to cover...
Just remember to crack responsibly & ethically, either on your systems or on systems that you’ve been given explicit permission for, otherwise you might end up in real trouble. Happy cracking!
How to test application with ZAP - Part TwoJenny R September 28, 2022
How to test application with ZAP - Part OneJenny R September 28, 2022
The World's Worst Hackers Have FlagsPaul Lighter September 27, 2022
Intro to Windows (Win32) APIacephale 4w September 26, 2022
State of the Union's Infrastructure Security According to CISAKent Weigle September 23, 2022