Password Cracking and Wordlist Engineering Part 3: John the Ripper, Core vs Jumbo, and When to Reach for It

Part 2 covered hashcat, the GPU-first cracker this series leans on for the fast NTLM/Kerberos formats. This post covers the other major open-source cracker, John the Ripper — and a distinction that only became obvious by actually installing it rather than trusting a decade of tutorials that all assume the same thing.

The gotcha: apt install john is not what most Kerberoast writeups assume

Installing John the Ripper from Ubuntu’s repository and asking it what it can crack:

$ john
John the Ripper password cracker, version 1.8.0
Copyright (c) 1996-2013 by Solar Designer
...
--format=NAME              force hash type NAME: descrypt/bsdicrypt/md5crypt/
                           bcrypt/LM/AFS/tripcode/dummy/crypt

That’s the entire format list. No NTLM, no NetNTLMv2, no krb5tgs, no krb5asrep. This build doesn’t even support --list=formats — that flag itself doesn’t exist in this version, which dates to 2013. It’s “core” John the Ripper: Solar Designer’s original project, focused on Unix crypt formats (descrypt, md5crypt, bcrypt, sha512crypt via crypt), and it’s what every major Linux distribution’s package manager gives you by default.

Every tutorial that shows john --format=krb5tgs cracking a Kerberoast hash is using John the Ripper Jumbo — a community-maintained fork (openwall/john, branch bleeding-jumbo) that adds several hundred additional format plugins on top of core John, Kerberos and NTLM among them. Kali Linux ships Jumbo by default, which is exactly why this gap is invisible to anyone working from a Kali box — and exactly why it surprises anyone building a cracking environment from a stock Debian/Ubuntu install instead.

Confirming the format names against the actual source

Rather than guess at Jumbo’s exact --format string for each hash type, I pulled the real plugin source. krb5_tgs_fmt_plug.c defines:

#define FORMAT_LABEL         "krb5tgs"

And krb5_asrep_fmt_plug.c — which, worth noting, handles etype 17, 18, and 23 under one format name, unlike hashcat’s split between modes 18200/19700/19800 — defines:

#define FORMAT_LABEL            "krb5asrep"
#define FORMAT_NAME             "Kerberos 5 AS-REP etype 17/18/23"

That source file also ships embedded self-test vectors — real, public reference hashes bundled with the format for John’s own --test suite, drawn from published Kerberos captures rather than invented for this post:

{"$krb5asrep$23$8cf8eb5287e28a4006c064892150c4fb$3e05ecc...", "TheEmperor99!"},
{"$krb5asrep$23$771adbc2397abddef676742924414f2b$2df6eb2...", "P@$$w0rd123"},

(from a public MS14-068 exploit capture and a Kerberos sample pcap, respectively — both cited in the plugin’s own source comments). That $krb5asrep$23$... shape is exactly what Part 1 described and exactly what GetNPUsers.py produces — confirming Jumbo’s format expectations line up with Impacket’s actual output before ever pointing it at a real target hash.

Core John still earns its place — just not here

None of this makes core John useless; it means core John’s job is different from what this series needs. descrypt, md5crypt, bcrypt, and sha512crypt — the exact formats core John does support — are Unix/Linux local account hashes, and core John ships two genuinely useful helper utilities for that job: unshadow (merges /etc/passwd and /etc/shadow into the single-file format John expects) and unafs (does the same for AFS). If Part 8’s defensive discussion of sha512crypt’s cost factor needs a live crack against a real /etc/shadow entry, core John is the right and sufficient tool. It’s the AD-facing formats this series otherwise cares about — NTLM, Kerberoast, AS-REP — that require Jumbo specifically.

John’s syntax, and where it earns a place next to hashcat

Once running Jumbo (or core John, for its own formats), the flag surface differs from hashcat’s in a few ways that matter:

$ john --wordlist=rockyou.txt --rules spns.txt
$ john --format=krb5tgs --show spns.txt

--rules (bare, no argument) applies John’s own default rule set from john.conf’s [List.Rules:Wordlist] stanza — conceptually the same idea as hashcat’s -r best64.rule from Part 5, but configured in a stanza-based config file rather than a flat rule file, and with its own (older, differently-documented) rule syntax.

Two features earn John a place in this series independent of hashcat, rather than as a worse duplicate of it:

--single mode. John can generate candidate passwords directly from the account’s own metadata — username, GECOS/full-name field, home directory — before ever touching a wordlist. Against local Unix accounts, where a surprising number of real passwords are still some transform of the username, this catches things a generic wordlist attack won’t, in seconds, with zero external data.

CPU-native formats with no meaningful GPU kernel. Some formats — high-iteration bcrypt in particular — are memory-hard or otherwise resistant to the massive parallelism a GPU offers, narrowing the throughput gap between CPU and GPU cracking far more than the raw core-count difference would suggest. For those formats, a well-threaded CPU run under John, --forked across cores, is a legitimate choice rather than a consolation prize.

Where this leaves the toolchain

hashcat for anything GPU-parallel — which, per Part 2’s numbers, is every AD-facing format this series cares about most. John (Jumbo) as a second opinion on the same formats, or as the primary tool for --single-mode local-account attacks and Unix crypt formats core John already covers well. Neither replaces the other; a serious assessment toolchain has both installed, and — the actual point of this post — installed in a way that’s been checked, not assumed.

Part 4 moves off the cracking engines entirely and onto the other half of the equation: the wordlists themselves, and why rockyou alone stops being the interesting question well before either tool’s throughput does.