You Shall Not Pass: Auding weak passwords.
Armsys Co had a security breach last month. Bob from accounting had his Office 365 credentials compromised. The attacker managed to exfiltrate some emails and download some files, luckily the company’s secrets were not affected. The SOC team asked Bob to change his password and he did it immediately. At the same time, the SOC team added Bob’s account to a high-risk user group.
Yesterday the SOC realized that Bob’s account was being accessed from an IP that belongs to a private VPN, the same the attacker used before. They disabled Bob’s account and started to look at how the attacker managed to get Bob’s password again. An analyst interviewed Bob about his computer and whether he received any suspicious emails. He confirmed that Bob didn’t receive any weird email and he didn’t execute any suspicious program on his PC. The analyst asked him one last question: Do you happen to use the company name on your password? Bob’s answer is affirmative to this.
The analyst realized that Bob used passwords like Armsys2023 or Amrsys1#, passwords with the company name had been banned but as there was no enforcement users still used these weak passwords. What can we do to solve this? In this blog, I will show some free tools that can help you ban weak passwords. This is a common problem that we can solve and is a problem I struggle to find a solution that is inexpensive and effective.
First, let’s do some password auditing with the Password Exposure Test tool from Knowbe4 and then start banning with Lithnet Password Protection. Lastly, I will mention some other tools you can use if you have those at your disposal.
Audit First
Let’s be honest, if we attempt to make a change without showing that we are tackling a problem we won’t receive the help we need. We need to show that the organization has a problem and we can make a change to solve this. A compromise like the one I described can be the start of change but we don’t want to wait until we have a compromise in our company. So, let’s start showing that there are users not following our policies and are using weak passwords.
For this, I would use the Password Exposure Test is simple to use and gives really good information that can help you identify vulnerabilities. This tool will cost you 0 dollars with 0 cents, yes it’s free!! Well, you need to give your corporate email on the following page: Password Exposure Test | KnowBe4. I understand if you see this as a way for them to send you ads but at least in my experience they don’t flood you with spam.
After registering you can download the tool installer from this page. You will need to install it on a secure computer or server as this tool will collect information from the domain controller and you don’t want attackers to get this information. Their product manual is good at explaining what you need to run this tool, please don’t forget to give the correct permissions to the user you will use. Password Exposure Test (PET) Product Manual – Knowledge Base (knowbe4.com)
Once you have it installed and with an adequate account you just need to run the tool with the correct credentials and pointing to the domain controller (DC). In this example I use a test domain called core.local and the DC is on 10.10.10.2. I’m using the administrator credentials because I’m lazy but you should avoid this, as the manual says: “We strongly recommend creating a new account in AD with these permissions for the purpose of running this test.”. Create the account, use it, and don’t forget to disable it after doing the test.
After you click “start test” the tool will start collecting the necessary information, it will take some minutes. At least in my experience with some domains with more than 2000 users it can take 20 to 30 minutes, but your mileage will vary. Once you finish this you will get the following report:
You can see we have different vulnerabilities on this test domain. There are 177 missing pre-authentication vulnerabilities, in this case I will ignore them as it’s out of the scope of this blog. We can see that we have 17 users with weak passwords and 24 users that share passwords. You may be asking what are the passwords this test considers weak? Well, we can see the passwords the tool uses for the test in the following file: C:\Program Files (x86)\KnowBe4\Password Exposure Test\data.bin. As you may guess this does not include custom weak passwords like the one Bob used.
I would recommend making a large list of possible weak passwords based on your company name, location, economic sector, and others. For instance, Armsys Co is an energy company that works in South America (Peru, Chile, and Argentina) and it has some wind farms called Windis. You can use this information to generate some passwords to feed the data.bin dictionary. (I’ll try to do a blog on this later)
Even without this change, you may find some weak passwords, but I would encourage you to add more passwords to your dictionary. Now with this information, we can look if the users that have weak passwords have high privileges. You can search using the active directory built-in tools and once identified this you can make a pretty report for your management to understand the risk (yes I know we all love to write reports but we need to do it).
Conclusion
What are you waiting for? An invitation? It’s your turn to audit your passwords.