John the Ripper in Practice: From Hash Extraction to Rule-Based Cracking

Tools & Defense
2025.12.21
Time it takes to read this article 6 minutes.

Introduction / Overview

John the Ripper (JtR) is one of the oldest and most flexible password crackers in the offensive-security toolbox. Where Hashcat shines on raw GPU throughput, John shines on its enormous ecosystem of *2john companion tools, its rich rule engine, and its ability to auto-detect hash formats. In this article you will learn how to extract hashes from real artifacts (ZIP archives, KeePass databases, SSH keys, Linux shadow files), how John detects formats, and how to drive wordlist and rule-based attacks effectively. We close with a Blue Team section that carries equal weight to the offensive material.

Legal & ethical disclaimer. Everything below is for education and for authorized testing on systems you own or have explicit written permission to test. Cracking password hashes you do not own — or attempting to without scope — is illegal in most jurisdictions. Stay inside your engagement rules of engagement.

How it works / Background

A password hash is a one-way transformation of a secret. Cracking does not "reverse" the hash; it guesses candidate passwords, applies the same hashing function, and compares the output to the target. Modern schemes (bcrypt, scrypt, Argon2, PBKDF2) deliberately slow this down with high iteration counts and per-hash salts, while legacy or misconfigured ones (raw MD5, NTLM, unsalted SHA1) fall quickly.

John ships in two main builds. The upstream version is fine, but for serious work use John the Ripper "Jumbo" (openwall/john), which bundles hundreds of formats and the *2john extractors. The community-jumbo build adds OpenMP and OpenCL support.

John operates in several cracking modes:

  • Single crack — derives candidates from the username/GECOS fields. Fast first pass.
  • Wordlist mode — iterates a dictionary, optionally mangled by rules.
  • Incremental — Markov-driven brute force based on character statistics.
  • Mask/external — templated brute force and custom logic.

Prerequisites / Lab setup

Install the Jumbo build. On Debian/Kali the john package is already the jumbo fork; from source it is straightforward:

sudo apt update && sudo apt install -y john   # Kali/Parrot

# Or build jumbo from source for the latest formats
git clone --depth 1 https://github.com/openwall/john.git
cd john/src
./configure && make -s clean && make -sj4
ls ../run/   # john + the *2john tools live here
Bash

Confirm the build and list the available *2john extractors:

john --list=build-info
ls /usr/sbin/*2john 2>/dev/null; ls ../run/*2john.py 2>/dev/null
Bash

Attack walkthrough / PoC

1. Extracting hashes with the *2john tools

John cannot read a .zip or .kdbx directly — you first convert the artifact into a hash string John understands. The naming convention is consistent: zip2john, keepass2john, ssh2john, rar2john, pdf2john, office2john, and many more.

# Encrypted ZIP archive
zip2john secret.zip > zip.hash

# KeePass database (KDBX)
keepass2john Database.kdbx > keepass.hash

# Password-protected SSH private key
ssh2john id_rsa > ssh.hash

# Microsoft Office document
office2john confidential.docx > office.hash
Bash

For Linux local accounts, combine /etc/passwd and /etc/shadow with unshadow:

unshadow /etc/passwd /etc/shadow > linux.hash
Bash

The output line embeds the format tag, for example a $6$ prefix for SHA-512 crypt or $keepass$*... for KeePass.

2. Format detection

John auto-detects most formats from the hash structure, but you should verify rather than trust. Use --list=formats to enumerate, and run a dry pass to confirm the chosen format:

# Search the supported format list
john --list=formats | tr ',' '\n' | grep -i keepass

# Let John guess, then read the banner it prints
john keepass.hash --wordlist=/usr/share/wordlists/rockyou.txt
# -> "Using default input encoding: UTF-8"
# -> "Loaded 1 password hash (KeePass [SHA256 AES 32/64])"
Bash

When detection is ambiguous (raw MD5 vs. NTLM, both 32 hex chars), force the format explicitly:

john --format=NT hashes.txt --wordlist=rockyou.txt
john --format=raw-md5 hashes.txt --wordlist=rockyou.txt
Bash

Guessing the wrong format is the single most common reason a known password "won't crack."

3. Wordlist mode

The bread-and-butter attack. Point John at a dictionary such as rockyou.txt:

john --wordlist=/usr/share/wordlists/rockyou.txt zip.hash
Bash

Cracked results are stored in ~/.john/john.pot. Re-display them at any time:

john --show zip.hash
john --show --format=NT ntlm.hash
Bash

4. Rules — turning one word into thousands

Rules mutate each wordlist entry (append digits, capitalize, leetspeak, etc.), dramatically expanding coverage without a bigger dictionary. Enable the built-in best64-style sets:

# Apply the default jumbo rule set
john --wordlist=rockyou.txt --rules zip.hash

# Use a named rule set defined in john.conf
john --wordlist=rockyou.txt --rules=Jumbo office.hash
john --wordlist=rockyou.txt --rules=KoreLogic linux.hash
Bash

You can author custom rules in john.conf (or /etc/john/john.conf). Rule syntax is compact; for example, append two digits to every candidate:

[List.Rules:Append2Digits]
$[0-9]$[0-9]
Plaintext
john --wordlist=base.txt --rules=Append2Digits target.hash
Bash

5. Single and incremental modes

When you have usernames, run single mode first — it is fast and surprisingly effective against passwords derived from account names:

john --single linux.hash
Bash

For an exhaustive fallback, incremental mode brute-forces using character frequency statistics:

john --incremental=ASCII --max-length=8 fast.hash
Bash

6. Performance and resuming

John checkpoints automatically. If a long run is interrupted, resume it:

john --restore
john --status        # show progress of a running session
Bash

If you have a strong GPU, you can hand the same hash to Hashcat; John and Hashcat understand overlapping formats and the two pair well in practice. See our companion guide on NTLM relay and capture for where these hashes come from in AD environments.

Mermaid diagram

John the Ripper in Practice: From Hash Extraction to Rule-Based Cracking diagram 1

The diagram shows the flow from a target artifact, through a *2john extractor and format detection, into John's cracking modes, ending either in a recovered plaintext stored in john.pot or a feedback loop to tune the attack.

Detection & Defense (Blue Team)

Password cracking is overwhelmingly an offline activity, so defense focuses on (a) preventing hash exfiltration, (b) making hashes expensive to crack, and (c) detecting the upstream theft that feeds the cracker.

Prevent hash access.

  • Restrict access to /etc/shadow (root-only, mode 0640 root:shadow) and protect the Windows SAM/NTDS.dit. Bulk reads of NTDS.dit map to MITRE ATT&CK T1003.003 (OS Credential Dumping: NTDS); monitor Volume Shadow Copy creation and ntdsutil/vssadmin usage.
  • Treat any handoff of encrypted archives, KeePass .kdbx, or SSH private keys as sensitive — these are exactly what *2john consumes.

Make hashes expensive.

  • Use modern, slow, salted algorithms: Argon2id or bcrypt for application passwords; ensure Linux uses yescrypt/SHA-512 with a high rounds count in /etc/login.defs and /etc/pam.d. Avoid raw MD5/SHA1 and unsalted schemes entirely.
  • In Active Directory, disable NTLM where possible and enforce strong, long passphrases. NTLM (T1003.002) is unsalted and falls quickly to rule-based attacks.

Policy and detection.

  • Enforce length-first password policy (15+ characters or passphrases). Length defeats rules and incremental mode far better than complexity churn.
  • Screen new passwords against breach corpora (the same rockyou-style lists attackers use) with tools like Azure AD Password Protection or a local banned-password list.
  • Deploy MFA so a cracked single factor is insufficient.
  • Detect the precursors: alert on access to shadow/SAM/NTDS, on LSASS handle opens (T1003.001), and on transfer of credential-bearing files. By the time John runs, the data is already off your network — your telemetry signal is the theft, not the crack.

Detect weak passwords proactively. Run John yourself against your own hash dumps during authorized audits to find weak credentials before an attacker does, then force resets. This is a legitimate, high-value use of the tool. For the broader credential-access picture, see Kerberoasting explained.

Conclusion

John the Ripper remains indispensable precisely because of its breadth: the *2john family turns almost any encrypted artifact into a crackable hash, its format detection reduces friction, and its rule engine multiplies the effectiveness of any wordlist. The defensive lesson is symmetric — because cracking happens offline and silently, the only durable mitigations are slow salted algorithms, length-first password policy, MFA, and tight monitoring of the credential stores that feed the cracker in the first place.

References

Comments

Copied title and URL