Overview

The goal of this lab is to learn more about utilizing the skill of password guessing and the associated process of analyzing existing public facing content.

Useful Commands and Instructions

We're going to start by utilizing nslookup similarly to what was applied in Activity 3.1:

nslookup [IP_ADDRESS] [DNS_SERVER_ADDRESS]

For example:

The target webpage has user bios, which means that we have potential usernames, and personal descriptions may provide some words to enter into a wordlist.

Notes on using CeWL

The command below utilized the built-in Kali tool "CeWL" which uses a spider that can be used to generate word lists. The options utilized in the command below are as follows:

1. -d is for the depth. This specifies how many directories deep to search (since we're specifying the page we want we set this to just 1, default = 2
2. -m is used to set the minimum word length (default = 3, I specified for clarity/intent)
3. -w [FILENAME] is used to direct output to a file as opposed to the standard output (typically printed to console)
4. wrap up the command by specifying the site URL

Here's the man page for reference: https://manpages.org/cewl

cewl -d 1 -m 3 -w cewlwordlist[CONTEXT].txt [SITE_URL]

From this point, I edited the wordlists to remove all unlikely words (ex. "and","the", etc.)--this was the simplified list. Then I trimmed some more based on the content of the user's bio--this was the small list.

The next step in this process was to mangle the small wordlists. By using rsmangler, we're able to take the words from the word list and make them possible passwords:

rsmangler --file [SOURCE_WORDLIST] -x 12 -m 9 -l -s -e -i -p -u -a --output [OUTPUT_FILE_NAME].mangled.txt

(Note that the ".mangled" file extension isn't necessary, it just helps as a naming convention. All of the switches mentioned as followed (besides --file and --output) are specified to FILTER OUT those results. --file specifies the source file to input, -x specifies max word length, -m specifies minimum word length, -l specifies "lowercasing" the word, -s swaps the case of the word, -e adds "ed" to the end of the word, -i adds "ing" to the end of the word, -p permutates all of the words, -u uppercases the word, and -a creates an acronym based on the words in the list.

Rsmangler documentation

Notes on medusa, hydra, or ncrack

When using hydra as the password cracking tool, there are a couple of ways to implement based on the services and source lists. In the screenshot above, you'll see the implementation of using the mangled wordlist (after mangling Frodo's shortened wordlist) that's directed to attempt passwords against the admin page. The -l parameter means "login", which is followed by a username. -P points hydra to a password list, which you must also specify. -t also specifies the number of threads on the server (in this case, 4). The last part of the command is the target--when using HTTP, you need to be more specific, in this case, specifying the HTTP GET request for the admin directory. It's essential that / is specified at the end of the URL.

Here's the command for ease of use/reference:

hydra -l [USERNAME] -P [PASSWORD_LIST] -t [THREAD_NUM] [TARGET_TYPE]:[TARGET_ADDRESS]

When this is applied to SSH, the earlier part of the command remains the same (assuming that the username remains the same), and the [TARGET_TYPE] must change. Here's an example of the cracked SSH password:

Issues and Troubleshooting

Initially, my wordlists were WAY too long for reasonable lengths of time running Hydra. In order to work around this, I further trimmed my initial wordlists, making sure to omit anything that I considered unlikely passwords. This allowed me to discover the HTTP passwords effectively, but the SSH passwords were significantly more difficult. I ultimately attempted using a different username, and this was the issue--the SSH users had a different username scheme. The existing wordlists contained the SSH passwords, but the naming convention for SSH was instead "[FIRSTNAME].[LASTNAME]".

Questions/Reflections

The tools used in this lab were fairly straightforward, however, the difficulty occurred due to how long Hydra would sometimes take to run, and you'd need to try different naming conventions for the usernames. Overall, it shows that password guessing can sometimes be effective, however, it can also take a very long time.

Additional reflection material is included directly in the lab submission to retain privacy.