When working with security-related issues, one common challenge is dealing with passwords that we don't know. For example, during an authorized security assessment, we may obtain a password hash from a database or another source.

But there is one problem. We don't have the original password.

The password is usually not stored directly. Instead, applications should store passwords using a password-hashing mechanism.

So, if all we have is the hash, we cannot simply read the original password from it.

We have to test possible passwords and determine whether any of them produce a matching result. This is where password-auditing and password-recovery tools can help.

Hello everyone, and welcome to a new video. In this article, we're going to learn about a popular password-auditing tool called John the Ripper, commonly known as John.

We'll understand: 

1. what this tool does 
2. how they work and 
3. how we can use it safely in a controlled laboratory environment. 

So, let’s get started.

Introduction to JTR

John the Ripper is a widely used, open-source password auditing and password recovery tool. Its main purpose is to test the strength of passwords by working with password hashes and other supported password-protected formats.

Features and capabilities of John the Ripper

• John the Ripper can handle various password hash formats, making it compatible with different systems and databases.
• It offers multiple attack modes, including brute-force, dictionary, and hybrid attacks, providing versatile options for cracking passwords.
• John the Ripper is optimized for speed, utilizing multiple CPU cores and GPUs to accelerate the password-cracking process.
• Users can easily use their own wordlists and apply custom rules to generate password variations efficiently.
• Being an open-source tool, John the Ripper benefits from continuous support and contributions from the vibrant cybersecurity community.

Now we have a basic understanding of what John the Ripper is and why security professionals use it. But simply understanding the theory isn't enough.

To properly understand how a security tool works, we need to use that knowledge in a practical environment.

Supported Platforms and Environments

If we talk about Supported Platforms and Environments, John the Ripper is compatible with various operating systems, including Windows, macOS, Linux, and other Unix-like systems. 

It also works on different architectures, making it highly versatile and widely accessible.

For this demonstration, we'll be using Kali Linux.

Kali Linux is a Linux-based operating system specifically designed for penetration testing, security research, digital forensics, and other cybersecurity tasks. It comes with a large collection of security tools, including John the Ripper.

If you're using Kali Linux, John is generally available by default, so we don't need to spend time installing it. For Windows users, I'll cover the installation and usage of John the Ripper in a separate article.

Now, before we start our practical demonstration, let's understand a few important options that we'll be using:

The basic command structure looks like this:

Here:

• john starts the program.
• The OPTIONS tell John how we want it to perform the password-auditing task.
• And PASSWORD-FILES represents the file containing the password hashes or other supported data that we want John to process.

About the OPTIONS, John provides many different options for different situations. Run john with the help flag; it displays all options to use:

However, I am not going through every single option one by one, it will take time, there is a chance it looks more theoretic. The best way to understand these options is to see them in action.

So, instead of spending too much time on theory, we'll move into our lab and learn the important commands through practical examples.

Let's start with our Practical demonstration. 

Practical Demonstration

So, what are we going to do here?

• First, we'll create a password hash ourselves.
• Then, we'll use John the Ripper to test password candidates against that hash and see whether the original password can be recovered.

Everything in this demonstration is created inside our own lab environment. 

We'll use the mkdir command to create a new directory, and then we change the directory to it:

We are now inside our laboratory directory.

Next, we'll create a test MD5 hash.

For this demonstration, I'll use a simple test password. We can generate its MD5 hash by using the md5sum command-line tool:

Here, 

• the echo -n command outputs the password without adding a new line.
• The pipe symbol, or | sends that output directly to md5sum. 
• The md5sum command then calculates the MD5 hash of that text.

The result is the hash value that we'll use for our demonstration. Now, let's save that hash into a file called hash.txt.

We can use the echo command again, followed by the hash, and then use the redirection operator to write it into the file. 

As you can see, the hash has been stored inside hash.txt. 

Now we have our test hash, so let's see what happens when we give it to John. For the first attempt, we won't specify any additional options.

John will try to identify the hash format automatically and start using its configured default settings. Depending on the John build and the input, you may see a warning or a message indicating that the hash format was not identified as expected.

This is a good example of why understanding the hash format is important.

In our case, we already know that the hash we created is an MD5 hash.

So instead of relying on automatic detection, we can explicitly tell John which format to use. We'll use the --format option for this.

• Here, John knows that the value should be treated as a raw MD5 hash. If the correct password is present in the candidates John is testing, it can find a matching value.

When that happens, John reports the recovered password.

So, what exactly happened here?

• John did not decrypt the MD5 hash.
• Instead, it tested password candidates, calculated their MD5 values, and compared those results with our target hash.
• When one of the candidates produced the same hash, John reported a successful match.

Now let's consider a different situation. 

What happens if the password is more complicated? 

What if the password is not included in the candidates that John is currently using? 

This is where a wordlist becomes useful.

We can provide our own wordlist by using the --wordlist option. 

Let's create a second test password and generate its MD5 hash using the same method. And we'll then append that new hash to our existing file.

To add new content without replacing the existing data, we can use the >> redirection operator. After that, we'll use cat to verify whether both hashes are present or not.

Now, let's run John again with our specified format.

You may notice that John does not report a new password. That can happen for several reasons.

• One possibility is that the password isn't in the candidates being tested.
• Another possibility is that John has already processed that hash and stored the result.

So, let's provide our own wordlist.

A common example on Kali Linux is the rockyou.txt wordlist.

We can use it with rockyou.txt. The rockyou.txt file contains a large collection of password candidates. John will process those candidates and compare them against the hashes in our file.

But in our demonstration, the password we selected isn't in that wordlist. In that case, John is not able to recover it. This brings us to another useful technique.

We can create our own small wordlist containing the password candidates that we want to test.

Let's create a file called passwords.txt. 

In real security assessments, candidate lists can be created from many different sources, including password policies, previously known information, or password-generation and transformation techniques.

The important security lesson is that people often choose passwords based on information that is easy to remember. That can include names, dates, favorite words, phone numbers, or other predictable patterns.

Now our wordlist is ready. Let's use it with John to test the candidates from our custom wordlist against the hashes.

As you can see, the password has been recovered. 

Notice something interesting here.

Our hash.txt file contains two hashes. However, during the previous run, John reported only one newly recovered password.

So, what happened to the other hash?

The answer is that John keeps track of passwords it has already recovered. It stores these results in a password database, commonly known as the pot file.

So, when John sees a hash that it has already successfully recovered, it doesn't need to perform the same password testing again.

This is why you may see fewer new results, even though multiple hashes are present in the file.

Instead, we can use the --show option. The --show option displays passwords that John has already recovered for the hashes in the file. 

This is usually the better way to review previously recovered results. If you remove or reset John's password database, those results will no longer be available to John, and he may need to perform the work again.

The exact location of the pot file depends on the John installation and configuration.

Let me explain this using our previous example:

Now, when we run the john command with our wordlist and hash file, John displays a message like this:

“Loaded 2 password hashes with no different salts. No password hashes left to crack.”

So, what does this message mean?

It means John has already processed both hashes and has recovered their corresponding passwords. Because those results are already stored in John's pot file, there are no remaining hashes for John to process.

So, what happens if we delete the pot file?

Let's find out.

First, we need to locate John's pot file.

On a typical Linux installation, John's configuration and data are stored under a hidden directory within the .john directory inside the current user's home directory. 

The tilde (|) symbol is a shortcut that represents the current user's home directory. 

Run ls command along with the path to the .john directory.

Here, you see files such as john.log and john.pot.

The john.pot file is particularly important for this demonstration because it stores passwords that John has already recovered. Now, let's remove the john.pot file. This removes John's stored recovery history for the passwords it has already found.

Now, let's run the same John command again. This time, John no longer has the previous recovery results stored in its pot file.

So, it processes the hashes again. As you can see, the two passwords are now reported again. This demonstrates why John keeps a pot file: it prevents the tool from repeating work that it has already completed.

Now let's move to another important capability.

John the Ripper is not limited to simple hash files. It can also work with password-protected files and other supported formats.

John includes a collection of utilities whose names commonly end with *2john. These utilities convert password-protected files into a representation that John can process.

Let's see this with a ZIP archive.

First, we'll create a simple text file.

The secret.txt file has now been created.

Next, we'll create a password-protected ZIP archive. We'll use the zip command with the -e option.

The command asks us to enter a password for the archive.

After we provide the password, the protected.zip file is created.

Let's verify it.

Now we have our password-protected ZIP archive.

If we try to extract it using the normal unzip command, it asks for the password.

Without the correct password, we cannot extract the protected contents. But John the Ripper cannot simply take every protected file directly as input.

This is where a format-specific*2john utility comes into the workflow.

For ZIP archives, the utility is called zip2john. Its job is to extract the password-verification data from the ZIP archive and convert it into a format that John can process.

Let's first check whether the zip2john utility can be run directly from the terminal.

We can use the command:

 As you can see, the utility is available in the system's executable path, which means we can run it directly from the terminal without specifying the full path.

Now, we'll use it against our protected archive. Let's use it zip2john with our protected ZIP file.

Here, 

• protected.zip is our password-protected ZIP archive.
• The greater-than (>) symbol redirects the output from zip2john into a file called protected.hash.

When we run the command, zip2john extracts the password-verification data from the ZIP archive and writes that data into protected.hash.

The output is redirected into a new file called protected.hash. Let's inspect that file.

As you can see, the file now contains the extracted verification data in a format that John understands.

Now, we can provide that file to John.

If the correct password is present in our wordlist, John can identify it.

And there we have it. We now have the password that can be used to extract the password-protected zip file.

We've now demonstrated the complete workflow.

• First, we created a password-protected file.
• Then, we converted the file into a format that John could process.
• Finally, John tested the password candidates and recovered the password from our controlled laboratory example.

There are many other *2john utilities for different file formats and password-protected data.

The overall workflow is generally similar:

• Convert the supported file into a John-readable format.
• Then provide that output to John for password auditing.

We're not going to cover every supported format in this video, because the basic concept remains the same.

You can experiment with the other utilities safely in your own laboratory environment. And that's where we'll stop for this lesson.