John the Ripper loves cracking Active Directory password hashes and your users love ‘Password1!’
(This is the second of a three-part series on Microsoft Active Directory password quality auditing and password cracking)
Following on from part 1 where we used DS-Internals to do some basic password quality auditing, in this post, we extract all of your password hashes from Active Directory and crack them with John the Ripper.
Cracking passwords with DS-Internals
In the previous post, we covered using DS-Internals to do a password quality audit. We did this by using the PowerShell module to examine account configurations for vulnerabilities and we provided a plain text password dictionary for brute forcing our users’ passwords. While the audit for configuration insecurities is excellent, the literal dictionary of passwords to use for cracking is not the most efficient way to do it. Nor is the output of sufficient quality to be as useful as it could be. This isn’t a criticism of the tool, it just isn’t what the tool specialises in.
When you provide a list of thousands of passwords, including globally well-known passwords and company-specific ones such as ‘Company1’ or ‘C0mp4ny123!’, DS-Internals will only tell you is a user password is found in that dictionary. It won’t suggest other similar formats such as ‘Company11111111’ which could also be in use. This is great for identifying users who need to change their passwords to something more secure, provided that you managed to create a comprehensive wordlist on your own. Which most of us probably can’t.
A better way to crack Active Directory passwords
DS-Internals is designed to let us overcome this challenge. Built in is an extensive hash export utility that will provide a range of hash table formats. My personal favourite cracking tool is John the Ripper and output support is built right in.
To export all user hashes from AD use the following:
Get-ADReplAccount -All -NamingContext 'DC=base55, DC=io' -Server rootdc01.base55.io |
Format-Custom -View JohnNT | Out-File -FilePath users.txt -Encoding ascii
This will produce a text file (users.txt) containing all usernames and hashes in a format that John will automatically detect and begin to crack. This file is an export of Active Directory’s most guarded secrets. Protect it the way you would your domain controllers. And don’t leave this file lying around for anyone to find.
Introducing your users to John
John the Ripper works on Unix based systems such as Linux, MacOS. If you’re looking for a Windows or Android alternative the developers of John recommend Hash Suite which is created by one of the project’s contributors.
With John installed, move your users.txt file into a suitable directory on the host machine and then let’s get cracking! As this file is so critical, I recommend transferring over an encrypted tunnel such as SCP. On a Windows machine, WinSCP will do the job for you. Once moved and confirmed to be complete I would also permanently delete the users.txt file from your Windows machine (which should also be on an encrypted disk already).
Thanks to the output from DS-Internals we can start to crack passwords with just one command.
john users.txt
This will run John in default mode and usually takes care of really insecure passwords within a matter of seconds. In default mode, John will write cracked passwords to $JOHN/john.pot where $JOHN is the home drive of the user running the process. This will usually be ~/john.pot in reality. To print the passwords to screen add –show
john users.txt --show
How John the Ripper works
John has three main modes of operation:
- Single mode
- Wordlist mode
- Incremental mode
By default, John will use all there of these and in that order until there are no passwords left to crack. Left alone, John will run forever until the incremental mode loops through every possible combination of characters until one works.
There is also a fourth mode: External. This is for coding and using your own cracking algorithms but I think that’s a little out of scope for what we’re doing here.
Single crack mode
Single crack mode runs first and is usually the quickest to complete and gain results. In order to crack passwords, it uses “login names, “GECOS” / “Full Name” fields, and users’ home directory names as candidate passwords, also with a large set of mangling rules applied.’ (Taken from the official documentation). The mangling rules do literally that, taking the username and applying letter for number substitution, case shuffling, reverse order, adding numbers, and so on.
Wordlist mode
If single mode fails to crack all of the passwords John then moves onto wordlist mode. This works like the dictionary we supplied to DS-Internals except it will also include all of the mangling rules for every dictionary word just as it did for Single mode. The default wordlist is the included ‘password.lst’ but even the authors recommend using a larger and better wordlist. This can be done using the –wordlist=’filename.lst’ option. You’ll also need to add –rules to apply mangle rules to your custom dictionary.
john --wordlist='mydictionary.lst' --rules users.txt
Incremental mode
This is the most comprehensive and therefore time-consuming mode. If we get past single crack and wordlist mode then we’re onto plain old password brute forcing, starting from ‘a’ going all the way up to ‘9999999999999999…’ and covering everything in between.
What we’re trying to achieve
The goal of all of this isn’t to crack the passwords of all of our users. If we wanted to do that we would just store them with reversible encryption (which is still bad). Our goal is to crack the passwords that are easy to crack. By using a wordlist tailored to our organisation in addition to the mangle rules we can see who is using insecure passwords and who is using less insecure passwords. If we can’t crack it it’s probably strong enough for now.
In Active Directory password audits part 3:
Now that we have extracted and analysed the metadata of all users in Active Directory and extracted and cracked the hashes of our users’ insecure passwords, it’s time to move onto the next step: preventing bad passwords and enforcing better Active Directory passwords.
Leave a Reply