Internal Password Auditing Guide

Introduction

You might think that your Active Directory (AD) environment is safe and secure because it is an internal domain. I am here to tell you that you are wrong. If your AD environment is not secure, and once a bad guy gains an initial foothold within your corporate network, it could basically mean game over for you. In my experience with doing red team engagements, attackers can gain initial foothold via countless exploitation paths. Be it social engineering campaigns, leaked credentials or compromised externally facing systems, an attacker’s final goal in targeting an organization will mostly be aiming to achieve Domain Administrator (DA) access on your AD. In my personal opinion, weak password practices play a big role in how an attacker could have gone from a basic compromised account to gaining DA access.

For this reason, this blog post will aim to guide IT administrators in performing an internal password audit. This will help in ensuring the domain accounts you have in your AD have sufficient password security.

History of Windows Hashes

When you create a domain account and specify a password, they are stored within a database file called ntds.dit. By default, they are either encrypted or hashed before storage. Encrypting and storing a password is a big security risk. It essentially means that you are storing it in cleartext, as the secret key to decrypting them is also stored within the ntds.dit file. We will cover this more in later sections on how to decrypt these passwords. As for hashed passwords, Windows have a few ways in hashing them.

LM Hashes

Lan Manager (LM) hashes are the oldest hashes of how Windows store passwords. Due to the way LM hashes are calculated, it is fairly easy to crack them. Firstly, all the lowercase passwords are converted to uppercase, and it is then padded into 14 characters length using NULL characters. The resulting password will then be split into 2 seven-character chunks and hashed separately using DES. In addition, LM hashes do not utilize salts, which means that 2 of the same passwords will always have the same password hash. This means that when a password is cracked, it can be appended to a rainbow table and reused in future attempts of cracking LM hashes. This method will be relatively faster compared to the standard brute forcing way of cracking passwords.

LM hashes are enabled by default up until Windows Vista and Server 2008. However, it could still linger within your AD if you migrated to a newer version of Windows. If you are trying to get rid of those LM hashes, simply do a password reset of those accounts and the hashes will be stored in later, more secure versions of hashes.

NT / NTLM Hashes

NT and NTLM hashes are the same, people tend to say them interchangeably. This type of hashing is the modern method of how Windows store passwords. It solves the 2 main problems LM hashes had, which is the case insensitivity and the splitting of passwords into 2 chunks and hashing them separately. Although not being considered as secure by modern standards, NTLM hashes are calculated using MD4, which is a major improvement from LM hashes. Saying that, it still lacks many features of modern hashes such as Bcrypt or PBKDF2.

I will not dive too much deeper into other types of hashes, as I will need to keep the contents on topic. If you are interested in learning the different types and benefits of other hashes, I might write a blog about it in the future, so keep an eye on our blogpost page!

There are 2 versions of NTLM hashes, v1 and v2. To add to the confusion with terminology, they are sometimes called net-NTLM hashes. There isn’t much differences between the 2 versions other than v2 is cryptographically stronger than v1. Additionally, NTLM v1 hashes are vulnerable to pass-the-hash attacks due to its challenge/response mechanism. In a nutshell, pass-the-hash attacks involve authenticating to systems using the password hashes instead of actual passwords. Meaning that attackers will not need to crack the hashes before logging onto the system. This is again, another topic for another time as it could get lengthy. For now, let’s focus on internal password auditing.

Some Tools To Prepare

Here is a list of things that you will need as a minimum to perform a password audit.

• • Domain Administrator access in your AD – Not exactly a tool but this is a must have
  • Hashcat – If you are using a Windows box to crack hashes
  • John The Ripper (John) – If you are using a Linux box to crack hashes
  • ntdsdump.py
  • Virtual Machines – Windows or Kali Linux (Kali) would be fine

Yeah yeah, I know there are a lot of Windows-based tools out there that you can use so you won’t really need to install a Kali Linux VM. It is your choice with tools, you can go with PowerSploit to grab your password hash database and then use DSInternal built in tools like Get-ADDBAccount to dump the password hashes. I personally don’t like how the output of those tools are, so I chose Impackets’ secretsdump instead, which is installed by default in Kali. Plus, as a system administrator, you should really have a Unix based machine as most cyber security tools out there only reliably works on Unix machines.

Gathering What You Need

Windows Server 2008 and above

Using the built-in ntdsutil tool. Log onto your DC and open a powershell prompt. Run the below commands to dump your ntds.dit file.

ntdsutil
activate instance ntds
ifm
create full C:\ntdsutil
quit
quit

Now you can find all the files you need to perform your audit in the folder at ‘C:\ntdsutil’.

Windows Server 2003 and below

Create a shadow copy with vssadmin, this will essentially create a copy of the whole C drive, allowing you to extract the files you need. Open a command prompt on your DC with administrator privileges, and run the below commands to dump your ntds.dit file.

Create a shadow copy of the C drive:

> vssadmin create shadow /for=C:

Copy the ntds.dit file from your shadow copy:

> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\windows\ntds\ntds.dit C:\Extract\ntds.dit

Save the SYSTEM hive:

> copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8\window\system32\config\SYSTEM C:\Extract\SYSTEM

Copy the dump files to your Kali machine. For convenience purposes, I will continue this blog post by using the ntdsutil example. Don’t worry, both ntdsutil and vssadmin methods lead to the same results, you just have to make sure that you are specifying the correct files when running the tools in later examples. As shown in the below screenshot, you will have two directories, ‘registry’ and ‘Active Directory’.

The ‘registry’ folder will have the ‘SECURITY’ and ‘SYSTEM’ hives. Think of them as your secret keys, and you will need them to decrypt and dump the password hashes stored in the ‘ntds.dit’ file in the ‘Active Directory’ folder.

You will now be in a position to dump the password hashes stored in your ‘ntds.dit’ file. For this, we will use Impacket’s secretsdump tool. This is installed on your Kali machine by default. If for any reason it is missing from your machine, you can git clone their official GitHub repository and use the secretsdump.py script in the ‘examples’ folder.

$ secretsdump.py -ntds [PathTo ntds.dit File] -system [PathTo SYSTEM File] -security [PathTo SECURITY File] LOCAL -outputfile [outputfile]

Depending on what kind of passwords / hashes are stored within the ntds.dit file, you will get different files with different extensions appended behind your output filename. For example, ‘cleartext’, ‘kerberos’ and ‘secrets’ files, as shown below.

You can review them as you like, some of them have cleartext passwords and others have hashes stored in different formats such as AES or DES. For the purpose of this blogpost, you should only care about the ‘ntlm-extract.ntds’ file. Impacket’s secretsdump will decrypt passwords stored in reversible encryption, writing them to the ‘cleartext’ file, as shown below.

If you have a closer look, they are actually domain administrators! So it doesn’t matter how strong your password is, one single misconfiguration and your password will be exposed.

Cracking The Password Hashes

Cracking password hashes typically involve brute forcing techniques by hashing a list of passwords and comparing them with the target hashes. If the password hashes match, it means that you have successfully cracked the hash. Unless the passwords are stored in reversible encryption, they won’t need to be cracked, as mentioned above.

You’ll need to know what format the hashes are before you can effectively crack them. Legacy Windows passwords are stored in LM format. These are legacy, and if you are still running versions of Windows Server 2008 or under, you should probably migrate to newer versions because they are now end of life. Meaning, Microsoft will no longer release updates for them. If you come across a security vulnerability in these versions, they will just ask you to migrate away and install later versions of Windows server. By default, Windows Vista and 2008 stores hashes in LM format, and NTLM format in versions after that. Here are some methods you can use to identify the password hashes you are working with.

Simple and easy, refer to Hashcat’s example hashes page. Just search through them and find the hash format that looks like your password hashes. Some can be really obvious, such as ‘krb5asrep’.

John can also tell you what kind of hashes you are working with, using it’s built in functionalities. Just run it without flags, as shown below:

Alternatively, you can try the hash-identifier tool. This is a Linux based tool and you can easily install it with the command ‘apt-get install hash-identifier’ on your Kali machine. After installing the tool, run ‘hash-identifier’ like the below, and paste your hash value in.

$ hash-identifier

The ‘hash-identifier’ tool will tell you what the most and least possible hash format is, but I personally find this unreliable. As a technical asset, you should always understand what you are working with and take manual steps to verify them.

Other than specifying the hash format, you can include other things like custom wordlists or rules to bring your password cracking process a step further. For example, John comes with the compatibility to use regular expressions and generate passwords. The following screenshot shows a sample rule defined in the ‘/etc/john/john.conf’ file. The comments on the file are pretty self-explanatory; however, if you need further guidance on John rules, feel free to contact us or scroll down to the bottom of the post and leave a comment.

Whilst we have more complex rules written as part of our arsenal, the above rule should suffice for basic password cracking. Obviously, we are not running a charity here and I will not give out too much knowledge. If you are interested in more advance internal password auditing, please do not hesitate to get in touch!

Using John The Ripper

For the purpose of showing how important it is to use custom wordlists and rules, we’ll do some experiments. Let’s start with running John without custom wordlists or rules.

$ john --format=NT ntlm-extract.ntds

As you can see, John defaults to using the ‘Single’ rule. If you checked John’s config file, that specific rule is quite lengthy, and using this rule could potentially take up a huge amount of your time. Unless time is all you have, or if you have a physical machine built specifically for password cracking with ridiculously expensive hardware, I wouldn’t recommend running John with its default rule. Plus, if you don’t specify a custom wordlist, John is just going to use the default wordlist at ‘/usr/share/john/password.lst’. Examining that file and doing a line count shows that the wordlist only contains 3559 entries.

In my experience in the password cracking game, I always find that having a big enough wordlist and a sufficiently complex john rule is good enough to get you started. Skipping to the part where I used the custom rule mentioned above and the famous rockyou password wordlist, I got my results back in just under 3 minutes.

$ john --format=NT --rules=Standard --wordlist=rockyoucustom.txt --pot=testdomainJohnStandard.pot ntlm-extract.ntds

Now let’s take this one step further and use a more complex rule. This ‘Complex’ rule will add special characters at the end of the wordlists provided. It took a longer amount of time to run, but it managed to crack an additional password for us. Do not underestimate this finding, as it could be an account with administrative privileges, such as Domain Administrators. So it could make a great amount of difference depending on whose passwords you have cracked because it means that you will be able to gain access to that user account.

$ john --format=NT --pot=testdomainJohnComplex.pot --rules=Complex --wordlist=rockyoucustom.txt ntlm-extract.ntds

Don’t worry about saving your password cracking results. This is already done and saved in the file you have specified with the –pot flag. In this case, ‘testdomainJohnComplex.pot’.

Using Hashcat

Hashcat is a really powerful password cracking tool; however, I just don’t feel like it fits the purpose we have here which is cracking large amounts of hashes in 1 single session. In my opinion, hashcat is really good at generating passwords in short amounts of time because it uses the GPU of your machine. Meaning that hashcat is good for cracking little amount of hashes, probably two to three at a time. So if you have a hash that you desperately need to crack, use hashcat with good wordlists and rulesets.

Let’s get back on track, here are some examples of running hashcat with and without rules. Firstly, I ran it without rules. Note the number of cracked passwords from the result.

$ hashcat -m 1000 ntlm-extract.ntds rockyoucustom.txt --potfile-path testdomainhashcatpot.pot --force -a 0

If you want to run hashcat with rules, create a new file with the defined rulesets. Here is my example, again, the comments explain what the rule definition does.

Simply use the ‘-r’ flag with the ‘rules’ file as the parameter to run hashcat with rules, as shown below. Note that it came back with additional cracked passwords.

$ hashcat -m 1000 ntlm-extract.ntds rockyoucustom.txt -r rules --potfile-path testdomainhashcatpotRules.pot --force -a 0

You may notice that the way hashcat work with rules is that they use specific words instead of regular expressions to generate passwords. According to their official documentation, regular expressions are slow and by doing rules this way, hashcat could generate 1 billion passwords in 10 milliseconds. In my personal opinion, I would prefer regular expressions as that offers me a more flexible way of generating passwords. Wouldn’t you agree?

Some Statistics For Your Report

Now that you have cracked the password hashes for the accounts in your AD, you are left with a pot file which simply has a list of account and password combinations. Unless you like to go through the results line by line, I would recommend running the ntdsdump.py script I have written. It takes the pot and ntds files as input and produces the following two files:

• • CrackedAccounts.txt
  • ntdsdump.txt

The CrackedAccounts.txt simply has a list of user accounts that are using weak passwords (the hashes you have cracked). For user account privacy purposes, we have omitted the passwords from this list; however, you can still get your hands on the combinations by a simple bash script via grepping the ntds entries against the pot results file.

As we acknowledge the necessity of presenting results to executive level employees, the ntdsdump.txt file will consist of a nicely formatted output with statistics of accounts using weak passwords within your AD. For extra benefits from using the parser tool, we decided to include the local accounts of the DC you extracted the ntds.dit file from. The following screenshot shows an example attempt of running the script.

$ python3 ntdsdump.py --ntds=[ntdsfile] --pot=[potfile]

The output is quite self-explanatory. The ‘Password hash’ column consist of the password hash with the ‘Cleartext password’ column showing its cracked password. The ‘Reuse Number’ column shows the amount of times that specific password has been reused within your AD, which demonstrates a poor password management procedure within the domain. I have mentioned passwords that are stored in reversible encryption in earlier sections of this blogpost. This essentially means that the secret encryption key is stored somewhere within the domain, and Impacket’s secretdump will decrypt it for you. So it doesn’t matter how strong or complex your passwords are. As long as you have them stored in reversible encryption, an attacker gaining access to your ntds file as well as the SYSTEM and SECURITY hive means game over for you. As shown above, the ntdsdump.py tool will list them for you as well.

“But Joseph, the results in your example looks ridiculous. I find it unlikely that users will be using simple passwords such as the ones shown above. Plus, 83% of accounts within the domain are using weak passwords? Are you sure?”

Thanks for pointing that out, this is just a test domain I have quickly spun up for the purpose of writing this blogpost. Saying that, I have done countless internal password audits for clients of ours, and the results of cracked passwords are shockingly close to the example shown above.

Some Recommendations

Now that the technical part of password auditing is over, let’s move onto some password guidance. Here is an unexhausted list of things you can start doing today to improve your password policy.

• • Account threshold and lockout
  • Avoid password reuse
  • Disable reversible encryption
  • Enabling password complexity
  • Implement password managers
  • Multi-factor authentication
  • Use passphrases

Account threshold and lockout

The AD DS service allows system administrators to define account threshold and lockout. Enabling these configurations will allow administrators to lock accounts upon a certain number of invalid logins. The account will be automatically unlocked after the define amount of time has passed. Hence, implementing brute force login protections.

Avoid password reuse

Password reuse has been on the top (among other issues) in security assessments I have performed in the past. This can be attributed to a number of different reasons. Service accounts tend to have higher privileges within a domain, and administrators who have created them could be reusing their personal account passwords. This does not necessarily pose a security risk to your domain; however, attackers could indirectly gain access to the service account if they get their hands on the administrator’s password. Another cause of password reuse could be due to the password reset procedures adapted by the IT helpdesk. Employees who have forgotten their passwords could reset them by initiating IT helpdesk tickets. For convenience purposes, the account passwords could be changed to a simple one, such as ‘Password1’ with no requirements to change it upon first time login.

Disable reversible encryption

Pretty much means what it says on the tin. Avoid storing passwords in reversible encryption within your domain. This can be done by disabling the ‘Store password using reversible encryption’ option in your local group policy on your DC. More specifically, run ‘gpedit.msc’ as an administrator on your DC and navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Account Policies >> Password Policy.

Enabling password complexity

Enabling password complexity will enforce certain restrictions on passwords when users create them. For example, Windows AD requires that the users satisfy at least three of the below requirements when setting a new password.

• • Uppercase letters (A through Z, with diacritic marks, Greek and Cyrillic characters)
  • Lowercase letters (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
  • Base 10 digits (0 through 9)
  • Special characters: (~!@#$%^&*_-+=`|\(){}[]:;”‘<>,.?/) Currency symbols such as the Euro or British Pound are not counted
  • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.

Implementing password managers

It could get difficult for system administrators to keep track of the passwords if they followed the above recommendations. In such cases, using appropriate password managers will aid admins in remembering their passwords. Password managers such as Keepass is a database that stores passwords. You will only need to remember one single password to open the database and access all the other passwords.

Multi-factor authentication

Enabling multi-factor authentication is not something related to password best practices; however, it can help with preventing a compromise of user accounts. Although this can be costly for organizations, I have seen our clients implement this by simply requiring a username and password combination as well as scanning an employee’s name tag to achieve multi-factor authentication.

Use passphrases

Use passphrases instead of passwords. This counters password brute forcing attacks, where an attacker tries every combination of characters to gain access to your passwords. Consider an 8-character length password. As English alphabetical letters consist of 26 characters, an attacker will have to try 8²⁶ password combinations to try all the possible password combinations, hence brute forcing. Throwing numeric values in the mix will result in 8³⁶ password combinations, and requiring passwords to have both lower and uppercase letters will result in (8³⁶)².

Now consider a really long password with 25 characters. The amount of possible password combinations will be (25³⁶)². If you use a really complex password such as ‘Pa5sw0rd45’, you risk the chance of forgetting it. This will then cause frustration and not to mention extra overhead for your IT support in resetting passwords for your users. Plus, the possible combinations of passwords will only be (10³⁶)². If you use a passphrase with 25 characters in length, it greatly increases the combinations of possible passwords. Do the math, it will be obvious whether passwords or passphrases are more secure.

Now that the mathematics are out of the way, coming up with a passphrase is a simple thing to do. Try mashing up three things that you like, add special characters as delimiters and end it with your lucky number. I came up with the below passphrase without giving it much thought, which is 28 characters in length. Good luck to the bad guys in trying to brute force this.

Whisky!Budweiser!Steak!28282

Conclusion

No doubt that improving cyber security in an organization is an expensive operation; however, internal password auditing can be a low cost and highly feasible exercise. In addition, improving your password best practices can resolve the low hanging fruit vulnerabilities that the bad guys can exploit to compromise your assets.

This blogpost serves the purpose of an introduction guide to auditing your passwords. It is already a lengthy post at this point and there are still many other ways and things to consider when you perform such exercises. If you are interested in finding out more, feel free to get in touch with us! We will be more than happy to provide further services for you.