The bad guys are already doing it. Here’s why and how you should do it too.
(This is the first of a three-part series on Microsoft Active Directory password quality auditing and password cracking)
If your company has anything exposed to the internet, attackers are already brute force attacking your user’s passwords. All day, every day. There are very few things you can do to stop them. Our best hope is to slow them down as they circumvent every countermeasure we put in place and ensure that users have passwords strong enough to withstand a low volume brute force attack.
With account lockout policies in place attackers will either cause a denial of service against your users by locking out legitimate employees, or force you to implement a lockout expiry time in an attempt to reduce the number of incoming service desk calls. Once lockouts are set to expire your lockout policy rules are simple to identify and circumvent. When that happens the only thing you have on your side is time.
If you set your extranet (from the internet) failed login attempt limit to 3 every 15 minutes, attackers can try up to 96 passwords per day, per user account. Combine that with a password spray attack against your organisation and there’s a good chance they’ll guess one right eventually. This is why it is key to perform password quality audits and blacklist bad passwords.
Multi-factor authentication without account lockouts just moves the problem. Given enough time attackers will guess weak passwords. Yes, they will be stopped by a second factor authentication request, but there’s a strong chance your users are using that same password on other services that don’t support MFA.
Password spraying brute force attacks
Password spraying attacks are similar to standard brute force attacks. The difference is, instead of targeting every single password against one user, they attempt every single user against one password then move onto the next password. The former will quickly lock out a single user. A password spray however might take several hours to loop back around to the first account if you have thousands of users.
Smart extranet lockout tools which identify and block password spray attack at the source are of little value when attackers proxy their requests through thousands of nodes in a botnet. By not using the same IP twice in any reasonable period of time it is difficult to differentiate real users from the bad guys.
Why your employee passwords are bad
You have a ‘strong’ password policy in place. The old standard of ‘minimum of 8 characters, 3 out of 4: Uppercase, lowercase, numbers, and symbols’ doesn’t cut it anymore. There’s a good chance someone is using Password1! or something similar which meets all of these requirements and is guaranteed to be on a wordlist somewhere.
You have a ‘really strong’ password policy in place. ‘Minimum of 20 characters, 4 out of 4: Uppercase, lowercase, numbers, and symbols’.
Password1!Password1!
‘Passwords must be changed every 30 days. No password reuse for the last 12 passwords’.
Password2!Password2! … Password12!Password12!
Users will also share the same passwords across facebook, hotmail, iPlayer, and that poorly secured website belonging to the local florist. That florist is going to be hacked and when that happens their password is in the public domain. Then it’s only a matter of time before someone tries it against their other accounts.
It’s not their fault though. Their job is to be sales representatives, production managers, customer support agents, designers, and all of those other things. Our job as IT professionals is to do what we can to protect their accounts and to provide support, feedback, and training where and when it is needed.
So what can we do?
Brute force your employee passwords (or to put it politely, perform a password quality audit)
Microsoft Active Directory is the standard for user management at hundreds of thousands of organisations around the world. We create user accounts, enforce password policies, enable single sign-on for other applications, then suffer from security compromises with phished, leaked, guessed, or shared credentials on a daily basis. We enable multi-factor authentication in the hope that if the first factor (the password) is compromised then the second factor won’t be.
The world isn’t perfect though and not all systems support single sign-on and multi-factor authentication. There will be times when no-matter what you do it won’t be good enough for the weakest account. If the bad guys are already attacking your user accounts then you might as well join them.
Brute forcing the dumb way.
Firing off millions of username and password combinations will achieve the exact same results the bad guys get. You’ll lock out accounts and fill up your event logs with needless noise. It will get the job done… eventually
You could use something like THC-Hyrda to attack across the network, either from inside your firewall or outside, generating a lot of noise and taking a lot of resource, or you could do it a better way.
Brute forcing the smarter way
Since you own these accounts and the infrastructure they run on, you have an advantage that the bad guys don’t: direct access to the Active Directory account database. With this you can pull and decrypt all of the encrypted password hashes and metadata of all accounts for analysis. If the passwords have been stored with reversible encryption instead of one way hashes you can simply decrypt them to plain text passwords.
(Note: Storing passwords with reversible encryption is a bad idea. Please don’t do this unless you really, really must, usually to make legacy stuff work.)
DS-Internals is a suite of powershell cmdlets that perform a range of Active Directory tasks. This includes an audit of password quality for all accounts on your domain. You run it using an account with replication read access to the AD user database. It pulls all account data including secrets for local testing and analysis away from the operational AD infrastructure. With this it can perform checks for:
- Passwords stored using reversible encryption
- Accounts with LM hashes (LAN Manager hashes) in addition to NT Hashes
- Accounts with no password set
- Accounts with passwords that can be found in a given password dictionary
- Groups of accounts with the same password
- Computer accounts with default passwords
- Accounts missing Kerberos AES keys
- Accounts that do not require Kerberos pre-authentication
- Passwords protected by weak encryption only (e.g.DES encryption)
- Administrative accounts which are allowed to be delegated to a service
- Passwords that will never expire:
- Accounts that are not required to have a password
All of these checks are performed away from Active Directory leaving your users and event logs unaware of the offline brute force attempts.
The Biggest benefits
While all of these assessed areas will identify things that need improvement, the biggest risk from the outside world are:
- Accounts with no password set/are not required to have a password
- Accounts with passwords found in the given password dictionary
The password dictionary is the key here. You’ll likely want to do two things:
- Create your own organisation specific wordlist for passwords you know are in common use. Things like:
- ‘Companyname1’ to ‘Companyname999’
- The standard password that servicedesk use when setting up accounts or resetting passwords over the phone
- ‘Password1’ to ‘Password999’
- Use the top1000 – top 10,000 passwords from libraries like https://github.com/danielmiessler/SecLists/tree/master/Passwords
Putting it into action
With two powershell commands and a user with AD replication privileges we can install the DS-Internals module and run an audit of all user passwords in the domain against our top 10,000 wordlist from SecLists
#Install the DS-Internals powershell module
Install-Module -Name DSInternals -Force
#Perform an online active directory account pull and audit passwords against a wordlist
Get-ADReplAccount -All -NamingContext 'DC=base55, DC=io' -Server rootdc01.base55.io |
Test-PasswordQuality -WeakPasswordsFile C:\IT\10-million-password-list-top-10000.txt
Depending on how old your Active Directory database is and how well it has been maintained, this will either give you very little (great!) or lots (not so great!) output.
Accounts with password that do not expire is useful for understanding the extent of the problem but chances are you’ll have no idea what most of the accounts are for or who they belong to. Years of churn will leave artifacts behind that used to be well named but now might as well be hashes themselves.
To make more sense of it the following PowerShell command will give you a list of all users who’s passwords are set not to expire, including the Distinguished Name (full path to the OU).
get-aduser -filter * -properties Name, PasswordNeverExpires | where {
$_.passwordNeverExpires -eq "true" } | Select-Object DistinguishedName,Name,Enabled
My preference is to export this to a csv with:
get-aduser -filter * -properties Name, PasswordNeverExpires | where {
$_.passwordNeverExpires -eq "true" } | Select-Object DistinguishedName,Name,Enabled | Export-csv c:\pw_never_expires.csv
Then import into Excel, move the DistinguishedName column to the end, split by comma (unless you’re account names can have commas in them), them put them back together in reverse order missing out the CN value to make it more sort-able, then copy the formula all the way down..
=CONCAT(M3,L3,K3,J3,I3,H3,G3,F3)
This will enable you to see the OU structure your organisation is using and makes it much easier to work out what the accounts were intended for.
In Active Directory password audits part 2:
Better Active Directory password cracking with John the Ripper – using DS-Internals to export all password hashes.
Leave a Reply