John The Ripper Example

[Trinidad Baltzell]

Iam practicing reversing md5 hashed passwords using John the Riper and was curious about some behaviour. I added the md5 hash of zaa to the top of the file with the hashes and when I ran john passwordFile.txt it reversed the hash to find zaa very quickly, but when I set it to incremental mode...well it's still running. How does incremental mode work? It has sucesffuly reversed other passwords like

UPDATE: I have observed what I believe is the fact that john never outputs the same password more than once, even between successive invocations (unless --show option is specified). For example if a wordlist is used and cracked a password myname123 then running john again in incremental mode, won't in fact print myname123 again; you need to do john samefile.txt --show to get it to output (I think it caches the cracked passwords). My reasoning is from what I observed, another part is the statement answering why no passwords may be hashed:

All of the password hashes found in the file (that are of the same type as the very first recognized hash in the file unless you're using the "--format=..." option) might be already cracked by previous invocations of John

Incremental mode is not meant to be used with a wordlist. Incremental mode allows you to bruteforce a character space such as lowercase letters. For the example of the lowercase character space the bruteforce would start at one character, try all the combinations, move to two characters, and repeat until the password is cracked.

As noted here, incremental mode uses trigraph frequencies to prioritize the order of attempted passwords. It comes with a set of pre-generated "charsets" that define a cracking order based on statistics from cracked passwords.

The charsets are generated by the code here based on the character combinations and character positions in passwords that have already been cracked, then some additional sorting is done here to prioritize the "most likely" passwords.

As you can see it skips back and forth between different lengths, trying what is "most likely" first based on the statistics of the passwords used to generate the charset (obviously with only 2 passwords it doesn't have much to go on).

Because John the Ripper (JtR) had found/cracked your hash already and saved in the file john.pot so that you don't see the password cracked again when you ran John in the incremental mode.You could empty the file john.pot (make the file empty) so that you could see John the Ripper crack your hash in the incremental mode.

Password crackers can be online or offline. Online password crackers, such as Hydra, are used when brute-forcing online network protocols and HTML forms. Situations where online brute forcing might be impractical include a remote system that limits the rate of sign-in attempts or a system that locks users out indefinitely after a predefined number of invalid login attempts.

In these scenarios, an offline password cracker attempts to gain access to a password where it is stored instead of using a brute-force attack strategy. Since systems and applications rarely store passwords without cryptographic protection, passwords must be cracked to make use of them.

A popular offline password cracker is John the Ripper. This tool enables security practitioners to crack passwords, regardless of encrypted or hashed passwords, message authentication codes (MACs) and hash-based MACs (HMACs), or other artifacts of the authentication process.

Editor's note: It is possible to use John the Ripper -- and any password cracker -- lawfully and unlawfully. It is up to you to ensure your usage is lawful. Get the appropriate permission and approval before attempting to crack passwords, and handle the information obtained ethically. If you are unsure whether a given usage is lawful, do not proceed until you have confirmed that it is -- for example, by discussing and validating your planned usage with your organization's counsel.

The tool is also notable for its ubiquity and accessibility. It's included in the default repositories for many Linux distributions, including Debian and Ubuntu, and installed by default in most penetration testing distributions, including Kali and BlackArch. A snap install of it is available, along with multiple container options in Docker Hub.

Simply put, John cracks passwords. It attempts to replicate the password-handling functionality of a target storage mechanism so that numerous password values can be attempted without relying on password validation.

Before using John the Ripper, one important note: We're using VMs to illustrate usage. In the case of this tool specifically, performance is important. Consider the relative advantages and disadvantages of using virtualization and the context. For example, you might find an IaaS where paying for CPU time can be an expensive proposition. Or you might get better performance running the tool on a host OS rather than a guest.

That aside, John is simple to use. At a minimum, you need to specify the stored password values you want to crack. If you provide no information other than that, the tool tries to figure out what format the stored values are in and assumes a set of constraints about what you might want to do. That said, in most cases, you should provide more information to allow the tool to operate most effectively.

While not necessary in every case, it's helpful to know the format passwords are stored in. This is because applications might manipulate formats in ways John might not expect -- a web application, for example, might Base64- or URL-encode values before storing them. It's also helpful because the built-in mechanisms used by John to determine type and format can be wrong. Consider two similar-in-format but vastly different values: an MD5 hash and an MD5 keyed hash. The outputs are identical in format, but the processes that led to the outputs are anything but. John wouldn't know the difference, unless you provide the missing information.

Figure 2 illustrates using the unshadow command. This is distributed with John the Ripper in most packages. It combines the contents of /etc/passwd and /etc/shadow on a Linux VM, in this case, Kali. Then, we used the john command and specified the format -- in this case, the crypt mechanism. Since we haven't told it what cracking mode to use, John begins with single crack and then proceeds to wordlist -- none was specified, so it used the default. Ultimately, it will move to incremental mode.

In a more complicated example, Figure 3 shows an attempt at cracking Microsoft Windows passwords. As with the Linux example, passwords must be put into a format John the Ripper can understand. To accomplish that, we used PwDump v8.2.

These values are fed into John the Ripper to crack in Figure 4. We specified wordlist mode and instructed it to use rockyou.txt, one of the built-in wordlists that comes by default with most security-focused Linux distributions. Note that you may need to extract the text file first. The passwords were set to weak values -- dictionary words in all cases -- to enable the cracking to complete quickly. These two examples demonstrate the most universally applicable and most basic usage of John the Ripper. For more advanced usage, you may need to get a little creative. Sometimes, the format of stored password values you can obtain are not in one of the formats supported by John out of the box. With a few clever modifications, however, you can convert to one of those with a little research.

In this article we are going to show how we can crack /etc/shadow file using John the Ripper. It is common in CTF like events to somehow get access to the shadow file or part of it and having to crack it so you can get the password of a user.

The process involves two basic steps, the first is called unshadowing while the second is the cracking itself. Unshadowing is a process where we combine the /etc/passwd file along with the /etc/shadow in order for John to be able to understand what we are feeding to it. Unshadow is a tool that handles this task and it is part of the John package. In order to unshadow the shadow file we need to also have the equivalent line from the passwd for the user of our interest. An example is the following:

Next and final step is to actually start the cracking with John. It is up to you which cracking method you will chose, though a bruteforcing using a wordlist is usually enough for CTFs. An example attack using a wordlist would be launched like below

Where as we see John managed to crack the password of the user root as it was included in the wordlist used.

If you would like to print all the passwords John managed to crack you may run john --show unshadowed.txt and you will get something like:

In this article we showed how John the Ripper can be used to crack the hashed password of a user that can be found in the /etc/shadow file. The process is pretty simple and straightforward yet if you find yourself stuck somewhere please feel free to reach out to me.

I often hear rumors about how fast a password hash (such as a linux passwd/shadow hash) can be cracked today by using modern GPU's. Basically what I heard recited by many was, that a kid with a fast gamer notebook with a decent graphics card could brute-force a password hash within hours by leveraging the power of the GPU.

I am not a security expert and by no means a Hacker, but i've wanted to try the script-kiddie approach myself hands on for a long time already. I was recently tasked with stress-testing some systems in our lab with significant compute power. One of them was a 128 core AMD ROME based server, the other one one was a GPU server with 8x NVIDIA RTX 2080Ti in it. So finally i took this opportunity to verify or bust the myth, that a teenager with a gamer notebook can crack your password hash in a few hours.

Well Spoiler alert: the myth is absolutely busted, IF your password is a safe password, meaning, it is not on a password list and of significant length. Once the wordlist based approach fails, the only option left to track is to brute-force the password, which means, to try all possible combinations of all possible characters of a password. Now if we know a password policy, that actually might help to narrow down the possible passwords and accelerate the brute force attack slightly by being able to remove un-allowed passwords (like for example all passwords that don't contain at least one upper and lowercase letter and digit, if our policy demands all three are present in a password). So ironically, the more restricting your policy, the less permutations are possible and the easier it is to crack your password.. so be careful what you wish for by publishing password policies ;)

3a8082e126