Introduction
In a previous blog, I talked about why most password policies are weak and how the password filtering problem keeps organizations exposed even when they think they’ve checked all the right compliance boxes. One of my recommendations was to conduct a targeted password audit to uncover weak passwords/schemes before an attacker does. Since I find myself giving this advice often during penetration tests, I figure better to lead by example and provide some easy-to-follow instructions for anyone interested in attempting a basic password audit to address low hanging fruit that may exist in your Active Directory environment.
Password auditing doesn’t need to feel intimidating and I can certainly understand any apprehension that comes with the territory of anything that has to do with Domain Controllers and the NTDS.dit file. Additionally, not everyone has the same level of understanding of what Active Directory password hashes/password cracking actually is.
When done properly, a password audit is a tool that can be used to significantly decrease the risk of account compromise. I will always advocate for bringing in experienced eyes like Depth Security for conducting a thorough audit, mostly because recognizing password schemes and building targeted wordlists is a skill that genuinely takes time to develop. That doesn’t mean, however, organizations should be flying completely blind when it comes to understanding the state of their own password security. Any audit is better than no audit.
This blog is intended to walk through the fundamentals of what password cracking is and how it works, how to extract and handle Active Directory password hashes responsibly, and how to run a basic audit that gives you actionable results.
Hashes vs. Passwords
Before getting to basic password cracking methodology, it’s worth taking a moment to make sure we’re all on the same page about what a password hash actually is.
When a user sets a password in Windows, Active Directory does not store the plaintext password. Instead, it stores a mathematical representation of that password called a hash. The specific format Windows uses to store hashes is called NTLM (NT LAN Manager) (It was once pointed out to me that it really should be LMNT due to the order of the hashes in the NTDS file which has lived rent free in my brain ever since.) NTLM hashes are one-way, meaning you can’t simply reverse the hash back into the original password the same way you’d decode a piece of encrypted text. While it is possible that reversible encryption might be enabled as a password storage option in Active Directory, that is a dangerous setting that should not be in place. If it is, I would recommend disabling it and forcing password resets on all accounts before conducting a password audit.
While you can’t reverse a hashed password, you can guess it. Password cracking is fundamentally the process of generating candidate passwords, hashing them using the same algorithm, and checking whether the result matches a hash you’ve captured. If it does, you’ve “cracked” that hash and recovered the original plaintext password. If an attacker gets access to your AD hashes (or any hashes for that matter) through any type of compromise, this is exactly what they’ll be doing on their end.
Modern GPU-based cracking rigs can attempt billions of NTLM hashes per second. The practical implication is that short or predictable passwords, regardless of whether they technically satisfy your complexity policy, are often cracked in minutes.
For the purposes of this blog, I’ll focus on the offline cracking process as it pertains to an internal password audit rather than live attacks, since that’s the more comprehensive and controlled way to evaluate your own environment. I will also suggest a few concrete resources to use that should be feasible even without a dedicated cracking rig as a solid baseline. A basic password audit can also help determine if accounts are at risk from using weak passwords that can be guessed in password spraying attacks even if an attacker never gains access to their password hash.
Step 1: Extracting the Hashes: The NTDS.dit File
Active Directory stores user account information, including password hashes, in a database file called NTDS.dit, located on your Domain Controller at C:\Windows\NTDS\NTDS.dit. You’ll also need the SYSTEM registry hive, which contains the encryption key (called the Boot Key or SysKey) required to decrypt the hashes stored in NTDS.dit.
There are a few ways to extract this responsibly in an authorized, internal audit context. The two most common approaches I recommend for organizations doing this themselves are:
Using ntdsutil (Built-in Windows Tool)
ntdsutil is a native Windows command-line tool that can create an offline snapshot of NTDS.dit without locking the live database. Run this from an elevated command prompt on the Domain Controller:
ntdsutil “activate instance ntds” “ifm” “create full C:\Audit\NTDS” q q
This creates a copy of NTDS.dit and the required registry hives in the C:\Audit\NTDS directory. Transfer this to your isolated audit workstation. Do not conduct cracking on a domain-joined machine or on a system that could expose the hashes to an uncontrolled environment.
Using Volume Shadow Copy
If ntdsutil isn’t an option, an existing Volume Shadow Copy on the DC can also be used to pull NTDS.dit:
vssadmin list shadows (“vssadmin create shadow /for=C:” if you need to create first) copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\Audit\reg save HKLM\SYSTEM C:\Audit\SYSTEM
A Word on Authorization and Handling
I cannot stress this enough: this process should only be performed by authorized personnel with explicit sign-off, and the resulting files should be treated with the same sensitivity as any other highly privileged credential material. NTDS.dit combined with the SYSTEM hive gives anyone who has it the ability to compromise every account in your Active Directory domain. Store the output on a hardened and isolated server and delete it when the audit is complete. I’ve had the (mis)fortune of finding examples of password audits and NTDS backups on file shares accessible by low-privileged users on internal networks before so please do not create more risk by conducting this audit. The goal of a password audit is to make an attacker’s life harder, not do their work for them.
Step 2: Extracting the Hashes from NTDS.dit
Once you have the NTDS.dit and SYSTEM files, you need to extract the actual hashes into a usable format. The tool most commonly used for this is Impacket’s secretsdump.py, which is part of the open-source Impacket suite. Run this from a Linux-based audit workstation:
secretsdump.py -ntds /path/to/NTDS.dit -system /path/to/SYSTEM LOCAL -user-status -outputfile /path/to/audit_hashes.ntds
This will produce a file with entries in the format:
username:RID:LM_hash:NTLM_hash::: (status=Disabled/Enabled)
For modern Windows environments you can generally ignore the LM hash column. LM hashing is disabled by default in current Windows versions and will usually just show the placeholder value aad3b435b51404eeaad3b435b51404ee. The NTLM hash in the fourth field is what is needed for password cracking. Similar to reversible encryption, if you have LM hashes, make sure new ones cannot be generated and force password resets on any affected account before proceeding to a password audit. LM hashes are even easier to crack than NT hashes since the max character space that needs to be brute-forced for any chunk of a LM hash is only seven characters and is incredibly weak.
You can also conduct a reuse analysis on the NTLM hashes before even attempting any password cracking. While still on the Linux-based audit station you can run the following to find which accounts share the same NTLM hash:
awk -F: ‘{print $4, $1}’ audit-hashes.ntds | sort | uniq -Dw 32
This can be used to help discover evidence of password schemes and whether service accounts, admin accounts, and regular user accounts are all sharing a password. This isn’t filtering out disabled accounts as a heads up since dangerous password schemes can often be found from reuse among them. For password cracking itself, it’s up to you if want to filter out disabled accounts. Disabled account hashes can still be helpful for identifying problematic password schemes and historical passwords used by your organization for password filtering purposes. If you wish to keep in disabled accounts for password cracking I would probably recommend filtering the ntds file into a “disabled-hashes” file and an “enabled-hashes” for easier data analysis. I also recommend filtering out machine accounts as well.
cat audit_hashes.ntds | grep -v Disabled | grep -v \\$ > enabled-hashes.ntds
cat audit_hashes.ntds | grep -v Enabled | grep -v \\$ > disabled-hashes.ntds
Step 3: Cracking the Hashes
Now comes the actual “password cracking.” The most commonly used tool is Hashcat, which is free, open-source, and capable of leveraging GPU acceleration to dramatically speed up the cracking process. For an internal audit, even a reasonably modern workstation with a dedicated GPU is sufficient to crack a significant percentage of typical corporate passwords.
Setting Up Hashcat
Hashcat takes a mode flag to tell it what hash type it’s working with. NT hashes use mode 1000:
hashcat -m 1000 /path/to/hashes.ntds /path/to/wordlist.txt
Wordlists
The quality of your chosen wordlists makes or breaks how successful your password audit will be. Some of you might be familiar with the “rockyou.txt” wordlist, which contains over 14 million passwords pulled from a real-world breach. The problem with “rockyou.txt” however is that it’s from 2009 and is now basically only suitable for CTF type exercises and not real-world password audits. If it’s still your current default wordlist you will end up missing a significant amount of very weak passwords.
I heavily recommend using “weakpass.com.” as a resource for your wordlists. The site has a large number of wordlists, ranging from small and targeted to massive files with over 8 billion passwords. To perform a basic password audit, I would recommend starting with “Breach.txt” which contains almost around 500 million password candidates based on passwords people actually use which is frequently updated.
For more targeted audits, building a custom wordlist around your company’s specific terms such as the organization’s name, location, business unit names, and product names could also dramatically increase your results. These can be assembled manually, with the help of LLM models such as Claude or ChatGPT, and/or with tools like CeWL/skweez, which crawls a target website and extracts unique words to use as a wordlist base. For bonus points after you have run through a dictionary audit you can use the cracked passwords to supplement your wordlists for even better coverage.
Rules
While proper wordlists provide the foundation for a good password audit, password rules are how that foundation can be supplemented to catch even more passwords. A rule file tells Hashcat how to mutate wordlist entries before hashing them. Rather than just trying “summer”, Hashcat with a rule set might try “Summer”, “Summer1”, “Summer2026”, “Summer2026!”, “@ummer2026!” and hundreds of other variations automatically.
Similar to wordlists, there are a large number of rule sets out there. They range from less than a hundred to some rule files that contain over a million. Rules allow you to approximate the kinds of patterns humans actually use, which is why even “complex” 14-character passwords can get cracked with regularity. As a starting point I would recommend “OneRuletoRuleThemStill.”
hashcat -m 1000 /path/to/audit_hashes.ntds /path/to/wordlist.txt -r /path/to/rules/OneRuletoRuleThemStill.rule
Masks
For passwords that don’t fall to wordlist + rules, mask attacks let you define a specific character pattern and brute-force within that structure. A mask like “?u?l?l?l?l?l?d?d?d?d!” would cover patterns like “Summer2024!”, one uppercase, five lowercase, four digits, one special character. These can be chained together or combined with hybrid attack modes that mix a wordlist with a mask suffix. For a basic password audit I am not really going to recommend any specific mask attack but did want to include some information for educational purposes and note that targeted and/or comprehensive password audits frequently utilize them.
Step 4: Analyzing the Results
Once Hashcat has run through your chosen attack modes, you can view cracked passwords with:
hashcat -m 1000 /path/to/audit_hashes.ntds –show
This will output the hash-to-plaintext mapping for every hash that was successfully cracked. From here, the analysis is where the real value of the audit starts to materialize.
Some things I look for when reviewing password audit results:
- Shared passwords. How many accounts share an identical hash? Shared passwords across privileged accounts are worth flagging immediately, regardless of what the actual password is. Daily driver accounts sharing their password with their administrative account is also a common issue.
- Pattern clustering. Are a significant portion of cracked passwords following the same scheme? “Company2025!”, “Company2026!”, “Company1!” are not three different passwords from a risk perspective and can be evidence that your password filtering is not doing enough.
- Password schemes/legacy passwords. Is there evidence that onboarding, reset, or default corporate chosen passwords are being used within the environment?
Privileged account exposure. Were any Domain Admin, sensitive service accounts, or other elevated account passwords cracked? - Age correlation. If you can cross-reference the cracked accounts against their last password set date in AD, you can often see whether longer-standing accounts are disproportionately weak, which can inform policy changes around account reviews.
Some Recommendations
Conducting a password audit is just a starting point. The output of the audit is only as valuable as what you do with it. A few things worth considering once you have results:
Force password resets on any cracked account, starting with privileged accounts. Communicate with affected users and, where possible, use the opportunity to educate rather than just penalize.
Feed the patterns you discover: the base words, the schemes, the seasonal variations, directly back into your password filtering configuration. Whether you’re using Microsoft Entra ID Password Protection, a third-party solution, or a custom deny list, real cracked passwords from your own environment are the most honest dataset you’ll get for improving your filter.
Run this audit more than once. Passwords you didn’t crack this time might be cracked with a better wordlist next time, and your environment is constantly changing. Password auditing should be a reoccurring control and not a once and done task.
Finally, don’t underestimate how much expertise can change the effectiveness of an audit. As I said earlier, any audit is better than no audit and by just using the resources above can be an effective way to address low-hanging weak passwords that often plague most organizations. However, if an attacker ever gains access to a password hash, they have much more time and resources to spend to attempt to crack the password that is not reflected by a cursory audit. This is where working with a partner like Depth Security, with both the tooling and the institutional knowledge, can make a meaningful difference in determining the risk your company might be exposed to from crackable passwords.
Conclusion
Password cracking sounds more exotic than it is. At its core, it’s an organized guessing process that exploits the predictable ways humans choose passwords. Conducting a basic password audit on your Active Directory environment is within reach for most security teams, and the output tends to be far more sobering than any theoretical discussion of a password policy ever is.
If your organization doesn’t know where its password risk actually stands hopefully this blog can be helpful towards making a meaningful step towards bolstering your password security.
References
https://www.depthsecurity.com/blog/weak-password-policies-filtering-problem/
https://github.com/fortra/impacket
https://weakpass.com/wordlists/breach.txt
https://github.com/digininja/Cewl
https://github.com/edermi/skweez
https://github.com/stealthsploit/OneRuleToRuleThemStill
Joel Coakley is a Senior Offensive Security Consultant with Depth Security, a Konica Minolta Service. With an extensive background in consulting and network and Active Directory testing, Joel is focused on improving his methods on how to best communicate the risks small and enterprise organizations face alike with practical and tangible feedback tailored to each organization’s environment and business needs. Outside of work, Joel enjoys spending time with his wife, family and friends, spoiling his pets, and going on runs in preparation for a second marathon. If you’re interested in hiring Depth Security for Penetration Testing services, please visit our contact page, or email sales@depthsecurity.com.