Presented by Vitaliy Kovalchuk at Grassr00tz 2024 in Appleton, Wisconsin · Approximately 49 minutes · Watch on YouTube
Quick answer
Better password auditing is not always about buying more GPUs or running a larger default ruleset. In this presentation, Vitaliy “Tally” Kovalchuk shows how authorized security testers can improve Hashcat results by combining proven wordlists, target-relevant vocabulary, small reusable rule files, mask analysis, combinator attacks, and human pattern recognition. The central lesson is simple: better candidate generation often matters more than blindly expanding the keyspace.
Authorized use only
Hashcat is a legitimate password-recovery and security-auditing tool. Use the techniques discussed here only with systems, hashes, and data you own or have explicit written authorization to assess. Engagement scope, data handling, retention, and reporting requirements should be established before testing begins.
Who should watch this
This presentation is designed for penetration testers, red and purple teams, password-audit specialists, security engineers, and defenders who already understand Hashcat’s basic attack modes and want to build more deliberate candidate-generation workflows. It is not an introductory installation tutorial; it focuses on expanding what experienced users try after the obvious attacks stop producing results.
In this companion guide
Overview · Video chapters · Kitchen framework · Core techniques · Defender takeaways · 2026 update · Checklist · FAQs
Cooking for Hashcat: what the presentation covers
Recorded at Grassr00tz 2024, this talk follows Vitaliy’s work as SEVN-X’s Director of Adversary Operations and in-house password-cracking resource. When an authorized penetration test produces password hashes, the challenge is rarely limited to launching Hashcat. The difficult part is deciding which candidates deserve compute time, which attacks fit the hash type, and how to learn from the results already recovered.
The presentation uses a cooking theme to make that workflow memorable. Hardware is the kitchen. Wordlists, rules, masks, analysis utilities, and shell tools are the utensils and ingredients. Hashcat is the critic evaluating the candidates. A recovered password is the finished result.
The talk begins with cracking hardware and familiar inputs, then moves into the more valuable material: alternative word sources, password-corpus analysis, small composable rules, transformed lists, combinator and hybrid strategies, target-specific context, passphrase patterns, and lightweight automation. Throughout the presentation, the emphasis is experimentation using existing tools—not writing an entirely new cracking engine.
Six takeaways from the talk
01. Match the attack to the hash. Slow algorithms punish oversized candidate sets, so prioritization matters.
02. Treat wordlists as raw material, not finished products. Transform, combine, filter, and tailor them.
03. Small, clearly named rules can be easier to combine and reason about than one enormous ruleset.
04. Organization-specific context—within engagement scope—often reveals candidates that generic lists miss.
05. Recovered passwords are evidence. Analyze their structures and feed the observed patterns into later attacks.
06. Revisit old, authorized hash sets as tools, rules, hardware, and your understanding of user behavior improve.
Video chapters
The self-hosted player above contains the complete talk. These timestamp links open the corresponding point on YouTube.
00:16 Introduction and intended audience
09:32 The password pattern that inspired the talk
12:55 Presentation roadmap
14:02 The kitchen, utensils, ingredients, and critic
15:26 Common hash sources encountered during authorized tests
17:36 GPU rigs, power, cooling, storage, and operating systems
24:33 Wordlist, mask, transformation, and analysis utilities
27:55 Established and alternative wordlist sources
31:29 Ruleset collections and passphrase resources
33:38 Building small custom rules and masks
36:28 “RockYou Salad” and transformed candidate lists
37:45 Combining rules, lists, pipelines, and loops
41:58 Target context and organization-specific patterns
44:04 Recognizing human patterns in passphrases
46:43 AI-assisted analysis as a “sous chef”
48:03 Final takeaways: reuse, mix, test, and iterate
The Hashcat kitchen framework
The cooking metaphor is playful, but the underlying operating model is useful because it separates compute, candidate generation, execution, and results.
Kitchen
Security meaning: GPU or CPU hardware, storage, power, cooling, drivers, and operating system.
The decision: What workload can be executed safely and efficiently?
Utensils
Security meaning: Hashcat, hashcat-utils, analysis tools, text editors, scripts, masks, and rules.
The decision: How should source material be analyzed, transformed, and delivered?
Ingredients
Security meaning: Authorized wordlists, recovered patterns, approved public vocabulary, and target-relevant context.
The decision: Which candidate families are most likely to reflect real user behavior?
Food critic
Security meaning: Hashcat’s cracking engine evaluates candidates against the supplied hashes.
The decision: Does the candidate reproduce the stored hash?
Finished dish
Security meaning: A recovered password and the evidence revealed by its structure.
The decision: What weakness does it expose, and how should the organization correct it?
The core techniques, translated from the transcript
1. Match candidate cost to the hash type
Hashes do not all run at the same speed. A large ruleset that is practical against a fast hash can become a multi-day or multi-week job against a deliberately slow construction. The presentation repeatedly returns to this tradeoff: start with high-confidence candidates, estimate the keyspace, benchmark on the actual hardware, and reserve broad attacks for situations where the likely value justifies the time and energy.
This is why attack planning matters. An efficient audit is not a contest to generate the largest possible number of candidates. It is a process for ordering the most plausible candidates first and expanding only when the evidence supports it.
2. Treat wordlists as ingredients
Established password lists are useful because they represent real choices people have made. They are not complete. The talk recommends supplementing them with broader vocabulary, proper nouns, passphrase components, and organization-relevant language collected within scope. Tools such as CeWL can derive vocabulary from approved public web content, while analysis tools such as PACK and Pipal can reveal masks, lengths, character classes, base words, and other recurring structures in an authorized corpus.
List quality also requires maintenance. Large collections may overlap heavily, wasting storage and compute on duplicate candidates. Normalize encoding, document provenance, remove duplicates where useful, preserve the original evidence separately, and record which inputs were used in each run so results can be reproduced.
3. Build small rules that describe one behavior
Hashcat’s rule-based attack modifies, cuts, extends, rejects, or otherwise transforms source words. Large community rulesets can be effective, but they may also produce enormous keyspaces and make it difficult to understand which behavior generated a successful candidate.
Vitaliy’s alternative is to create small, clearly named rule files for one behavior at a time—for example, a defined year range, selected character substitutions, case toggles, or separators—and combine them deliberately. This makes experiments easier to reason about and reuse. The warning is important: multiple rules multiply candidate counts quickly, so inspect and benchmark combinations before committing to a long run.
4. Combine candidate families
A combinator attack joins entries from two dictionaries. A hybrid attack pairs a dictionary with a mask-generated candidate space. These techniques are valuable as users move from short passwords toward longer, multi-word constructions.
The talk’s “salad” method transforms familiar lists into smaller fragments or alternate forms. Its “sandwich” method joins those forms and adds tightly scoped rules or masks. The names are informal, but the strategy is disciplined: decompose an observed construction, create candidate groups for each component, combine them in the likely order, and apply only the transformations supported by evidence.
The same logic applies to long passphrases. Length alone helps, but a long string assembled from a predictable template can still produce a much smaller effective search space than its character count suggests.
5. Use engagement context responsibly
Generic wordlists cannot know an organization’s naming conventions. During an authorized engagement, approved sources may reveal company names, office locations, product names, hostnames, DNS labels, usernames, service terminology, slogans, team names, or required passphrase structures. Those terms can become targeted candidate inputs when the rules of engagement permit it.
Context must be handled as assessment data. Collect only what the engagement authorizes, protect it appropriately, separate client-specific material from reusable general resources, and dispose of it according to the agreement. A successful audit should reduce the client’s risk, not create a new store of sensitive information.
6. Let recovered passwords teach you
One recovered password may expose a pattern shared by many accounts: username-plus-number, location-plus-year, color-animal-color, company term plus punctuation, or a predictable default. Statistical tools can surface common masks and positions, but human review can still identify semantic structures that a generic report misses.
Use that knowledge to refine the next authorized test, then report the systemic issue—not only the individual password. The highest-value finding may be a provisioning template, service-account convention, password-reset practice, or policy instruction that caused many people to build secrets the same way.
7. Automate the repeatable parts
Hashcat and hashcat-utils are designed to work with files, standard input, and standard output. That makes it possible to chain transformations, filtering, combination, rule application, and execution. Simple loops can run a controlled attack plan consistently and make it easier to revisit a hash set later.
The talk also introduces AI as a “sous chef” for generating small analysis scripts and answering questions that an existing tool may not cover. That can accelerate development, but client passwords, hashes, usernames, and assessment data should never be placed into an unapproved public AI service. Use approved environments, synthetic samples, local models, or de-identified statistics, and independently validate generated code before relying on its output.
The defensive lesson
Password length does not erase predictability
The strongest insight in this talk is not limited to password crackers: people follow patterns. If policy forces the entire organization toward the same construction—such as a capitalized word, company term, year, and symbol—attackers can model that structure. A 16-character password built from a visible template may be far weaker than its length suggests.
Current NIST SP 800-63B guidance reflects this reality. It calls for at least 15 characters when a password is the only authentication factor, permits a minimum of eight when the password is used within multi-factor authentication, recommends allowing at least 64 characters, rejects arbitrary composition rules, and requires comparison against a blocklist of common, expected, or compromised values.
NIST also requires support for password managers and autofill and recommends permitting paste. Those measures help users choose unique generated passwords rather than memorable patterns that repeat across services. For higher-risk access, phishing-resistant authentication can reduce dependence on passwords altogether.
Organizations should also protect stored passwords with an appropriate salted password-hashing scheme and a defensible work factor. Slow, memory-intensive verification materially changes offline attack economics, while fast or unsalted legacy hashes give an attacker far more guesses per second.
2026 context
What changed after the 2024 presentation?
The presentation captures the tools and hardware Tally was using in 2024. Individual GPU pricing, operating-system references, driver behavior, cloud availability, tool repositories, and performance figures will continue to change. Benchmark your own supported environment and verify current documentation before building a cracking rig or scheduling a large engagement.
The most important software development is the Hashcat 7 generation. The project’s 7.0.0 release notes describe new compute and scripting bridges, virtual devices, expanded backends, automatic hash-mode detection, Argon2 support, rule-engine enhancements, revised memory management, and broad performance work. These changes expand what Hashcat can execute, but they do not replace candidate strategy.
The talk’s central ideas remain current in 2026: understand the hash, prioritize likely candidates, compose small transformations, analyze recovered patterns, protect assessment data, and treat compute as a finite resource. Better tooling makes those decisions more powerful; it does not make them unnecessary.
Practical password-audit checklist
Before launching an authorized offline password audit, confirm that the workflow answers these questions:
01. Does the written scope explicitly authorize collection, transfer, cracking, retention, and reporting of the hashes involved?
02. Are the hash type, source, integrity, and expected business value understood?
03. Has the hardware been benchmarked against the actual hash mode before estimating completion time?
04. Are candidate sources approved, documented, normalized, and protected according to their sensitivity?
05. Does the attack order begin with high-confidence candidates before expanding into costly keyspaces?
06. Have wordlists, rules, masks, and combinations been sampled and counted before execution?
07. Are sessions, logs, outputs, and tool versions recorded so the work can be resumed and reproduced?
08. Are recovered passwords reviewed for systemic patterns rather than reported only as isolated accounts?
09. Are recovered secrets, potfiles, generated lists, and client context encrypted and access-controlled?
10. Is there a documented process for securely returning or destroying assessment data when the engagement ends?
The bottom line
“Cooking for Hashcat” is a talk about moving beyond default inputs. Hardware provides capacity, but candidate design determines whether that capacity is used intelligently. Existing utilities, well-understood rules, targeted vocabulary, composable attacks, and careful analysis can expose password patterns that a routine dictionary run misses.
For the companion build guide, read Building a Password Cracker Rig. To keep watching instead, open the full presentation on YouTube.
Frequently asked questions
Hashcat and password-auditing FAQs
What is Hashcat?
Hashcat is an open-source password-recovery and auditing utility that supports CPUs, GPUs, and other hardware accelerators across Linux, Windows, and macOS. Security teams use it to evaluate password resilience, recover authorized credentials, and analyze the risk created by stored password hashes.
Why can targeted attacks outperform brute force?
Blind brute force explores a very large character space. Targeted attacks use evidence about human choices, organizational context, known structures, or recovered examples to prioritize a much smaller set of plausible candidates. That can produce useful results sooner, especially against slow hash constructions.
What is a Hashcat rule-based attack?
A rule-based attack applies transformations to each entry in a source dictionary. Rules can change case, substitute or insert characters, append or prepend values, cut content, or reject candidates. They model the predictable ways people modify words when creating passwords.
What is the difference between combinator, hybrid, and mask attacks?
A combinator attack joins entries from two dictionaries. A hybrid attack pairs dictionary entries with a mask-generated space on either side. A mask attack defines the expected character type or fixed value at each position. All three reduce unnecessary guessing when the tester has evidence about likely structure.
Are long passphrases automatically safe from offline cracking?
No. Length is valuable, but predictability still matters. A passphrase built from a known template, familiar quotation, repeated pattern, or small set of required categories may occupy a much smaller effective search space than a unique generated secret of similar length.
What should organizations do instead of enforcing complex password formulas?
Support long passwords and password managers, block common and compromised choices, permit paste and autofill, use multi-factor or phishing-resistant authentication according to risk, store passwords with a suitable salted password-hashing scheme, and test whether organization-specific patterns remain guessable.
Can anyone legally use these techniques?
The software is publicly available, but authorization determines whether a specific use is lawful and appropriate. Security testing should be limited to assets and data you own or have explicit permission to assess, with agreed scope, handling controls, and reporting requirements.
Related resources
Achieve Better Cybersecurity
Would your password strategy survive a real-world audit?
SEVN-X penetration testing evaluates how attackers could use identity, credential, configuration, and password weaknesses in your actual environment—then turns the evidence into practical remediation priorities.