Active Directory Password Auditing with NtdsAudit and NThashes

Wouldn’t it be great to know if any of the accounts in your Windows Active Directory were using passwords that have been seen in breached databases? In this article, I will show you how you can use the NtdsAudit and NThashes tools to do just that. 

My first introduction to this tool began when I was looking for something to help me conduct password audits for my client’s environments. I was working as a Compliance Analyst and needed something that wasn’t just going to tell me if a password was strong or weak, but something that could compare these passwords against a whole database of passwords extracted from breached databases. 

In fact, this kind of password checking is a requirement called out in NIST 800-53 under control number IA-5(1).

From NIST SP 800-53 Rev. 5

For password-based authentication: (a) Maintain a list of commonly-used, expected, or compromised passwords and update the list [Assignment: organization-defined frequency] and when organizational passwords are suspected to have been compromised directly or indirectly; (b) Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a);

“The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters.”

I thought auditing an environment to identify accounts using previously compromised passwords was a fantastic idea. We may feel safe when a password passes all complexity checks, but if this password has been seen in compromised databases, it is no longer unique. It is common for these breached passwords to be put into large lists that are leveraged during password spraying or brute-force attacks.

The passwords we’ll be working with are all hashed – both the passwords we’re generating and the passwords we’re comparing them to. The database we’ll be comparing against is the “haveibeenpwned” database maintained by Troy Hunt. It contains the hashes of passwords found from thousands of different breaches. These passwords are hashed in order to provide useful data for security researchers and their tools, but also protect the anonymity of the data itself. You can read more about the inception and intention of this database in Troy’s own blog post here. 

“The entire point is to ensure that any personal info in the source data is obfuscated such that it requires a concerted effort to remove the protection, but that the data is still usable for its intended purposes.”

So, while we may be playing fairly (and safely), threat actors are not and probably already have lists of all these passwords and their associated usernames in cleartext. That’s what makes previously compromised passwords dangerous – they’re free game and require very little effort to make use of. Threat actors love low-hanging fruit.

Now that we know why it’s important to do this kind of auditing and who the people are that are helping us in this goal, let’s look into how to actually perform the audit. 

Disclaimer: Only perform this process on systems where you have express permission to do so. 

Dumping Active Directory Data Using ntdsutil

The first step in this process is to extract the password hashes that you would like to test. This can be done many different ways, but the easiest way I’ve found is to use the official Microsoft tool ntdsutil. This tool is built into Windows Server 2008 and higher that have the AD DS or AD LDS server role installed. The bonus with using this tool is that, since it’s an official MS tool, it’s not typically blocked by antivirus software. However, you may get some alerts from other system monitoring tools. 

You can verify ntsdutil is installed and available on your machine by opening a command prompt and typing “ntdsutil.” If it’s there, you will get a UAC prompt (click yes) and another command window will open up for ntdsutil.exe.

If you can’t find this tool on your server or would like to investigate alternate installation options, see the official Microsoft documentation here. 

Once you know that ntdsutil is installed and ready to go, issue the following command in a fresh, elevated command prompt to create the Active Directory dump under c:\ad-pw-audit

*Note – this should be considered a sensitive file, so make sure you output it to somewhere safe and don’t freely share it with others.

Extracting Password Hashes Using NtdsAudit

Now that you’ve got the ntdsutil files created, you’re good to move on to the next step – downloading and running the NtdsAudit tool created by dionach. We’ll be using this tool to extract the hashes from the Active Directory dump, but it is a nice tool that has some additional functionality when it comes to auditing your environment. You can see all of its auditing superpowers here.

Download the NtdsAudit.exe from the releases section on the creator’s github and place it in a folder that contains your ntdsutil files (in my example, c:\ad-pw-audit). Just be aware that NtdsAudit may trigger some antivirus alerts; you may need to temporarily whitelist this software in order to run it.

You’re ready when you’ve got NtdsAudit.exe downloaded and saved in your folder created by ntdsutil: 

Open an elevated PowerShell prompt in this folder and run the following command to begin the audit and extract the password hashes:

Again, keep this dump.txt file secure. It should be completely deleted from the system after you’ve completed your audit and should not be saved anywhere it can be easily accessed by others.

Running the audit successfully results in a lot of fun stats that are extremely useful in their own right. This report isn’t why we’re here, but it’s cool to review either way and a good reason to come back and use NtdsAudit in the future. 

Once this completes, you will be left with the “dump.txt” in your current working directory. Having this file generated, we can move on to the next step.

Comparing Extracted Hashes with the HIBP Database

The “dump.txt” is the file we’ll use to compare the extracted hashes to known compromised passwords in the HIBP database. The first thing you must do is format the exported data so that it is readable by the API. To do this, copy and paste this code provided by mdjx into your active PowerShell window: 

Once the data is formatted properly, we’re ready to send to the API and see the results of our hard work! Use the code provided by mdjx to query the API: 

$Accounts | % {$Acct = $_; ($acct.NTHash).Substring(0,5) | % {$Hashes = Invoke-RestMethod https://api.nthashes.com/search/$_; if (($Acct.NTHash).Substring(5) -in ($Hashes.split(":")) ) {Write-Output $Acct | select Username, UID, Disabled, IsAdministrator, IsDomainAdmin, IsEnterpriseAdmin} Start-Sleep -Milliseconds 100}}

If you’re looking to have these results saved to a file so you can review them later, you can append some code at the end to tell it to export the results to csv: 

Append this to export to a csv:

All together: 

The API may take a minute or two depending on how many accounts you are auditing, but should eventually return the results we’re looking for. You’ll know it’s done when the PowerShell prompt returns and you can type in the PowerShell window again. 

As you can see in my test lab, I have two user accounts using passwords that were found in previously breached databases. This report is reasonably safe to share with others, but only those with a “need to know.” Treat this file as you would any other kind of vulnerability report on your environment. To a threat actor, this is basically a list of easy targets. I would highly recommend that you delete the entire folder you’ve been working out of (in my case, c:\ad-pw-audit) and save only the report.

Using Password Audits for NIST Compliance

In my previous work as a Compliance Analyst, I would perform these password audits for our clients pursuing compliance with the NIST 800-53 or 800-171 compliance. It was incredibly valuable to them to be able to provide a full report of accounts using compromised passwords. 

If you do present a report like this to a client, be sure to convey the message accurately and not try to scare them into action. Just because an account is on this list doesn’t mean it’s compromised or in immediate danger. Instead, celebrate that these accounts were found; now that we know they’re there, we can do something about it! Getting these accounts updated with new passwords is a good preventative step that can help keep you or your clients out of danger.

Credit must be given to the creator of the nthashes tool – mdjx and the creator of the NtdsAudit tool – dionach. A walkthrough and write up of the process performed by mjdx can be found here: www.nthashes.com. Credit also goes to Troy Hunt for building and maintaining the HIBP website. 

Achieving NIST Compliance with Blumira

Blumira is a cloud-based SIEM with threat detection and response that can help organizations achieve NIST 800-53 compliance. Our platform alerts your team about critical cyber threats in real-time and provides automated and actionable response capabilities that reduce the overhead associated with traditional SIEM products.

With Blumira’s free edition, secure your Microsoft 365 environment in seconds with coverage for unlimited data and users. With our free edition, you can:

• Use guided security playbooks to easily respond to threats 
• View summary dashboard and reports
• Set up in seconds using our new feature, Cloud Collectors 

And now you can take your security to the next level with our free, comprehensive Domain Security Assessment! Sign up here to uncover potential vulnerabilities across your domain.