Hashcat rule review begins with synthetic seed inputs and an explicit transformation order. Separate candidate expansion from actual recovery measurements and keep the approved workload visible.
On this page
Open the practical working record for this guide’s task-specific fields and next action.
Preview candidate behavior before timing recovery
Use synthetic input to inspect a small ruleset, then record seed count, transformation order, hash type and stopping condition for a separately authorized comparison. Rule combinations can enlarge work without adding useful distinct candidates. Do not turn candidate arithmetic or one hardware result into a general completion estimate. Protect recovered secrets and report online controls separately. Source and scope.
Hashcat rules transform seed words into password candidates. More candidates do not guarantee more recoveries: the result depends on the hash type, input quality, tested transformations, available hardware and the permitted workload. Use a small, documented comparison before expanding.
This is an offline password-audit method for authorized datasets or synthetic examples. It reports no measured recovery rate or GPU benchmark. Documentation was checked on October 16, 2026; verify behavior against your installed version.
Separate candidate generation from audit results
A candidate is a proposed plaintext. A recovery means the tool found a candidate matching a supplied hash under the selected mode. A large generated set can contain duplicates or candidates the selected implementation cannot process. Keep these counts separate.
Choose a question you can evaluate: for example, whether adding a particular suffix family increases recoveries within an agreed compute budget. Do not assume one family consistently outperforms another across organizations or password populations.
Confirm scope and protect recovered secrets
Record permission for offline auditing, the dataset source, approved hardware, duration, storage and retention. Ownership of an online account does not necessarily authorize testing the service or obtaining its stored hashes. Use invented words and local sample files for learning.
Set restrictive storage permissions before an audit. Hash files, recovered plaintext, potfiles, output files, logs and restore artifacts can be sensitive. Do not email recovered passwords or place them in public repositories. Agree on evidence minimization and cleanup with the data owner.
State a hypothesis before selecting rules
Use approved policy information or a synthetic training objective to choose transformations. A capitalization or year example illustrates a mechanism; it is not evidence about the habits of a particular organization. Avoid collecting personal details to enrich an audit without explicit permission.
Keep the seed list and transformations versioned separately. When comparing runs, note whether both received equal time, equal candidate budgets or complete coverage. Those comparisons answer different questions.
Preview a small rule file
The official rule reference defines : as unchanged, c as capitalize first/lowercase the remainder, and $X as append character X. For a toy preview, put summer in sample.txt and these three lines in workshop.rule.
Run the preview command below without a hash file. Expected outputs are summer, Summer and Summer2026!. This is an explanatory example, not a reported execution on this site. Previewing candidates does not establish GPU compatibility or audit speed.
:
c
c$2$0$2$6$!hashcat -a 0 --stdout sample.txt -r workshop.ruleDistinguish alternatives from stacked transformations
For the mode-0 example, separate rule-file lines are alternatives. Multiple -r files stack combinations, and file order matters. The Hashcat FAQ explains rule stacking and troubleshooting; check it before combining files.
Use a tiny input to inspect the actual output, including duplicates and length. Keep rule-file syntax engine-specific. The rule reference also warns that reject operations are not ordinary rule-file operations; do not assume a length-rejection line in a .rule file enforces your intended audit boundary.
Run a controlled baseline and one change
Document the Hashcat version, hash mode, relevant options, hardware and driver environment, seed-list identifier, rule-file identifier and stopping condition. Confirm that the selected hash format is correct before interpreting a result. A display of zero recoveries is not a diagnosis of the rules.
Preserve a baseline, then add one family and record elapsed time, tested progress, rejected candidates and incremental recoveries where available. Existing potfile entries and already recovered hashes can affect what a later run appears to discover. Explain how comparison state was handled rather than treating every displayed total as new.
Estimate workload without presenting false precision
As a hypothetical upper-level count, 1,000 seed entries and 3 alternative rules create 3,000 seed-rule applications. If every application produces one distinct acceptable candidate, that would be 3,000 distinct candidates; duplicates and rejections can reduce it. Two stacked files containing 3 and 4 rules introduce 12 combinations per seed before those effects.
A candidate count divided by a guessed “speed” is not a dependable completion estimate. Hash mode, salts, implementation, workload shape and hardware affect throughput. Use the actual run’s status and an agreed stopping rule; do not extrapolate a fast-hash demonstration to a slow password-hashing scheme.
Interpret low recovery rates carefully
Few recoveries can reflect strong passwords, an unsuitable candidate set, incomplete coverage, a wrong mode or a processing error. Inspect the status and warnings before choosing an explanation. A faster run and a better audit are different outcomes.
Do not generalize a rule’s success from a small, biased sample or from only the easiest recovered passwords. An unrecovered password is not proven strong; report the tested coverage and limits. Remove a rule from a specific future plan only when the evidence and budget justify that decision.
Separate syntax, environment and strategy errors
First confirm the tiny preview matches the intended transformation. Next check supported options and the relevant official troubleshooting guidance for your installed build. Then review whether the strategy fits the authorized dataset. Changing rules cannot repair a missing or incompatible compute runtime.
Do not disable warnings or protection checks merely to make a job proceed. Preserve the diagnostic output with secrets removed. Use a known synthetic test to investigate the tool before rerunning a sensitive dataset.
Report offline and online controls separately
Offline resistance depends on password strength and appropriately configured salted password hashing. MFA and online login rate limits can reduce account takeover opportunities, but do not slow an offline computation against a copied hash set. NIST SP 800-63B-4 distinguishes password verification and other authentication requirements. Apply the requirements relevant to the system rather than claiming a Hashcat run measures all authentication security.
Report the authorized population, relevant denominators, duration, coverage and incremental results. State whether counts refer to hashes, accounts or unique plaintexts. Recommend changes tied to the confirmed weakness and avoid including recoverable secrets in screenshots or management summaries.
Next step: preserve a reproducible comparison
Save the small preview, a description of the baseline and one proposed transformation. Obtain the audit inputs and handling rules before moving beyond synthetic examples. For a broader lab plan, the Kali lab infrastructure guide explains environment and evidence separation.
This method has no promised time-to-first-recovery. Stop when the authorized budget ends, when the environment produces unresolved errors or when the planned comparison no longer answers the audit question.
Common questions
Does a mask do the same thing as a rule? No. Masks describe candidate structure; rules transform seed candidates. Choose the method for the tested hypothesis and supported mode.
Does an offline recovery prove an account can be accessed? No. It demonstrates a match against the supplied hash within this test. Actual login behavior, MFA, account status and authorization require separate permitted evaluation.
Keep conclusions narrower than the evidence
A defensible audit explains what was tested, what changed and what remains unknown. Use a verified preview and controlled comparisons to support those conclusions; generated candidate volume alone is not a success metric.
Hashcat: Rule-preview comparison ledger
Use these fields for your own task. Keep the actual conditions, evidence and unresolved questions beside the next decision.
Use the editable record below to retain the task context and unresolved questions.
Edit here, then select and copy the text to your own notes before leaving. This field has no submission or storage function; reloading resets it. Do not enter passwords, tokens or private client information. The 12,000-character limit applies to this working note.
Next action: Preview the candidates before increasing a rule-combination workload.
Related task: Use Build a Python Pentest Toolkit: Scope, Results and Tests for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.
Hashcat rules: inspect expansion before recovery claims
Illustrative example — not a performed lab test.
- Observation
- A synthetic seed produces the expected transformed candidate, but no authorized hash-recovery run was performed.
- Supported interpretation
- Candidate transformation passed for that seed and rule order.
- Still unresolved
- Recovery rate, throughput, duplicate behavior across the full seed set and usefulness for another approved dataset.
- Next authorized check
- Keep original seeds, rule order and expanded candidates together. Inspect a small synthetic sample before increasing combinations. Record actual approved recovery measurements separately; successful expansion is not a measured cracking result.
Practice-aid update: October 20, 2026. Added the illustrative decision case and editable note. No new VM execution or full-article revalidation is claimed.