What you are really doing when you "crack" a hash

Hashcat does not reverse a hash — nothing does. It guesses passwords, hashes each guess with the same algorithm, and compares. Everything about using it well follows from that one fact: your job is to make good guesses quickly, and the two levers you have are how fast you can hash (the algorithm and the GPU) and how good your guesses are (wordlists, rules and masks). A cracking session that fails is almost never a limit of the tool; it is a limit of one of those two levers.

This is a legitimate and routine part of security work: auditing whether your organisation's password policy actually holds, recovering your own lost credentials, and — in a sanctioned engagement — proving that captured hashes lead to plaintext. All of it assumes the hashes are yours to test.

Tell hashcat what it is looking at: the hash mode

The -m flag is the first thing to get right, because a wrong mode means every guess is hashed the wrong way and nothing will ever match. A few you will meet constantly:

The number matters less than the habit: identify the hash before you attack it. If you are unsure, hashcat --identify hashes.txt will suggest candidate modes, and --example-hashes prints a sample of every format so you can compare shapes.

The speed of an algorithm is the whole game

Here is the single most important thing a bullet list of commands never tells you. These algorithms are not in the same universe of speed:

• MD5 and NTLM are fast hashes — a modern GPU computes them in the hundreds of billions per second. A weak Windows password falls in minutes.
• bcrypt and sha512crypt are slow by design. bcrypt has a deliberate work factor that a GPU cannot shortcut; the same hardware that does 100+ billion MD5 guesses a second manages a few hundred thousand bcrypt guesses a second — five or six orders of magnitude slower.

The practical consequence: against MD5, brute force is on the table. Against bcrypt, brute force is hopeless and you must spend your limited guesses wisely — a targeted wordlist with rules, not a mask over the whole keyspace. Knowing which kind of hash you hold decides your entire strategy, and it is why "just brute-force it" is beginner advice that stops working the moment the target uses a real password-storage algorithm.

The four attack modes, and when each earns its place

-a 0  Dictionary: try every word in a list. Your default first move.
hashcat -m 1000 -a 0 hashes.txt rockyou.txt
-a 0 -r  Dictionary + rules: mutate each word. The highest-yield attack there is.
hashcat -m 1000 -a 0 hashes.txt rockyou.txt -r rules/best64.rule
-a 3  Mask (brute force): every string matching a pattern. Only for fast hashes.
hashcat -m 1000 -a 3 hashes.txt ?u?l?l?l?l?d?d?s
-a 6  Hybrid: a word followed by a mask. Catches "password2026!" patterns.
hashcat -m 1000 -a 6 hashes.txt rockyou.txt ?d?d?d?d

Start with a plain dictionary. It is fast and it catches the genuinely weak passwords first, which is often all an audit needs to prove its point. Then add rules — this is where most real cracks happen, and it deserves its own section below. Reach for masks only against fast hashes, and only for patterns you have reason to expect.

Masks: brute force with a shape

A mask attack (-a 3) tries every string that fits a pattern, built from character-set tokens:

• ?l lowercase, ?u uppercase, ?d digit, ?s special, ?a all of the above.

So ?u?l?l?l?l?d?d?s is "capital, four lowercase, two digits, a symbol" — the exact shape of Summer26! and a million passwords like it. This matters because unrestricted brute force grows impossibly fast: every position you add multiplies the keyspace by the size of its character set, and ?a?a?a?a?a?a?a?a (eight of anything) is already tens of quadrillions of candidates. A well-chosen mask that encodes how people actually build passwords turns an impossible search into a finishable one. Masks are precision, not brute strength.

Rules are where the cracks come from

A rule file mutates each dictionary word on the fly — capitalise it, append digits, swap a for @, reverse it, double it. This is high-yield because it mirrors exactly how people modify a base word to satisfy a policy: password becomes Password1, P@ssw0rd!, password2026.

best64: 64 of the most productive rules. The one to start with.
hashcat -m 1000 -a 0 hashes.txt rockyou.txt -r rules/best64.rule
Stack rule files to multiply their effect (and the runtime).
hashcat -m 1000 -a 0 hashes.txt rockyou.txt -r rules/best64.rule -r rules/toggles1.rule

best64.rule ships with hashcat and is the right default — a small, dense set that catches the common mutations without exploding your runtime. dive.rule and OneRuleToRuleThemAll are far larger and find more, at a cost in time. The insight worth keeping: a modest wordlist with a good rule set beats a giant wordlist with none, because the rules generate the mutations a static list can never contain.

Getting more from the hardware

hashcat -b                              # benchmark: what your GPU does per hash type
hashcat -m 1000 -a 0 h.txt w.txt -O     # optimised kernels — faster, caps password length
hashcat -m 1000 -a 0 h.txt w.txt -w 3   # workload 3: push the GPU harder

-O enables optimised kernels that are meaningfully faster but assume a maximum password length (usually 31 or fewer), so a very long passphrase can be silently skipped — know that trade before you rely on it. -w sets how aggressively hashcat drives the card; -w 3 is a good default on a dedicated cracking box, lower if you need the machine to stay responsive. And always run hashcat -b once on new hardware so you know, in advance, whether a given attack against a given hash type will take minutes or years.

Don't lose a long session

hashcat -m 1000 -a 0 h.txt w.txt -r rules/best64.rule --session=audit1
hashcat --session=audit1 --restore     # resume after a stop or reboot
hashcat -m 1000 h.txt --show           # print already-cracked plaintexts from the potfile

Named sessions let you stop and resume a multi-day run, and hashcat records every crack in a potfile so re-running the same hashes instantly shows what is already broken rather than redoing the work. --show reads that potfile — it is how you pull results out at the end.

Using the results honestly

The output of a cracking session is a list of real people's real passwords, even in a sanctioned audit — it is some of the most sensitive data you will handle. Report the findings (how many fell, to what kind of attack, how fast, which policy gaps that reveals), store the plaintexts encrypted, and destroy them when the engagement closes. The point of the exercise is to fix weak passwords, not to keep a trophy list. And, as always: crack only hashes you own or are authorised in writing to test.

Running hashcat without a GPU rig of your own

Serious cracking wants a real GPU, and building or renting one is the right move for heavy work. For an audit that does not justify the hardware — or to check a policy against a wordlist without provisioning a machine — CyberSec Pro runs hashcat from a browser: you supply the hashes and choose the mode, attack and rules on a form, see the command before it runs, and watch progress stream back. The job runs server-side in a dedicated container, and the hashes you upload are treated as the sensitive material they are — held for the job and never written to logs or backups.

Whichever way you run it, the thinking carries over: identify the hash, respect how fast (or slow) its algorithm is, spend your guesses on rules and shaped masks rather than blind brute force, and handle what you recover like the liability it is.