Automating Hashcat for Bulk Password Cracking: A Deep Dive into addicted2hash
Hook
Running Hashcat against thousands of hashes isn't the hard part—it's orchestrating the 17 different attack combinations over 48 hours without manual intervention that separates hobbyists from professionals.
Context
Password cracking is deceptively manual. While Hashcat itself is a phenomenally powerful GPU-accelerated cracking engine, using it effectively against bulk hash lists requires executing a carefully sequenced series of attacks: wordlists first, then rule-based mutations, hybrid attacks combining wordlists with masks, combinator attacks merging multiple dictionaries, strategic mask attacks targeting common patterns, and finally computationally expensive brute-force as a last resort.
For penetration testers and security researchers processing dumps from compromised databases, this means babysitting terminal windows for days, manually queuing the next attack mode, adjusting parameters based on hash types, and trying not to accidentally CTRL+C away hours of progress. The addicted2hash toolkit emerged from this pain point: a collection of Bash scripts that automate the entire attack pipeline, letting you start a job Friday evening and return Monday to see what cracked. It's the infrastructure layer that Hashcat never built, optimized for commodity hardware and real-world pentesting scenarios where you have more time than GPU clusters.
Technical Insight
The core architecture centers on addicted2hash.sh, a sequential attack orchestrator that implements a priority-based cracking strategy. The script's elegance lies in its simplicity: it's essentially a state machine that progresses through attack modes, checking for user interruption between each phase.
The attack sequence starts with wordlist-based attacks using common dictionaries (rockyou.txt, crackstation.txt), then escalates to hybrid attacks that append or prepend mask patterns to dictionary words. Here's a simplified view of how the script structures its attack pipeline:
# Wordlist attacks - the low-hanging fruit
for wordlist in "${WORDLISTS[@]}"; do
hashcat -m $HASH_TYPE -a 0 $HASH_FILE $wordlist -o $OUTPUT_FILE --session=$SESSION
check_abort # Allows 'q' to skip to next attack
done
# Hybrid attack: wordlist + mask (e.g., "password123")
hashcat -m $HASH_TYPE -a 6 $HASH_FILE $WORDLIST ?d?d?d -o $OUTPUT_FILE
# Strategic mask attacks targeting common patterns
for mask in "?u?l?l?l?l?d?d" "?l?l?l?l?d?d?d?d" "?u?l?l?l?l?l?d?d"; do
hashcat -m $HASH_TYPE -a 3 $HASH_FILE $mask -o $OUTPUT_FILE
check_abort
done
# Combinator attack: merge two wordlists
hashcat -m $HASH_TYPE -a 1 $HASH_FILE $WORDLIST1 $WORDLIST2 -o $OUTPUT_FILE
What makes this approach effective is the recognition that password complexity follows power law distributions. Most users choose passwords from a relatively small set of patterns: dictionary words with number suffixes, capitalized first letter plus digits, or simple keyboard patterns. By attacking these high-probability patterns first, you crack 60-80% of hashes in the first few hours, leaving the long tail for overnight runs.
The finger-crack.sh script implements a more sophisticated feedback loop called a fingerprint attack. This technique uses already-cracked passwords as intelligence to crack harder passwords. The workflow:
- Run initial attacks to get a seed set of cracked passwords
- Feed cracked passwords to the Expander tool, which generates mutations (reversals, capitalizations, 1337-speak, common suffixes)
- Use the expanded list as a new targeted wordlist
- Repeat iteratively as more passwords crack
This creates a snowball effect where cracking password123 helps you crack P@ssw0rd123! in subsequent iterations. The script manages this iteration automatically:
while [ $ITERATION -lt $MAX_ITERATIONS ]; do
# Extract newly cracked passwords
hashcat --show -m $HASH_TYPE $HASH_FILE > cracked.txt
# Generate mutations using Expander
./expander.pl -i cracked.txt -o expanded_$ITERATION.txt
# Attack with expanded wordlist
hashcat -m $HASH_TYPE -a 0 $HASH_FILE expanded_$ITERATION.txt -o $OUTPUT_FILE
# Check if we cracked new hashes, else break
NEW_CRACKS=$(hashcat --show -m $HASH_TYPE $HASH_FILE | wc -l)
[ $NEW_CRACKS -eq $PREV_CRACKS ] && break
((ITERATION++))
done
The supporting dict2hash.sh utility showcases practical engineering for testing scenarios. It uses GNU Parallel to generate hash files from wordlists across multiple hash types simultaneously, leveraging OpenSSL for hash generation. This is invaluable when you need test data or want to validate your cracking pipeline against known inputs.
The crack-monitor.sh script addresses a different pain point: progress visibility. Hashcat's native status output is ephemeral and requires manual checking. The monitor script periodically polls Hashcat's status, parsing output to track crack rates, speed, and progress percentages. It's simple bash process management—finding Hashcat PIDs, sending status signals, capturing output—but solves the very real problem of "is this still running or did it hang three hours ago?"
One architectural decision worth noting: the toolkit deliberately avoids complex dependency chains. It's Bash scripts calling Hashcat and standard Unix utilities. No Python virtual environments, no Ruby gems, no dependency hell. This makes it deployable on a fresh Kali Linux install or penetration testing dropbox with minimal setup. The tradeoff is limited error handling and less elegant code, but maximum portability and minimal friction.
Gotcha
The elephant in the room is hardware dependency and time investment. The documentation candidly states "24-48 hours on a single GTX GPU" for full attack runs. This isn't a tool for rapid password recovery—it's designed for exhaustive, unattended processing. If you have a deadline measured in hours rather than days, this approach won't help. The attack sequence is also entirely fixed; there's no intelligence about hash types or dynamic strategy adjustment. Cracking bcrypt hashes with the same strategy as MD5 wastes enormous compute time on attacks that won't work.
The Bash implementation creates practical issues. CTRL+C handling is attempted via trap handlers to preserve cracked hashes, but as the maintainer notes, it "doesn't work like you would think." You'll lose session state if you interrupt incorrectly. Error handling is minimal—if a wordlist file is missing or Hashcat hits an error, the script may silently continue to the next attack rather than alerting you. There's also no logging infrastructure; you'll need to manually redirect output if you want records of what actually ran. For production pentesting workflows, you'd want to wrap this in additional monitoring and error reporting, which somewhat defeats the "simple automation" premise.
Verdict
Use if: You're a penetration tester or security researcher processing bulk hash dumps (thousands of hashes) with multi-day timelines, running on commodity GPU hardware (single or dual consumer GPUs), and need hands-off automation that maximizes crack rates without manual intervention. It's ideal for red team engagements where you dump credentials Friday and need results by Monday, or academic research scenarios analyzing password patterns across breached databases. The fingerprint attack mode is particularly valuable for targeted campaigns where you have some cracked passwords and want to expand coverage.
Skip if: You need results in hours rather than days, are working with specialized hash types requiring custom attack strategies (looking at you, bcrypt with high iteration counts), want granular control over Hashcat parameters and attack ordering, or lack dedicated GPU resources. Also skip if you're cracking small hash sets (<100 hashes) where manual Hashcat usage is faster than configuring automation, or if you need production-grade error handling and logging. Modern alternatives like custom Python scripts using the Hashcat Python bindings give you similar automation with better error handling, or just use Hashcat directly with tmux/screen sessions if you want full control.
