Learn Hashcat attack modes -- dictionary, rule-based, mask, and hybrid attacks against NTLM, Kerberoast, and bcrypt hashes at GPU speeds.
GPU-Accelerated Password Cracking with Hashcat
Hashcat is the world's fastest password cracking tool, capable of billions of hash attempts per second using GPU acceleration. At Hard level, successful cracking requires selecting the right attack mode for the target hash type, applying intelligent rules to expand wordlists, and understanding why some algorithms (bcrypt, Argon2) remain resistant even to GPU cracking.
Password cracking is a core post-exploitation skill because credentials rarely travel in plaintext — they travel as hashes. Every compromised database dump, every extracted NTLM hash from a domain controller, every Kerberos service ticket captured from the wire arrives as a hash that must be reversed before it can be used for authentication. Understanding how cracking works is also essential for defenders: the decisions developers make about which hashing algorithm to use and what password policy to enforce directly determine whether a database breach becomes a catastrophic credential compromise or a contained incident.
What Hashing Is and Why It Breaks
A cryptographic hash function takes an input of any length and produces a fixed-length output (the hash or digest) that cannot be reversed mathematically. The same input always produces the same hash. Different inputs produce different hashes. You cannot compute the original input from the hash — in theory.
The fingerprint analogy: Imagine a password as a person's face. A hash is like taking their fingerprint — a transformed representation that is derived from the original but doesn't reveal it directly. You can check whether a fingerprint matches by taking someone's print and comparing, but you can't reconstruct the face from the fingerprint alone. Password cracking doesn't reverse the hash — it takes a huge list of candidate passwords, computes the hash of each one, and checks if any match the target hash. It's not breaking the mathematical function — it's an exhaustive search for the original input.
This is why cracking speed matters so much: the attack is fundamentally a guessing game. The question is how many guesses per second can an attacker make, and how many guesses are needed to find the right answer. A GPU with 16,000 shader cores can compute billions of MD5 operations per second in parallel. Against a weak password in a large wordlist, the match happens in milliseconds. Against a strong random password with a slow algorithm like bcrypt, the match may require more computation than is physically feasible.
Why Identical Passwords Must Produce Different Hashes — Salting
Without salting, every user who chose the password "password123" would have the exact same hash in the database. This creates two catastrophic weaknesses:
- Single crack unlocks all copies — an attacker who cracks one instance of a common password automatically compromises every account using that password simultaneously, without any additional work.
- Rainbow tables become viable — a rainbow table is a precomputed lookup table mapping hashes back to passwords. For unsalted common hash algorithms, attackers can download a table that maps billions of MD5 hashes to their plaintext originals and look up any cracked hash instantly, without running hashcat at all.
A salt is a random value unique to each user that is combined with their password before hashing. hash(salt + password) means two users with the same password produce completely different hashes. Salts are not secret — they're stored alongside the hash. Their purpose is not to add a secret but to make precomputed tables useless and force per-hash independent cracking. Modern secure password hashing algorithms (bcrypt, Argon2, scrypt) include salting automatically.
# Unsalted MD5 — same password, same hash for all users: alice: MD5("password123") = 482c811da5d5b4bc6d497ffa98491e38 bob: MD5("password123") = 482c811da5d5b4bc6d497ffa98491e38 # Crack once → compromise both accounts simultaneously # bcrypt — unique salt per hash, even identical passwords differ: alice: $2b$12$rJ8M... (salt embedded in hash) bob: $2b$12$Kp9N... (different salt, different hash) # Must crack each hash independently — no shortcuts
Hashcat Attack Modes
Hashcat provides four primary attack modes, each suited to different information states. The right mode depends on what you know about the target passwords: if you have a breach wordlist, dictionary attack; if you know the policy, mask attack; if you want to expand a wordlist intelligently, rule-based. Understanding when to use each mode is the difference between cracking in minutes and running for weeks with no results.
-a 0 Dictionary try each word in wordlist exactly -a 1 Combinator combine two wordlists: "pass" + "word" = "password" -a 3 Mask pattern brute force: ?u?l?l?l?d?d?d -a 6 Hybrid wordlist + mask: "password" + ?d?d?d = "password123" -m 0 MD5 -m 1000 NTLM (Windows) -m 1800 sha512crypt -m 3200 bcrypt -m 22000 WPA2/WPA3 -m 13100 Kerberos TGS (Kerberoast) -m 1500 DES(Unix) -m 500 MD5crypt (Linux shadow) -m 1400 SHA-256 -m 18200 Kerberos AS-REP (AS-REP Roast)
Hashcat Cracking in Practice
NTLM hashes are the primary cracking target in Windows enterprise environments. They are extracted via Mimikatz (sekurlsa::logonpasswords), DCSync (lsadump::dcsync), or Impacket's secretsdump. The NTLM format is the fourth field in the colon-delimited secretsdump output. NTLM is extremely fast to crack — 52 billion attempts per second on an RTX 4090 — making short or common passwords recoverable in seconds.
# secretsdump output format: user:rid:lm_hash:ntlm_hash::: Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c::: # Extract just the NTLM hash (4th field): 8846f7eaee8fb117ad06bdd830b7586c # Dictionary attack with rules — the standard starting point: hashcat -m 1000 ntlm_hashes.txt rockyou.txt --rules-file best64.rule -O 8846f7eaee8fb117ad06bdd830b7586c:Password1 Speed: 52,847 MH/s (52 billion NTLM hashes/second on RTX 4090) # "Password1" cracked — 8 chars, capital + lowercase + digit # This took approximately 0.002 seconds against rockyou.txt
The speed figure is not theoretical — 52 billion NTLM attempts per second means that every 8-character password using only lowercase letters (26^8 = 208 billion combinations) can be exhausted in under 4 seconds. Every 8-character password with upper, lower, digits, and symbols is cracked in minutes. NTLM's speed is why it is functionally broken as a password protection mechanism without additional controls.
Pure dictionary attacks miss a huge portion of real passwords because humans don't use words verbatim — they modify them in predictable ways to satisfy password policies. They capitalise the first letter, add a number at the end, substitute letters with symbols, or append the current year. Hashcat rules automate these transformations, turning a wordlist of 14 million words into hundreds of millions of likely candidates.
The password policy game analogy: Imagine a lock that requires a key with at least one uppercase letter, one number, and one symbol. Most people don't generate a random key — they take something memorable and apply the minimum changes to pass the check: "fluffy" becomes "Fluffy1!" because that's the easiest path. Rules codify exactly these patterns. The best64.rule file captures the 64 transformations that recover the most real-world passwords in practice.
# Common rule transformations — each rule runs against every wordlist entry: c Capitalise first: password → Password $1 Append 1: password → password1 $! Append !: password → password! sa@ Substitute a→@: password → p@ssword c sa@ $1 Combined: password → P@ssword1 $2$0$2$4 Append year: password → password2024 hashcat -m 1000 hash.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule 8a3f2c1b...:P@ssword1! # Chain multiple rule files for even broader coverage: hashcat -m 1000 hash.txt rockyou.txt -r best64.rule -r toggles1.rule # Runs every word through both rule sets — multiplicative coverage
When you know an organisation's password policy — minimum length, required character types, common prefix patterns — a mask attack is dramatically more efficient than a dictionary attack. Rather than trying every word in a wordlist, a mask enumerates only the specific character-space that the policy defines. For a policy requiring "8+ characters, uppercase, lowercase, digit, and symbol," the mask covers exactly that space and nothing else.
The combination lock analogy: A standard combination lock has three dials with 0-9, giving 1,000 combinations. If you know the lock uses only digits 1-5 on the first dial, you've reduced the search to 500. Masks apply this logic to passwords: if you know the first character is always uppercase and the last four are digits, you've reduced the search space by 99% compared to trying all combinations of all characters.
# Charset tokens: ?u=uppercase ?l=lowercase ?d=digit ?s=special ?a=all # Corporate pattern: 1 upper + 3-4 lower + 4 digits + 1 symbol (Corp2024!) hashcat -m 1000 hash.txt -a 3 ?u?l?l?l?d?d?d?d?s # Tries: Aaaa0000! Aaaa0001! ... Zzzz9999~ — ~4.7 billion combinations # At 52GH/s NTLM: exhausted in under 0.1 seconds # Hybrid: company name + 4 digits + symbol (known prefix pattern) hashcat -m 1000 hash.txt -a 6 company_prefixes.txt ?d?d?d?d?s a8b3c1d2...:Acme2024! # Increment mode — try all lengths from 6 to 12 characters: hashcat -m 1000 hash.txt -a 3 --increment --increment-min 6 ?a?a?a?a?a?a?a?a?a?a?a?a
Kerberoasting (covered in the AD Attacks module) produces TGS (Ticket Granting Service) hashes in the $krb5tgs$ format. These are cracked with mode 13100. The key insight is that these are service account passwords — set by developers or administrators, often years ago, and frequently not subject to the same rotation policy as user accounts. They tend to be memorable, policy-compliant but humanly chosen, and therefore vulnerable to rule-based dictionary attacks.
# Kerberoast hash format from Rubeus or Impacket GetUserSPNs: $krb5tgs$23$*svc_sql$CORP.COM$MSSQLSvc/sqlserver.corp.com:1433*$8a3f2c1b... hashcat -m 13100 kerberoast.txt rockyou.txt -r best64.rule -O $krb5tgs$23$*svc_sql*...:Sql@dmin2024 # Password: Sql@dmin2024 — exactly what a developer would set # svc_sql likely has Domain Admin rights → full domain compromise # AS-REP Roasting hashes (mode 18200) — same approach: hashcat -m 18200 asrep_hashes.txt rockyou.txt -r best64.rule $krb5asrep$23$jdoe...:Winter2024!
The choice of hashing algorithm is the single most impactful password security decision. The difference between MD5 and bcrypt is not a small performance gap — it is a factor of 700,000. A password that would take 0.001 seconds to crack against MD5 requires 700 seconds against bcrypt. A password that would take a year against MD5 would take 700,000 years against bcrypt. The algorithm transforms an instant attack into a computationally infeasible one.
The vault analogy: MD5 is a combination padlock from a dollar store. bcrypt is a bank vault door. Both "lock" the same item. The combination on the padlock can be found by trying all combinations in seconds. The bank vault is designed specifically to resist determined, well-equipped attackers for years. Password hashing algorithms work the same way — some are padlocks, some are vault doors.
# GPU cracking speeds (RTX 4090 approximate — single GPU): MD5: 130,000 MH/s (130 billion/second) NTLM: 90,000 MH/s (90 billion/second) SHA-1: 70,000 MH/s SHA-256: 20,000 MH/s SHA-512: 7,000 MH/s MD5crypt (Linux): 300 kH/s (300 thousand/second) bcrypt ($2b$, cost 10): 184 kH/s (700,000x slower than MD5) Argon2id: ~10 kH/s (13,000,000x slower than MD5) # Practical impact on a 10-character random alphanumeric password: # MD5: ~62^10 ÷ 130,000,000,000 ≈ 64 seconds # bcrypt: ~62^10 ÷ 184,000 ≈ 48 million seconds (1.5 years) # Argon2: ~62^10 ÷ 10,000 ≈ 800 million seconds (25 years) # 14-char random with Argon2: effectively uncrackable in any human timeframe
The bcrypt cost factor (the number after $2b$) is tuneable — cost 10 is the standard, cost 12 is 4x slower, cost 14 is 16x slower. Modern recommendations suggest bcrypt cost 12 or higher for new deployments, or migrating to Argon2id which is purpose-designed for password hashing and is the current NIST recommendation.
When organisations suffer a database breach and their hashed passwords are exposed, attackers don't just use those hashes for that organisation's service — they crack as many as possible and build credential databases for use elsewhere. This is the pipeline that feeds credential stuffing attacks: automated login attempts against other services using username:password pairs recovered from previous breaches.
# Large database breach — 50 million bcrypt hashes # Prioritise low-cost hashes first (older, cheaper to crack) hashcat -m 3200 breach_bcrypt.txt rockyou.txt -r best64.rule --status-timer 60 # Realistic bcrypt crack rate: ~2% of hashes from a large breach # 50M × 2% = 1 million plaintext passwords recovered # Those 1M passwords are then tried against: # - Email providers (Gmail, Outlook) for account takeover # - Banks and financial services # - Corporate VPNs using the same email address # HIBP (Have I Been Pwned) documents 12+ billion compromised credentials # For defenders: check your users' passwords against breach databases curl https://api.pwnedpasswords.com/range/$(echo -n "password123" | sha1sum | cut -c1-5) ...B4F54:4567891 ← last 35 chars of SHA1 hash, seen 4.5M times in breaches
Hashcat in Context — What Cracking Reveals
An e-commerce platform suffers a SQL injection attack. The attacker exfiltrates the users table containing 2.3 million rows: email addresses and MD5-hashed passwords with no salt. Running hashcat against rockyou.txt with best64.rule on a single RTX 4090, the attacker cracks 68% of all hashes in 20 minutes. The remaining 32% are either long random passwords (the security-conscious users) or uncommon words.
1.5 million email:password pairs are now available. These are fed into an automated credential stuffing tool targeting Gmail, Outlook, banking apps, and Amazon. Password reuse rates across services typically run 30-50%. This single breach yields access to hundreds of thousands of accounts across entirely unrelated services — a cascade that began with one vulnerable SQL query and one poorly chosen hash algorithm.
During a red team engagement, the assessor gains a foothold on a workstation via a phishing email. Mimikatz extracts the local Administrator NTLM hash. The local admin password follows the company's documented standard: company name + four digits + symbol. A hybrid attack combining a wordlist of company name variations with the mask ?d?d?d?d?s runs for 4 minutes and recovers the password.
The same local admin password is set on every workstation in the organisation (a common practice for ease of management). The single recovered hash provides local admin access to all 800 workstations. On one of those workstations, a Domain Admin has an active session. Mimikatz extracts the DA's NTLM hash. DCSync dumps the entire domain. Total time from phishing email to Domain Admin: 2 hours, 20 minutes. Total cracking time: 4 minutes.
What Password Cracking Reveals About Organisational Security
- Algorithm choice determines breach impact more than password policy does. A strong password policy enforced with MD5 storage provides less real protection than a minimal policy enforced with Argon2id. The hash algorithm is the last line of defence when a database is stolen — and it is frequently the only thing standing between a breach and a full credential compromise.
- Password policies that produce predictable patterns are partially defeated. A policy requiring "capital, lowercase, number, symbol" doesn't produce random passwords — it produces "Word1234!" patterns. Rules exploit these patterns. The only password that is genuinely resistant to cracking is one that a human didn't choose: a random string of sufficient length generated by a password manager.
- Multi-factor authentication doesn't protect hashes. MFA prevents attackers from using a compromised password to log into a service — but it does nothing about the hashes in the database. An attacker who cracks NTLM hashes from AD can use them for Pass-the-Hash attacks against internal services, for lateral movement, and for offline cracking without triggering any MFA checks.
- Breach notification obligations depend partly on hashing strength. GDPR and various state privacy laws assess breach severity partly based on whether the compromised data was appropriately protected. A regulator reviewing a breach of bcrypt-hashed passwords may assess lower mandatory notification requirements than one reviewing MD5-hashed passwords — because the former provides meaningful protection to affected users, the latter does not.
What You Need to Know
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Hashcat GPU Cracking →← Return to all labs