Staying with the topic of weak passwords, today I’m going to show you a free way to check if your employee’s password has been compromised. This is something that Azure AD Micrososft Entra Password Protection, which I described earlier, can’t do.
Sound great? Probably, but before we get started, a little disclaimer.
Read me before you get fired!
You are about to do something that may be considered a security incident. Therefore, it is necessary to get approval for such activities before going into production. If someone approves your request, take it seriously. Work in an isolated environment with no Internet connection. This is very important because you really don’t want copies of your password hashes or Active Directory database ending up on the dark web.
What’s the plan?
Our goal is to compare the password hashes of the local Active Directory domain with those already compromised and posted online in the leaks. If we find any accounts where the hashes overlap, it will be necessary to immediately force a password change for such an account and conduct mandatory security training for its owner.
What do we need?
For our little audit, we will need
- Authorization from your supervisor to perform the activities described here.
- Have I Been Pwned database
- Active Directory database
- DSInternals PowerShell module
- Isolated environment (VM)
Preparations
Have I Been Pwned database download
We will download a database of NTLM hashes of leaked passwords from Have I Been Pwned using PwnedPasswordsDownloader tool.
Manual
On a machine with an Internet connection, download and install .NET 6.0.
Then open CMD and install the PwnedPasswordsDownloader tool.
|
|
Let’s start our “downloader” and save the database to a txt file.
|
|
The database is approximately 29GB. Depending on your Internet connection, it may take several minutes/hours/days to finish downloading.
When the file is ready, copy the pwnedpasswords_ntlm.txt file to the machine where you want to run the comparison.
Saving DSInternals module
We will use the DSInternals tool to analyze our employees’ passwords. However, our VM on which we will perform the comparison doesn’t have access to the Internet. Therefore, we need to download the module to another machine and copy it to the target VM.
Manual
Start PowerShell and save the module by Save-Module
command.
|
|
Then copy the DSInternals folder from the C:\Temp temporary directory to the target machine.
Active Directory database export
The last thing on our list is a copy of the Active Directory database, which is the ntds.dit file, as well as the key used to decrypt it, called the BootKey/SysKey.
Manual
We cannot just copy the ntds.dit file because it is constantly being used by our domain controller.
There are several ways to copy this file available on the Internet. I chose the one that uses Volume Shadow Copy (VSSAdmin) because it doesn’t require you to install or download any external software or utilities.
Let’s run CMD and create a new shadow copy:
|
|
Then we copy the ntds.dit file from our shadow copy:
|
|
The file has been copied to the C:\Temp folder. Now we can do some cleanup. Use this command to delete the shadow copy:
|
|
To decrypt our ntds.dit file, we need a BootKey/SysKey. We’ll get it from the domain controller registry.
To perform the export run CMD and execute the reg.exe SAVE
command.
|
|
When this is done, copy the ntds.dit and SYSTEM.hiv files to the machine on which you will be performing the comparison.
It’s time for an audit
Checklist
We should have four exports on our VM:
- Have I Been Pwned database - file pwnedpasswords_ntlm.txt
- DSInternals PowerShell module - directory DSInternals
- Active Directory database - file ntds.dit
- Domain Controller registry export - file SYSTEM.hiv
Once you have checked all the items on the list, we are ready to begin.
DSInternals import
To “install” our PowerShell module that we downloaded earlier, we simply copy the DSInternals directory to C:\Program Files\WindowsPowerShell\Modules
.
Then we use the Get-Module
command to verify that our module can be found.
|
|
First attempt to perform an audit
Once we have all the elements in place we can start auditing our passwords. We do this with the Get-ADDBAccount
and Test-PasswordQuality
commands, which are part of the DSInternals module.
|
|
Well, this is not the result I had in mind….
Turns out we need to fix our AD database before we can try the comparison again. Well, that’s life. Not everything works out the first time 🙃
Repair of ntds.dit file
We go back to the backup of our domain controller and run PowerShell. First, we want to verify that our database is indeed corrupted. To do this we will use the built-in tool ESENTUTL.
|
|
It looks like you can live with a corrupted Active Directory database 🙂
Unfortunately, we need a working database for our audit, so we will try to fix it.
|
|
We’ve already confirmed that our ntds.dit file is corrupted, so we’re going to deliberately accept the warning and continue to repair.
Success! We did it. The database has been repaired. Just to be sure, let’s check its integrity again.
|
|
ESENTUTL no longer returns an error. We can try to run our password audit again.
Second attempt to perform an audit
Let’s replace our damaged ntds.dit file with the repaired one and run the commands again.
|
|
No more errors, great. Now it’s time to analyze the results.
Findings
Before running the commands, I deliberately prepared the accounts that DSInternals audit “should” flag. These accounts had set passwords that Have I Been Pwned marked as pwned!.
The full report can be found below:
|
|
What lessons can we learn from this?
In our domain 5 users have passwords that were compromised and were part of the Have I Been Pwned database. We should reset the passwords for these accounts immediately.
The user
good.boy1
is an impostor. He has been trying to play the good guy in order to fool us.We have a group of accounts that have identical passwords for some reason. Could it be that the same user has two AD accounts, or maybe it’s a miraculous coincidence?
Three users don’t need to change their passwords at all, ignoring our password policy. For those who are curious, the MSOL_XYZ account is the AD Connect service account.
Of course, the full report contains more detections than the ones I have described. Full details of the Test-PasswordQuality
cmdlet is available on DSInternals GitHub.
Conclusion
Was it worth it?
In my opinion, definitely yes! Despite minor issues with the ntds.dit file, we were able to identify a potential opportunity to hijack the AD user accounts, which could have had serious consequences. Of course, the whole operation could have resulted in a data leak if it had not been done in a controlled environment….
Is there any way to automate this?
Yes, the Get-ADDBAccount
and Test-PasswordQuality
commands can be run on a production Active Directory database using a dedicated service account. The Have I Been Pwned database, on the other hand, can be updated periodically. However, securing this process can be very challenging and requires multiple audits.
Perhaps there is a service that can do this effectively and securely?
Well, Microsoft has such a service, which is included in the Azure AD Premium P2 Micrososft Entra ID P2 plan, but that’s a topic for another post 🤫
Have fun with your tests.