Understanding the usage of custom wordlists: Part 1

·

2 min read

Disclaimer: This narrative is intended for educational and authorized purposes only. Author is not responsible for unethical usage of the guide. Names, organization and scenario are fictitious.

Victim: Mr Ahmed Moses

Attacker: Bello Paul

Company: ABC Enterprises

Narrative: In the last one year, attacker Bello Paul has been gathering information on how he can gain access to ABC Enterprise business application. Using social engineering techniques, he has been able to get a valid username for Mr. Ahmed Moses, who happens to be the admin of the web-based business application. His only hurdle is guessing the corresponding password for that account. The password policy document, which for some reasons Bello Paul has got, clearly states that all passwords in the organization has the following characteristics: character length of between 8-12 characters, contains lowercase, uppercase, numbers and special characters. Based on previous data breaches and security reports, Bello Paul has gathered that ?, #, &, !, $, %, *, (, ) and @ are often used as chosen special characters in most passwords that require such symbols. Bello Paul needs to use this gathered information to create a wordlist that would contain the correct password for Mr Ahmed Moses.

For this scenario, the first tool that comes to mind is an open-source pre-installed tool on Kali Linux, known as “ Crunch ”. While there are various parameters that can be used when running Crunch, I’d first enter the command below, which will use the given characters to create a wordlist containing every possible combination within the minimum and maximum lengths. We can now use a tool like BurpSuite to run a dictionary attack, using the wordlist as input for the password field. It will take a while, as the password is quite complicated but eventually, we will get a successful login.

crunch 8 12 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY$ %*() -o customwordlist.txt

Assumptions for the crunch attack above to yield expected results

  • MFA is not setup in the application.
  • Account lockout is not setup (even if it is setup, it could still be bypassed using tools that changes your public ip or/and using different machines if the block is tied to your computer or/and sending request after lockout has expired)
  • No IDS is setup (if this is being monitored then so many failed logins before the eventual successful one should raise a flag)

In the next part of this series, we will see how we can write custom programs using a language of choice to customize the wordlist and limit the number of unsuccessful requests.