Building a Bulk SHA1 Password Cracker Workflow for Penetration Tests
Warning: use this workflow only on systems and data you own or have explicit, written permission to test. Unauthorized password cracking is illegal and unethical.
Overview
This article outlines a practical, repeatable workflow to recover large numbers of SHA1-hashed passwords during authorized penetration tests. The goal is to maximize recovery rate and efficiency while preserving auditability and safety. The workflow covers preparation, tooling, wordlist and rule selection, distribution of work across hardware, post-processing, and reporting.
1) Define scope and constraints
- Authorization: Ensure written permission includes cracking hashed credentials and specifies target systems, data retention, and disclosure limits.
- Hash source & format: Confirm how hashes were extracted (e.g., /etc/shadow, application DB) and their format (salted vs. unsalted, hex encoding, newline-separated).
- Legal/operational constraints: Note allowed compute, storage, time window, and whether live systems may be impacted.
2) Classify hashes
- Salted vs. unsalted: Salted SHA1 (per-user salt) drastically changes approach. If salted, record salt alongside hash.
- Hash count and duplicates: Count unique hashes; deduplicate identical hashes to avoid wasted work.
- Entropy estimate: Sample hashes and try quick checks (length of known encodings, presence of salts) to estimate password complexity.
3) Select tools
Recommended tools for bulk SHA1 cracking (choose per environment and license compliance):
- Hashcat — GPU-accelerated, supports many modes and rule sets.
- John the Ripper (Jumbo) — flexible, CPU/GPU support, good for wordlist+rules.
- Custom scripts — for pre/post-processing, splitting jobs, or integrating API-based wordlists.
Install and test on a small sample to confirm correct hash format and expected behavior.
4) Prepare wordlists and rule sets
- Base wordlists: rockyou, SecLists, curated corp-specific lists (usernames, company terms, keyboard patterns).
- Targeted lists: leaked-password corp leaks, role-specific terms (e.g., “admin”, product names), common suffixes/prefixes.
- Rules/ mangling: Use Hashcat rule files (e.g., best64, d3ad0ne) and custom rules that reflect likely human patterns (year append, common substitutions).
- Combinator attacks: Combine name lists with wordlists when users’ personal data is available and authorized.
- Markov / probabilistic models: Use tools like Hashcat’s maskprocessor or external trainers to build probability-based masks.
Always keep provenance and versioning for lists and rules.
5) Prioritize cracking strategy
Apply a staged approach:
- Low-effort, high-yield: Run wordlist + common rules on deduplicated hashes.
- Targeted transforms: Use tailored wordlists combining corporate/role data.
- Mask attacks: Brute-force common structures (e.g., ?l?l?l?l?d?d).
- Hybrid/combinator and probabilistic attacks.
- Full brute-force as last resort (resource-intensive).
Set time or resource budgets per stage to avoid runaway compute costs.
6) Infrastructure and parallelization
- GPU vs CPU: Use GPUs for speed (Hashcat). For many hashes, scale horizontally across multiple GPUs or hosts.
- Job splitting: Split by hash subsets or by attack mode. For salted hashes where salts differ, you may need per-hash processing or adapt approaches (e.g., targeted dictionary per salt).
- Distributed tools: Use orchestration (Ansible, scripts) to deploy and start jobs, collect results, and handle retries.
- Resource monitoring: Track GPU/CPU utilization, temperature, and job progress to avoid throttling or failures.
7) Execution and monitoring
- Start with a small validation run.
- Log command lines, tool versions, wordlists, rule files, and start/end times for reproducibility.
- Continuously capture cracked outputs and remove corresponding hashes from remaining work to avoid duplication.
- Monitor false positives by verifying cracked plaintexts where possible (e.g., re-hash to confirm match).
Example Hashcat invocation (conceptual):
hashcat -m 100 -a 0 hashes.txt rockyou.txt -r rules/best64.rule –potfile-path=results.pot
Adjust mask (-a 3), combinator (-a 1), or hybrid modes as needed.
8) Post-processing and analysis
- Normalize results: Store cracked pairs (username/hash/plaintext) in CSV/secure database with timestamps and proof (recomputed hash).
- Password classification: Tag passwords by strength categories (very weak, weak, moderate, strong) based on length, character classes, and entropy estimates.
- Account impact assessment: Identify reused passwords, matches with privileged accounts, and credentials present in multiple systems.
- Cleanup: Securely delete sensitive intermediate files per scope rules.
9) Reporting
Produce clear, actionable findings:
- Executive summary: total hashes, cracked count, overall recovery rate, business risk level.
- Technical appendix: methods used, wordlists/rules, time spent per stage, command lines, hardware used, cracked sample set (redacted as required).
- Remediation recommendations: enforce salted+slow hashing (e.g., bcrypt/Argon2), stronger password policies, MFA, credential rotation, breach monitoring.
Include reproducible steps so the client can validate findings.
10) Ethics, safety, and hard limits
- Never exfiltrate or retain plaintext beyond authorized scope.
- Stop immediately on encountering data or accounts outside scope.
- Use the least intrusive methods necessary to achieve objectives.
- Maintain an immutable audit trail of actions and obtain sign-off for any deviation.
Quick checklist (for each engagement)
- Written authorization? Yes/No
- Hash format documented? Yes/No
- Deduplicated hash set ready? Yes/No
- Wordlists and rules versioned? Yes/No
- Resource limits set? Yes/No
- Results securely stored & reported? Yes/No
Conclusion Following a structured, staged workflow maximizes password recovery while controlling legal, ethical, and operational risk. Keep processes auditable, prefer targeted approaches before brute force, and prioritize remediation guidance that reduces the likelihood of real-world compromise.