---
title: Cracking passwords with John the Ripper
course: intro_pentest
section: Exploitation
layout: lesson
---

It’s hard to imagine discussing a topic like the basics of hacking without
discussing passwords and password cracking. No matter what we do or how far we
advance, it appears that passwords remain the most popular way to protect data
and allow access to systems. With this in mind, let’s take a brief detour to
cover the basics of password cracking.

There are several reasons why a penetration tester would be interested in
cracking passwords. First and foremost, this is a great technique for elevating
and escalating privileges. Consider the following example: assume that you were
able to compromise a target system but after logging in you discover that you
have no rights on that system. No matter what you do, you’re unable to read and
write to the target’s files and folders, and even worse, you are unable to
install any new software. This is often the case when you get access to a low
privileged account belonging to the "_user_" or "_guest_" group.

If the account you accessed has no or few rights, you’ll be unable to perform
many of the required steps to further compromise the system.

Another reason for cracking passwords and escalating privileges is that many of
the tools we run as penetration testers require administrative-level access to
install and execute properly. It ain’t uncommon for penetration testers to find
themselves in a situation where they were able to crack the local administrator
password (the local admin account on a machine) and have this password to turn
out to be exactly same password that the Network Administrator was using for the
domain administrator account.

**Never, never, never use the same password for your local machine administrator
as you do for your domain administrator account.**

If we can access the password hashes on a target machine, the chances are good
that with enough time, John the Ripper (JtR), a password-cracking tool, can
discover the plaintext version of a password. Password hashes are … and can be
accesses remotely or locally. Regardless of how we access the hash file, the
steps and tools required to crack the passwords remain the same. In its most
basic form, password cracking consists of two parts:

1. Locate and download the target system's password hash file
2. Use a tool to convert the hashed (encrypted) passwords into a plaintext
   password

Most systems don’t store your password as the plaintext value you enter, but
rather they store an encrypted version of the password. This encrypted version
is called a hash. For example, assume you pick a password “qwerty" ” (which is
obviously a bad idea). When you log into your PC, you type your password
“qwerty" to access the system. However, behind the scenes your computer is
calculating and checking an encrypted version of the password you entered. This
encrypted version or hash of your password appears to be a random string of
characters and numbers.

"qwerty" encoded in MD5: `d8578edf8458ce06fbc5bb76a58c5ca4`

Different systems use different hashing algorithms to create their password
hashes. Most systems store their hashes in a single location. This hash file
usually contains the encrypted passwords for several users and system accounts.
Unfortunately, gaining access to the password hashes is only half the battle
because simply viewing or even memorizing a password hash (if such a thing were
possible) ain’t enough to determine the plaintext. This is because technically
it ain’t supposed to be possible to work backward from a hash to plaintext. By
its definition, a hash, once encrypted, is never meant to be unencrypted.

Consider the following example: Assume that we’ve located a password hash, and
we want to discover the plaintext value. It’s important to understand that in
most cases we need the plaintext password, not the hashed password. Entering the
hashed value into the system won’t get us access because this would simply cause
the system to hash the hash (which is obviously incorrect). To discover the
plaintext version of a password, we need to circle through a series of steps.

First, we select a hashing algorithm, next we pick a plaintext word, third we
encrypt the plaintext word with the hashing algorithm and finally, we compare
the output or hash of the chosen word with the hash from our target. If the
hashes match we know the plaintext password because no two different plaintext
words should produce the exact same hash.

Although this may seem like a clumsy, awkward or slow process for a human,
computers specialize in tasks like this. Given the computing power available
today, completing the four-step process outline above is trivial for a modern
machine. The speed at which John the Ripper can generate password hashes will
vary depending on the algorithm being used to create the hashes and the hardware
that is running John the Ripper. It’s safe to say that even an average computer
is capable of generating millions of Windows (LM) password guesses every second.
John the Ripper includes a nifty feature that allows you to benchmark your
computer’s performance. This benchmark will be measured in cracks per second
(c/s). You can run this by opening a terminal window and issuing:

```
john --test
```

This will provide you with a list of performance metrics and let you know how
efficient your system is at generating guesses based on your hardware and the
algorithm being used to hash the passwords.

Before we can crack passwords, we first have to locate the password hash file.
As mentioned earlier, most systems store the encrypted password hashes in a
single location. In Windows-based systems, the hashes are stored in a special
file called the SAM (Security Account Manager) file. On NT-based Windows systems
including Windows 2000 and above, the SAM file is located in the
`C:\Windows\System32\Config` directory. Now that we know the location of the SAM
file, we need to extract the password hashes from the file. Because the SAM file
holds some very important information, Microsoft has wisely added some
additional security features to help protect the file.

First the SAM file is locked when the operating system boots up. This means that
while the OS is running we don’t have the ability to open or copy the SAM file.
  In addition to the lock, the entire SAM file is encrypted and not viewable.

Fortunately, there’s a way to bypass both of these restrictions. On a remote
machine, we can use the Meterpreter and SAM Juicer to access the hashes on a
live target. If we’ve physical access to the system, we can also boot to an
alternative operating system like BlackArch. By booting our target to an
alternate operating system, we’re able to bypass the Windows SAM lock. This is
possible because the Windows OS never starts, the lock never engages, and we’re
free to access the SAM file. Unfortunately, the SAM file is still encrypted, so
we need to use a tool to access the hashes. Fortunately, the required tool is
built into BlackArch.

After booting the target system to an alternate operating system, the first
thing you need to do is to mount the local hard drive. Be sure to mount the
drive containing the Windows folder. We can accomplish this by opening a
terminal and typing:

```
mount /dev/sda1 /mnt/sda1
```

It’s important that you mount the correct drive as not all systems will have a
"`/dev/sda1`". If you’re unsure about which drive to mount, you can run the
"`fdisk -l`" command. The fdisk tool will list each of the drives available on
your target system and should help you determine which drive you need to mound.
You may also need to create a mount point in the “/mnt” directory. To do so, you
can simply use the `mkdir` command.

```
mkdir /mnt/sda1
```

Once you have successfully mounted the local drive in BlackArch, you’ll be able
to browse the Windows “`C:\`" drive. You should be able to navigate to the SAM
file. You can do so by typing the following command into a terminal window:

```
cd /mnt/sda1/Windows/system32/config
```

If everything has gone as planned, you should be in the directory containing the
SAM file. To view the contents of the current folder issue the "`ls`" command
in the terminal window, you should see the SAM file.

In step 1 we issue the “`fdisk -l`" command to view the available drive on the
local disk. In step 2, fdisk responds back by stating that there is a drive at
"`/dev/sda1`". In step 3 we use this information to mount the drive into our "`/mnt/sda1`"
folder so that we can access the local hard drive. Now that our drive is mounted
and available, in step 4, we move into the directory containing the SAM file by
using the "`cd`" (change directory) command. In step 5 we verify that we are in
the proper directory by issuing the "`ls`" command to list the contents of the
current folder. Finally, step 6 shows the SAM file.

Now that we’ve located the SAM file, we can use a tool called Samdump2 to
extract the hashes. At this point, we have the ability to view and copy the SAM
file, in effect overcoming the first security feature, but at this point the SAM
file is still encrypted. To view an unencrypted copy of the SAM file, we need to
run Samdump2. Samdump2 utilizes a file on the local machine called “system” to
decrypt the SAM file. Fortunately, the “system” file is located in the same
directory as the SAM file.

To run Samdump2, we issue the "`samdump2`" command followed by the name and
location of the “`system`" file, located by the name and location of the SAM
file we want to view. Recall that earlier we had issued the "`cd`" command to
navigate to the "`Windows/system32/config`" folder. At this point, we can
extract the contents of the SAM file by running the following command in a
terminal:

```
samdump2 system SAM > /tmp/hashes.txt
```

This will invoke the Samdump2 program and appending the “ > hashes.txt” will
save the results to a file called “hashes.txt” in BlackArch’s /tmp directory.

Now that we have the password hashes saved, we need to transfer them off the
live BlackArch disk. This can be done by simply e-mailing the hashes.txt file to
yourself or inserting a thumb drive and creating a local copy of the hashes.
Either way, make sure you save the hashes.txt file because you are working off a
“live” CD and your changes ain’t persistent. This means that when you reboot all
the files you created in the BlackArch disk will be gone.

Now that you have a copy of the password hashes, you can begin the process of
cracking the passwords. To accomplish this task, we’ll use a tool called John
the Ripper. Like each of the other tools we have examined, John The Ripper is
available for free. You can download it by going to
http://www.openwall.com/john. Before we begin utilizing John the Ripper, it’s
important that you understand how Microsoft creates password hashes.

Originally Microsoft utilized a hashing algorithm called Lan Manager (or LM for
short). LM hashes suffered from several key weaknesses that made password
cracking a trivial task. First, when LM hashes are created, the entire password
is converted to uppercase. Converting all the characters used in a password to
uppercase is a fundamental flaw that greatly reduces the strength of any
password. This is because technically if we hash the word “Password” and
“password”, although they are only different by a single case of a single
letter, these two words will produce a different hash output. However, because
LM hashes convert every character to upper case, we greatly reduce the number of
guesses we need to make. Instead of requiring an attacker to guess “Password”,
“password”, “PASsword” and so on, with every possible combination of upper and
lower case letter, the attacker only needs to make the single guess of
“PASSWORD”.

To further compound this issue, every Lan Manager password is 14 characters in
length. If a password is less than 14 characters, the missing letters are filled
with null values. If a password is greater than 14 character, the password is
truncated at 14 characters.

The final nail in the coffin of Lan Manager passwords (as if it needed another)
is the fact that all sorted passwords, which are now 14 characters in length,
actually get split in half and stored as two individual 7-character passwords.
The length of a password is one source of strength; unfortunately, because of
the LM design, the max password that needs to be cracked is 7 characters. John
will actually attempt to crack each of the 7-character halves of the password
individually and typically makes very short work out of it.

Take a moment to consider these flaws. When taken together, they represent quite
a blow to the security of any system. Suppose our favourite Network Admin, Ben
Owned is utilizing LM hashes on his Windows machine. He is aware of the dangers
of weak passwords, so he creates the following password, which he believes is
secure: SuperSecretPassword!@#$.

Unfortunately for Ben, he’s operating under a false sense of security. His
complex password will actually undergo a series of changes that make it much
less secure. First, the password is converted to all uppercase:
SUPERSECRETPASSWORD!@#$. Next, the password is truncated to be exactly 14
characters, with any remaining letters simply discarded. The new password is:
SUPERSECRETPAS. Finally, the password is broken into equal halves of 7
characters, each: SUPERSE and CRETPAS.

When a hacker or penetration tester gets ahold of Ben’s password, the attacker
has to crack two simple, all-uppercase, 7-character passwords. That is a
drastically simpler task than the original password of SuperSecretPassword!@#$.

Fortunately, Microsoft addressed these issues and now uses a much more secure
algorithm called NTLM to create its password hashes. However, as a penetration
tester you’ll still find systems which are utilizing and storing LM hashes.
Modern versions of Windows don’t use nor store LM hashes by default; however,
there are options to enable LM on these systems. This “feature” is implemented
to support backward compatibility with legacy systems. As a side note, you
should always upgrade or discontinue the use of any legacy software that
requires you to use LM hashes. Old systems often put your entire network at
risk

John the Ripper is capable of cracking passwords by using a password dictionary
or by brute forcing letter combinations. As we discussed earlier, password
dictionaries are lists of words and letter combinations. One advantage of using
a password dictionary is that it’s very efficient. The main disadvantage of this
technique is that if the exact password ain’t in the dictionary, John the Ripper
will be unsuccessful. Another method for cracking passwords is to brute force
letter combinations. Brute forcing letter combinations means that the password
cracker will generate passwords in a sequential order until it has exhausted
every possible combination. For example, the password cracker will begin by
guessing the password as a single letter “a”. If that guess is unsuccessful,
it’ll try with “aa”. If that guess is unsuccessful, it’ll move to “aaa” and so
on. This process is typically much slower than a dictionary guessing attack, but
the advantage is that given enough time, the password will eventually be found.
If we try every letter in every possible combination, there is simply nowhere
for a password to hide. However, it’s important to point out that brute forcing
  passwords of significant length and cipher would take many lifetimes to
  crack.

John the Ripper is built into BlackArch. To run it, we can simply enter the
following command into a terminal:

```
john
```

You can issue the following command:

```
john /tmp/hashes.txt
```

In the command above “john” is used to invoke the password cracking John the
Ripper program. The next command “/tmp/hashes.txt” is used to specify the
location of the hashes that we extracted using Samdump2. If you saved your
hashes.txt to a different location, you’ll need to change this path.

If your target machine is using NTLM hashes, you’ll need to add the
"`--format=NT`" switch. In this case, the command would look like the
following:

```
john /tmp/hashes.txt --format=NT
```

After issuing the appropriate command to instruct John the Ripper to run, the
program will attempt to crack the passwords contained in the hashes.txt file.
When John is successful in finding a password, it’ll display it to the screen.

Below you’ll find a brief recap of the steps used to crack Windows passwords.
It’s important that you practice and fully understand how to fully complete each
of the steps below. If you’re given physical access to a machine, you should be
able to complete steps 1-4 in less than five minutes. The time it takes to
complete step 5, the actual cracking of the passwords, will vary on your
resources and the quality or strength of the passwords you are cracking. You
should also become comfortable enough with each of the steps that you can
perform them without the aid of notes or a cheat sheet:

1. Shut down the target machine.
2. Boot the target to BlackArch.
3. Mount the local hard drive.
4. Use Samdump2 to extract the hashes.
5. Use John the Ripper to crack the passwords.

The process of cracking Linux and OSX password is much the same as the method
described above with a few slight modifications. Linux systems don’t use a SAM
file to store the password hashes. Rather the encrypted password hashes are
contained in a file called the “shadow” file which is located at: "`/etc/shadow`"

However, before you can use the "`/etc/shadow`" file with John the Ripper, it
must be joined with the "`/etc/passwd`" file. In many respects this is similar
to how we had to use the “system” file with the SAM file to extract Windows
password hashes. John the Ripper includes a function to combine shadow and
password files so you can continue cracking the password. To accomplish this
task, you need to use the "`unshadow`" command, which is built by default into
BlackArch. To accomplish this, issue the following command in a terminal:

```
unshadow /etc/passwd /etc/shadow > /tmp/linux_hashes.txt
```

This command will join the “/etc/passwd” with the “/etc/shadow” file and store
the results in a file called “linux_hashes.txt” in the “/tmp” directory.

Now that we’ve extracted the hashes, we’re almost ready to begin cracking the
Linux passwords. However, before we can start, we need to use a version of John
the Ripper that supports cracking different types of password hashes. If you are
using a wrong or unpatched version of John the Ripper, the program will return a
message saying “No password hashes loaded”. Most modern Linux systems store
their passwords using the SHA hashing algorithm. With this in mind, we have to
choices: we can either patch the version of John the Ripper or download a
prepatched version. If you are unfamiliar with the patching process and manually
compiling Linux source code, it may be easier to find a prepatched version that
supports SHA hashes. Once we’ve the correct version of John the Ripper running,
we can complete this task by issuing the following command:

```
john /tmp/linux_hashes.txt
```

John the Ripper contains many more options and switches that can be used to
greatly improve your cracking time and chances to success. You should see our
Password Cracking course.
