Hashcat and Password Cracking for Defenders Guide: Running Safe Password Audits That Change Controls

Once an attacker holds your password hashes, cracking happens on their own hardware, out of sight of every control you run, so the only defence that still works is having passwords and hash formats that do not fall to it. Hashcat is the open source tool that both attackers and defenders use to recover passwords from hashes, and an authorised audit with it is the most direct way to find out which of your passwords would survive. This guide explains what hashcat does, which enterprise hash types are weak, how to run a password audit with proper authorisation and data handling, how to turn results into control changes, and how to detect the hash theft that comes before cracking. It is for identity and Active Directory teams, security testers, and the security leaders who approve audits. It is defensive: no cracking commands or attack procedures.

This is an independent guide from NHI Mgmt Group, based on hashcat's public documentation as of November 2026. It is not sponsored or reviewed by the hashcat project. Tool features change, so confirm behaviour against the current documentation.

Key takeaways

• Cracking is invisible; theft is not. MITRE ATT&CK notes that password cracking (T1110.002) is usually done on adversary-controlled systems outside the target network, so detection effort belongs on the credential dumping, Kerberoasting and relay steps that produce the hashes.
• Hash format decides the outcome. Fast, unsalted formats such as NTLM and Kerberos RC4 tickets fall to large wordlists quickly; salted, deliberately slow functions such as bcrypt, scrypt and Argon2 make each guess expensive.
• An audit is a governed activity. Written authorisation, an isolated cracking system, no plaintext in reports and secure deletion are what separate a password audit from a data breach you caused yourself.
• Results should change controls, not shame users. Feed cracked patterns into a blocklist, raise length, remove forced rotation and move service accounts to managed credentials, as NIST SP 800-63B-4 and SP 800-53 IA-5(1) describe.
• Machine credentials are the high-value finds. A cracked service account password usually works on many servers and rarely changes, so service and non-human accounts deserve first priority in remediation.

What hashcat is and how it works

Hashcat describes itself as a highly optimised password recovery platform for GPUs, CPUs and large distributed systems. It is free and open source under the MIT licence, runs on Linux, Windows and macOS, supports CUDA, HIP, Metal and OpenCL backends, and its README lists over 630 hash modes. Version 8.0.0, the current major release in the project's repository as of November 2026, added probabilistic context-free grammar (PCFG) attacks, hash recipes for custom constructions and initial FPGA support for bcrypt.

Hashcat never "decrypts" anything. It generates candidate passwords, hashes each one in the same way as the target system, and compares the result. Everything depends on how good the candidates are and how expensive each hash is to compute.

Mode names and numbers are from hashcat's help documentation. The point for defenders is that composition rules ("one upper case, one digit, one symbol") are exactly what masks and rules are designed to search, which is why current NIST guidance drops them in favour of length and blocklists.

Which enterprise hashes are at risk

The table lists hash types defenders meet most often, with the hashcat mode number so you can read audit output, where attackers obtain them, and what to change. Speed descriptions are relative and depend on hardware.

See the Password Hashing and Key Derivation Guide, the Kerberoasting and AS-REP Roasting Defence Guide, the Kerberos RC4 Deprecation guide and the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.

Running an authorised password audit

A password audit extracts your own hashes, tries to crack them under controlled conditions and reports what fell. Done carelessly, it creates a file of every employee's password on a laptop. The governance matters as much as the technique.

Governance before any hash is touched

• Written authorisation: signed by the system owner and the CISO or equivalent, naming scope (which directories and systems), purpose, people involved, the cracking system, retention and destruction date. Treat it like a penetration test approval. See the Penetration Testing Policy Template.
• Privacy and HR: agree with your data protection officer and HR how results are used. Reporting at the level of patterns and groups, not named individuals, avoids most concerns.
• Separation of duties: the people who crack should not also be the people who can log on with the results. Two-person control over the cracking system is reasonable for tier 0 hashes.

Data handling

A phased audit

1. Pilot. Start with a small, agreed scope such as service accounts and privileged accounts. These carry the most risk and the fewest privacy issues.
2. Baseline runs. Use a fixed time budget and fixed candidate sources (public breach wordlists, organisation-specific words such as company, product and site names, and standard rules) so results are comparable between audits.
3. Classify findings. Group cracked accounts by class (privileged, service, standard user, shared, disabled but enabled) and by pattern (breached password, organisation word, season and year, reuse across accounts).
4. Remediate by risk. Force change for cracked privileged and service accounts first, then standard users with the next sign-in, alongside the control changes below.
5. Repeat. Re-run with the same budget each quarter or after policy changes, and track the trend.

Rolling back is about the policy, not the audit: if a new minimum length or blocklist causes a support surge, slow the enforcement ring rather than abandoning it.

Turning results into control changes

Cracking results are the evidence for policy changes that current standards already ask for.

See the Password Policy Guide (NIST-aligned) and the Breached password checks guide for implementation detail.

Detecting the steps that lead to cracking

You cannot see an attacker's GPU, but you can see how the hashes left. ATT&CK lists password policies (M1027) and multi-factor authentication (M1032) as mitigations for T1110.002, which reflects that the best answer to cracking is making the result useless.

• Domain hash extraction: directory replication requests from hosts that are not domain controllers (Security event 4662 with the replication extended rights), volume shadow copy creation on a DC, and access to NTDS.dit or the SYSTEM hive. See the Golden Ticket, Silver Ticket and DCSync Guide and the Credential Dumping Guide.
• Kerberoasting: 4769 events requesting RC4 (ticket encryption type 0x17) service tickets, or one account requesting tickets for many SPNs in a short window.
• AS-REP roasting: 4768 events for accounts without pre-authentication; better, a scheduled query for accounts with the "Do not require Kerberos preauthentication" flag set.
• Challenge-response capture: LLMNR and NBT-NS responses from unexpected hosts, and NTLM authentication to unknown servers. See the NTLM Relay Guide.
• Cracking tools inside the estate: hashcat binaries, GPU driver installs on servers that should not have them, and large wordlist files on endpoints outside the approved audit system.
• Leaked hash sets: monitor for your domain in leak and breach notifications. In the Cisco Active Directory Credentials Leak 2025, Active Directory hashes taken in an earlier breach were republished years later, which is exactly when offline cracking happens.

Where identity fits

Service accounts, scheduled task accounts and other non-human identities are the most valuable cracking targets in most domains. Their passwords are set once by a person, often to something memorable, rarely changed because rotation might break an application, and the accounts often hold administrator rights on many servers. Kerberoasting exists because any domain user can request a ticket for an account with a service principal name and attack it offline. The fix is to remove human-chosen passwords from machine identities: group managed service accounts where supported, otherwise long random secrets held in a vault and rotated automatically. See the Group Managed Service Accounts (gMSA) Guide and the Rotating a Windows or Linux Service Account Password runbook. Encrypted password manager and vault backups are another case: in the LastPass Breach 2022, stolen vault backups meant the strength of each customer's master password became the remaining protection.

Decision guidance

• In-house or outsourced audit? Small organisations usually get better value from a penetration testing provider that includes a password audit in an internal test, provided the contract covers hash handling and destruction. Larger organisations with repeated audits benefit from an in-house, isolated system and consistent baselines.
• Full domain or targeted? Start targeted (privileged and service accounts). Move to full domain audits once blocklists and length rules are in place, so the audit measures policy effect rather than legacy debt.
• Cracking or comparison? If the main goal is to find breached passwords, comparing hashes against a known breached-password hash list answers that without cracking anything, with fewer privacy concerns. Cracking adds insight into patterns and organisation-specific words.
• Cloud-only identities: where the identity provider does not expose hashes, rely on its built-in banned password and breach detection features and focus audits on any remaining on-premises directory.

Metrics that show it is working

• Crack rate within a fixed budget: percentage of hashes recovered in the same time and candidate set each audit, trending down.
• Privileged crack rate: cracked privileged and service accounts (target zero).
• Breached-password matches: accounts whose current password appears in breach corpora (target zero after blocklist enforcement).
• Service accounts on managed credentials: percentage using gMSA or vaulted, rotated secrets.
• RC4 ticket share: percentage of 4769 events with RC4 encryption, trending to zero.
• Audit hygiene: audits closed with documented destruction of hashes and results (target 100%).

Common failure patterns

• Plaintext in the report. Audit reports or spreadsheets listing cracked passwords by user are a breach waiting to happen, and they often end up on shared drives.
• Cracking on a domain-joined laptop. The hashes and the potfile then sit on a machine exposed to the very attacks the audit is meant to measure.
• Exempting service accounts. Teams skip them to avoid breaking applications, which leaves the highest-value targets untouched.
• Fixing users, not policy. Forcing a reset for every cracked user without changing the blocklist or length rule gives the same result next quarter.
• Assuming old leaks are dead. Hashes stolen years earlier remain crackable and useful while the passwords are unchanged, as the Cisco republication showed.

Framework mapping

Practitioner checklist

• Get written authorisation naming scope, people, system, retention and destruction before extracting any hash.
• Pre-register the extraction with the SOC so credential dumping alerts are closed against the register, not suppressed.
• Crack only on an isolated, encrypted, non-domain-joined system, and protect or disable the potfile.
• Report patterns and account classes, never plaintext passwords or named individuals.
• Remediate privileged and service accounts first, moving them to gMSA or vaulted random secrets.
• Deploy breached and context-specific password blocklists and raise minimum length in line with NIST SP 800-63B-4.
• Remove RC4 from Kerberos and NTLMv1 from the network, and re-enable Kerberos pre-authentication everywhere.
• Re-run the audit on a fixed budget each quarter and record destruction of results.

Standards and references

• MITRE ATT&CK: Brute Force: Password Cracking (T1110.002)
• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5 (IA-5(1) Password-based Authentication)
• OWASP: Application Security Verification Standard 5.0
• hashcat: project repository, README and documentation
• hashcat: Encrypted plains
• hashcat: Example hashes and hash modes

Related NHI Mgmt Group resources: Password Security Guide · Password Spraying and Credential Stuffing Defence Guide · NetExec and CrackMapExec Detection Guide · Metasploit for Defenders Guide · Penetration Testing Guide