Hashcat: What It Is, Attack Modes and Password Policy Lessons

Hashcat is a free, open-source password recovery tool that takes password hashes and tries to find the passwords that produced them, using graphics cards to test enormous numbers of guesses offline. Penetration testers use it to show which passwords would not survive an attacker who has captured their hashes, and attackers use it to turn stolen hashes into working logins. If hashcat appears in your penetration test report, the finding is about your password policy, your service accounts, and how easily an attacker could collect the hashes, not the tool.

To learn which of your own passwords would fall, our Active Directory security assessment tests the hashes and tickets one standard user can collect, at $6,000 for one domain (multi-domain estates are quoted); for larger networks, see what an internal network test costs at each size.

What hashcat is

Hashcat is maintained by Jens “atom” Steube and contributors, was proprietary until 2015, is now released under the MIT license, and runs on Linux, Windows and macOS. The current major release is version 8.0.0, published on October 25, 2026 (release notes on GitHub; project history on Wikipedia). It added a grammar-based (PCFG) attack mode, 146 new hash modes and FPGA support for cracking bcrypt, alongside the usual GPUs and CPUs, according to the project’s release notes.

Two facts matter most to a defender:

• Hashcat usually runs off your network. It works on hashes already copied. MITRE ATT&CK notes that cracking “is usually done on adversary-controlled systems outside of the target network” (T1110.002, Password Cracking). When it runs on an attacker’s own hardware, you cannot detect the cracking itself, only the steps that collected the hashes and the logins that follow.
• It is fast because of GPUs. Microsoft has said that Kerberoasting’s “effectiveness is growing because of the use of GPUs to accelerate password cracking techniques” (Microsoft Security, October 2024). The Windows NT hash is a single unsalted MD4 of the password (MS-NLMP), so human-chosen passwords stored that way fall quickly.

Hashcat is also a legitimate audit tool, covered in our guide to penetration testing tools.

Hashcat attack modes, and what each one says about your passwords

“Mode” means two things in hashcat. Hash modes identify the format being attacked, such as an NT hash, a Kerberos ticket or a Wi-Fi handshake. Attack modes decide how guesses are generated, and each one catches a particular kind of password. Each attack mode has a number, set with the -a option and listed on the hashcat wiki, which is how it usually appears in a tester’s notes or a report appendix.

Attack mode	Number (-a)	What it tries	Passwords it catches	Policy lesson
Straight (dictionary), usually with rules	0	Leaked-password words changed by rules (capitalize, add a year, swap letters for symbols)	“Summer2026!”, “P@ssw0rd1”, “Welcome123”	Complexity rules produce exactly these. Use a blocklist instead.
Combination	1	Two words joined	“BlueTiger”, “CoffeeTime”	Two common words is not a passphrase.
Brute-force (mask)	3	Every character in a defined pattern	Short passwords, even random ones	Short passwords fail however random they look.
Hybrid (word plus mask)	6 (word then mask), 7 (mask then word)	A word plus digits or symbols	“Company2025”, “!Yankees99”	Company names, teams and places plus a number are guessed early.
Association	9	Hints tied to each account, such as the username	Passwords containing the user’s name or ID	Block names inside passwords.
PCFG (new in version 8.0.0)	4	A grammar learned from real passwords, most likely structures first	Human-pattern passwords of any length	Long but predictable is still predictable.

Hashcat rarely beats long random passwords. It wins because people choose passwords predictably, and rules requiring a capital, a digit and a symbol push them toward the most predictable pattern of all.

Common hashcat hash modes: NTLM, NetNTLMv2 and Kerberos

The hash mode, set with -m, tells hashcat which format it has been given. A report that says “cracked in mode 13100” is telling you where the hash came from, and so which control failed. These are the modes that show up most often in Windows and Wi-Fi testing, with the numbers and names from the project’s example hashes list.

Hash mode	Hashcat’s name	Where the hash comes from	What it points to
1000	NTLM	SAM, LSASS memory or NTDS.dit	Hashes were dumped from a host or a domain controller
5600	NetNTLMv2	A challenge-response captured on the network	LLMNR, NBT-NS or coerced authentication reached a listener
13100	Kerberos 5, etype 23, TGS-REP	An RC4 service ticket (Kerberoasting)	A service account that still allows RC4
19700	Kerberos 5, etype 18, TGS-REP	An AES256 service ticket (Kerberoasting)	A service account on AES with a guessable password
18200	Kerberos 5, etype 23, AS-REP	An account with pre-authentication turned off (AS-REP roasting)	A pre-authentication exception to remove
2100	Domain Cached Credentials 2 (DCC2), MS Cache 2	Cached domain logons on a workstation or server	Privileged users logged on to a host that was later compromised
22000	WPA-PBKDF2-PMKID+EAPOL	A captured Wi-Fi handshake or PMKID	A guessable pre-shared key
3200	bcrypt	An application’s user table	An application breach; the hash is salted and slow by design

The format changes the odds as much as the password does. NTLM is one unsalted MD4 operation per guess, while bcrypt and Argon2 are salted and built to be slow, so the same password can fall in one format and survive in another. For an authorized audit, the report should name the hash mode, the attack mode and the wordlist and rule set used for each cracked account, so you can repeat the test after the fix.

What a hashcat finding reveals in a penetration test

A cracked password usually ties back to one of these root causes:

• Roastable accounts with human-chosen passwords. Any domain user can request a service ticket encrypted with a key derived from a service account’s password, and an account with Kerberos pre-authentication turned off (usually for a legacy application) hands out a crackable value to anyone. A weak password then falls offline with no lockout to stop it, and a cracked service account key is also what lets an attacker forge a silver ticket for that service. See our Kerberoasting guide.
• Hashes captured from the network. On a default Windows network, LLMNR and NBT-NS poisoning can capture NTLMv2 challenge-responses within minutes. Our Responder explainer covers the fix.
• Hashes dumped from a host or domain controller. Cracking hashes from the SAM, LSASS memory or NTDS.dit shows how many real passwords an attacker would hold, including ones reused on VPNs and cloud apps. The dump itself is usually done with tooling such as Impacket, which is the step your monitoring can see.
• A password policy that passes audits but not attacks. Passwords that meet the complexity rule yet fall to a wordlist and rules are a pattern testers see often. A Kerbrute or NetExec password spray tries the same patterns online, one guess per account, below your lockout threshold.

Severity depends on what the cracked account can reach, which is why BloodHound attack paths and cracking results belong together.

How to detect password cracking activity

Watch how the hashes are collected and how cracked passwords are used. Turn on “Audit Kerberos Authentication Service”, “Audit Kerberos Service Ticket Operations” and “Audit Directory Service Access” (with auditing on the domain object, for 4662) on every domain controller, and forward the Security log off the box.

Stage	Log source	Event or signal	What it means
Ticket collection (Kerberoasting, AS-REP roasting)	DC Security log	4769 with encryption type 0x17 (RC4), 4768 with Pre-Authentication Type 0, or one account requesting many service tickets quickly	Tickets gathered for offline cracking; see our Kerberoasting guide
Hash theft from hosts and DCs	Sysmon Event ID 10, EDR, DC Security log	A process opening lsass.exe without reason (Sysmon); 4662 replication rights used by a non-DC account	Hashes copied from memory or the directory; see our Mimikatz guide
Using cracked passwords	DC and host Security logs	4624 logons from those accounts at unusual hosts or times; bursts of 4625 or 4771 failures	Cracked credentials tried or used
Cracking on your own machines	EDR, process creation (4688 or Sysmon Event ID 1)	A cracking tool running, or sustained GPU load on a machine that should not have it	An insider or compromised host doing the cracking

Since Microsoft’s 2026 RC4 changes made AES the default (the enforcement phase began with the April 14, 2026 updates, for CVE-2026-20833), patched domain controllers issue RC4 service tickets (4769 with 0x17) only where RC4 was explicitly left enabled: each one points to an account to fix, and a burst from one client suggests Kerberoasting.

Password policy lessons: how to make hashcat fail

Some hashes will be taken. The goal is to make them worthless. In order of impact:

1. Require length, not composition. NIST SP 800-63B-4 (July 2025) requires at least 15 characters for passwords used as a single factor and 8 within multi-factor authentication, prohibits composition rules and periodic forced changes, and requires a change on evidence of compromise (NIST SP 800-63B-4). In Active Directory, the Default Domain Policy ships with a seven-character minimum and the Group Policy setting allows at most 14 (Microsoft Learn). Use fine-grained password policies to set stronger rules for admins and other high-value groups.

2. Block the passwords attackers guess first. NIST also requires a blocklist of common, expected and compromised passwords. Microsoft Entra Password Protection covers the common and expected part on on-premises domain controllers (with Microsoft Entra ID P1 or P2), using a global banned list plus up to 1,000 custom terms such as your company name. Normalization and fuzzy matching catch variants such as “C0nt0s0”, but a banned term plus a few extra characters can still pass (Microsoft’s own example accepts “ContoS0Bl@nkf9!”), so pair it with a long minimum length (Microsoft Learn). It checks only at change or reset, and not against breached-password lists, which is what the audit in step 3 is for.

3. Audit what you already have. A password audit compares stored hashes with breached and common password lists, and with each other, to find known-bad passwords and admins who reuse one across accounts. Our Active Directory hardening checklist explains how to run one safely from a Tier 0 machine and protect the output like the domain itself.

4. Take service accounts out of human hands. Move every service that supports it to a group managed service account (gMSA) or delegated managed service account (dMSA), so Windows sets and rotates a long random password. One caveat on dMSAs: Akamai’s May 2025 BadSuccessor research showed that anyone allowed to create a dMSA in an organizational unit could use it to take over other accounts in a domain with a Windows Server 2025 domain controller, so keep those domain controllers patched and limit who can create dMSAs to trusted administrators. For the rest, Microsoft recommends at least 14 characters and AES, which does not save a weak password (Microsoft Security), and MITRE suggests 25 or more (T1558.003).

5. Require Kerberos pre-authentication everywhere. Turn it back on for each exception, or give that account a long random password.

6. Make the hashes harder to collect. Turn off LLMNR and NetBIOS name resolution, enforce SMB signing so captured authentication cannot be relayed instead of cracked, deploy Windows LAPS for unique local administrator passwords, keep privileged logons on Tier 0 systems, enable Credential Guard where supported, and put human admins in Protected Users after testing, which CISA recommends for domain admins “to prevent caching of password hashes locally” (CISA AA24-326A).

7. Keep MFA on everything external. Internal NTLM and Kerberos logons usually bypass it, so steps 1 to 6 still matter.

A strong password policy alone can stop this. In the same CISA assessment, the organization’s domain password policy “neutralized the red team’s attempts to crack hashes and spray passwords” (CISA AA24-326A).

How Invadel tests password strength, and what it costs

Password strength is tested in our internal network penetration testing and Active Directory security assessment. Starting from one standard domain user, a senior in-house tester finds every Kerberoastable and AS-REP roastable account, tests weak, captured and reused credentials, and maps where each cracked account leads. Cracking runs offline, so it never touches your network; on the network itself, nothing on a domain controller is changed and any spray stays under the lockout threshold agreed in writing. Each cracked account becomes a finding that names the pattern that fell and what the account could reach, with the fix and the events your monitoring should have raised.

Engagement	What it tells you about your passwords	From
Active Directory security assessment	Which roastable service accounts and captured hashes fall to a wordlist, and what each cracked account reaches in one domain of up to a few hundred hosts	$6,000
Internal network penetration test	The same, plus the hosts, services and segments around the domain where cracked or reused passwords also work	$6,000 Small, $9,200 Medium, $14,500+ Large
Wireless penetration test	Whether your Wi-Fi pre-shared key can be recovered, at one NYC-metro office (up to 3 SSIDs); sites elsewhere are quoted (see wireless penetration testing cost)	$3,800

Once the weak passwords are reset or the accounts moved to managed passwords, the free retest checks the same accounts again. Prices are fixed in writing, every test includes an attestation letter, and onboarding starts within 24 hours of a signed proposal. See a sample report, all penetration testing prices and the cost calculator, or send your scope through the scoping questionnaire for your fixed price.

Frequently asked questions

What is hashcat used for? Recovering passwords from their hashes offline. Testers use it to audit password strength, and attackers use it to turn stolen hashes into logins.

What hashcat mode is used for NTLM hashes? Hash mode 1000 is NTLM, the NT hash stored in the SAM and NTDS.dit. NetNTLMv2 challenge-responses captured on the network are mode 5600, and Kerberoasted RC4 service tickets are mode 13100. They are different formats with different fixes, so check which one your report names.

Which wordlists and rules do testers use with hashcat? Usually lists of real leaked passwords, plus words specific to your organization (company, product, team and place names), changed by rule sets that add years, capitals and symbol swaps. That is why a blocklist with your own terms and a long minimum length do more than a complexity rule.

How do you use hashcat safely for a password audit? Only with written authorization, on an isolated offline machine, against a copy of the hashes extracted under change control. Report the patterns and accounts that failed, not the passwords, then delete the hash copy and the cracked output. Running it on hashes you are not authorized to test can break computer crime laws.

Does hashcat require a GPU, and is it only for Linux? No to both. It runs on Linux, Windows and macOS and can use CPUs, but GPUs make it far faster.

Is hashcat faster than John the Ripper? Usually, on GPUs and common hash types. John the Ripper’s jumbo build also has GPU support and comes with extraction tools for many password-protected file formats, so many testers keep both.

Can we detect hashcat on our network? Usually not, because cracking happens on the attacker’s own hardware. Watch the steps before and after: RC4 service tickets (4769 with 0x17), tickets issued without pre-authentication (4768 with type 0), LSASS access, replication rights, and unusual logons.

The short version

Hashcat turns captured hashes into passwords offline, and succeeds when passwords follow human patterns, service accounts have human-chosen passwords, and legacy protocols leave hashes easy to collect. Detect the collection steps, and make cracking fail with long, blocklisted passwords, managed service accounts, AES and pre-authentication. To test your own domain, see what our Active Directory assessment covers (from $6,000 with a free retest), check the internal network testing prices, or scope your test.