J. Perez Duertojperezduerto.info

Cracking with hashcat end to end: GPU or not, rules, wordlists, and building your own

  • password-cracking
  • hashcat
  • wordlists
  • credentials
  • methodology

Capturing a hash is half the job. A kerberoast ticket, an NTLM hash, a NetNTLMv2 challenge, a Linux shadow entry: all of them are just encrypted or hashed forms of a password, and recovering the password is an offline problem you solve with a cracker. hashcat is the standard tool. This post is the end-to-end working knowledge: running it on a laptop with no GPU or a rig with one, choosing the mode for the hash you hold, using rules and the common wordlists, and the part most guides skip, building a custom wordlist from the patterns a target organization really uses.

If you came here from Kerberoasting, the tickets you saved go straight into the mode-13100 example below.

Scope: offline cracking of hashes you are authorized to hold, on your own hardware. Nothing here touches the target; the whole point of cracking is that it happens where the victim cannot see it, which is also why the only real defense is upstream, covered at the end.

With or without a GPU

hashcat runs its attacks on compute devices through OpenCL or CUDA. A GPU is one to three orders of magnitude faster than a CPU, but hashcat runs fine on a CPU alone, which is all you need for fast hashes and modest wordlists.

  • Check what you have: hashcat -I lists the devices hashcat can see. On a Kali VM with no GPU passthrough you will usually see only the CPU, and that is fine.
  • Force CPU if needed: hashcat -D 1 ... selects CPU devices, -D 2 selects GPU. On a headless or VM Kali, install an OpenCL CPU runtime (sudo apt install pocl-opencl-icd) so hashcat has a device to run on.
  • Benchmark to set expectations: hashcat -b -m 13100 tells you candidates per second for that hash type on your hardware. A fast hash (NTLM, RC4 kerberoast) on a CPU still does millions per second; a slow hash (bcrypt, sha512crypt) on a CPU is painful and genuinely wants a GPU.
  • When the VM has no GPU, move the file, not the fight. Cracking is just a file plus a wordlist, so copy the small hash file to a machine with a GPU (your host, a cloud instance) and crack it there. There is nothing engagement-specific about where the grinding happens.

The practical rule: match ambition to hardware. On CPU, lean on good wordlists and rules against fast hashes. Reserve large masks and slow hashes for a GPU.

The core command

Every hashcat run is the same shape:

hashcat -m <hash-mode> -a <attack-mode> hashes.txt [wordlist] [options]

The mode number tells hashcat what it is cracking. The ones you will actually use:

Mode Hash Where it comes from
13100 Kerberoast TGS-REP ($krb5tgs$) Kerberoasting
18200 AS-REP roast ($krb5asrep$) accounts without Kerberos pre-auth
1000 NTLM SAM, NTDS.dit, DCSync
5600 NetNTLMv2 responder, SMB relay captures
1800 sha512crypt ($6$) Linux /etc/shadow
22000 WPA-PBKDF2 / PMKID Wi-Fi handshakes
3200 bcrypt ($2*$) web app databases

The attack mode tells hashcat how to generate guesses: -a 0 straight (wordlist), -a 3 mask (brute force over a pattern), -a 6 wordlist then mask, -a 7 mask then wordlist, -a 1 combinator (two wordlists joined).

A first real run, the kerberoast tickets from the companion post:

hashcat -m 13100 -a 0 roast.hashes /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule -o cracked.txt

Options worth knowing from day one: -o cracked.txt writes results, --show reprints already-cracked hashes from the potfile, --username lets the input carry user:hash lines, -O enables the optimized kernel (much faster but caps password length, usually 31), and -w 3 raises the workload so it uses more of the machine.

Wordlists

A straight attack is only as good as the list.

  • rockyou.txt is the baseline, on Kali at /usr/share/wordlists/rockyou.txt.gz. Unpack it once: gunzip -k /usr/share/wordlists/rockyou.txt.gz. Fourteen million real leaked passwords; it cracks a surprising share of human-chosen secrets on its own.
  • SecLists (sudo apt install seclists, then /usr/share/seclists/Passwords/) collects targeted lists: leaked corpora, default credentials, and pattern lists like season-and-year.
  • Weakpass and Kaonashi are larger community lists for when rockyou is exhausted; download them when you have a GPU to justify the size.

Order matters: run the smallest, highest-yield list first (rockyou plus a good rule), then escalate to bigger lists only on what remains.

Rules

A rule file mutates every word in your list on the fly, so a list of a million words with a rule of a thousand transforms becomes a billion guesses, without storing any of them. A rule is a line of single-character operations: capitalize the first letter, append digits, substitute letters for leetspeak, duplicate the word, and so on.

# every rockyou word, each mutated by every rule in best64
hashcat -m 1000 -a 0 ntlm.txt /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/best64.rule

The ones that earn their place, all under /usr/share/hashcat/rules/:

  • best64.rule, 64 high-value transforms, the default first choice; cheap and effective on CPU.
  • rockyou-30000.rule and dive.rule, progressively larger, for when best64 is spent and you have GPU time.
  • OneRuleToRuleThemAll, a community rule (not shipped with hashcat, download it) that folds the best of many rule sets into one; a strong single-rule default on a GPU.

You can stack rules with multiple -r flags, which multiplies them together; that gets expensive fast, so stack only on a GPU and on the hashes that survived the cheaper passes.

Masks and brute force

When you know the shape of a password, a mask attack (-a 3) is far smarter than blind brute force. The charsets are ?l lowercase, ?u uppercase, ?d digit, ?s special, ?a everything.

# e.g. a policy of Uppercase + four lowers + three digits + a symbol: Summer2025!
hashcat -m 1000 -a 3 ntlm.txt '?u?l?l?l?l?d?d?d?s'

# unknown length up to 8, built up incrementally
hashcat -m 1000 -a 3 --increment ntlm.txt '?a?a?a?a?a?a?a?a'

Masks are how you weaponize a known password policy: if the domain requires one uppercase, one digit, and a symbol with a minimum length, you brute only the strings that satisfy it instead of the whole keyspace.

Building a custom wordlist from observed patterns

The highest-yield move on a real engagement is not a bigger public list, it is a small list shaped like the target's actual passwords. Humans in one organization converge on patterns: the company name, local sports teams, the current season and year, a product name plus a symbol.

  • Scrape the organization's own words with CeWL. It crawls a site and emits the vocabulary that appears on it, which is exactly the jargon people build passwords from.

    cewl -d 2 -m 5 -w corp-words.txt https://www.targetcorp.com

    Then run corp-words.txt with a rule that appends years and symbols, or feed it to a mask.

  • Turn a known pattern into a rule or mask. If you have cracked a handful and they look like Targetcorp2025!, write a tiny rule (capitalize, append 2025, append !) and run it over your base list, or express the pattern as a mask directly.

  • Preview candidates with --stdout. hashcat can print what a wordlist-plus-rule would generate without cracking anything, so you can sanity-check a custom rule before spending time on it:

    hashcat -a 0 corp-words.txt -r my-pattern.rule --stdout | head

  • Generate structured candidates: maskprocessor (mp64) emits every string for a mask, kwprocessor (kwp) produces keyboard walks like qwerty123, and princeprocessor (pp64) combines words from a list into longer candidates. These feed hashcat through a pipe or a file.

  • Learn the pattern from what you already cracked. The PACK toolkit reads a set of recovered passwords and reports the organization's real structure: statsgen summarizes the masks and character sets in use, maskgen turns that into an ordered mask list to run next, and policygen builds masks that satisfy a stated policy. Crack a first batch with rockyou, feed the results to statsgen, then target the rest with the masks it tells you the organization actually uses. That feedback loop cracks far more than any single public list.

Detection and defense

Offline cracking is invisible to the target by design, so there is nothing to detect at crack time. The defense is entirely upstream of the hash ever being useful:

  • Length beats complexity. A long passphrase or a machine-managed password defeats wordlists, rules, and masks alike, because none of them reach into a large random keyspace. This is the same fix that neutralizes Kerberoasting: a 25-plus-character or managed secret is not crackable in practice.
  • Deny the patterns. Block the season-and-year, company-name, and keyboard-walk patterns at password-set time with a custom dictionary filter, so users cannot pick the very strings a custom wordlist is built from.
  • Use the tooling defensively. Run hashcat against your own captured NTDS or shadow hashes on a schedule. Whatever it cracks is a list of accounts to force-reset and a source of patterns to add to your deny list. This is proactive auditing, and it finds the weak passwords before an attacker does.

For where these hashes come from in the first place, see Windows credential access.

Use

This is written for authorized assessment and for defenders auditing their own password strength. hashcat is not clever, it is fast and systematic: the skill is in feeding it the right candidates, which means the smallest high-yield wordlist, the right rule, and, when you can, a custom list shaped like the target's real habits. For a defender the lesson is the mirror image: the only passwords that survive this are the ones too long and too random for any wordlist, rule, or mask to reach, so that is the control to enforce.

References

Back to all techniques