Demonstrating Threat Actor Thought Process For Known Password Cracking
Using hashcat to build target specific wordlists
From time to time I have to determine how “guessible” a password is - typically this when the customer gives me the Pre-Shared Key (PSK) during a Wi-Fi penetration test to save me having to blindly brute force it for the sake of time and money. Internally I’ve documented my thought process for how approach demonstrating how likely a given known password would be to a bruteforce attack.
The Base Word(s)
I often focus on the base word in this process - because a good base word will break or make this. Often in Wi-Fi penetration testing we have to generate our own PSK wordlists because organisation’s quite frequentally use some derivity related specifically to them, and it’s just unlikely to appear in common wordlists (AKA SecLists).
When building bespoke wordlists we are should consider using a list of common characteristics that users might have mixed into their PSKs, such as the below (non-exhaustive) list:
- company name ( this characteristic will often be the base word itself for our bespoke wordlists )
- short-form
- long-form
- acronym
- geography
- city name
- suburb
- postcode
- infrastructure
- WLAN name, such a guest network PSK including the characteristic ‘guest’ in the key
- business purpose, such as a Point of Sale network PSK including the characteristic ‘POS’ in the key
The Process
The process itself is very simple - it boils down to 3 steps typically, and involves using hashcat iteratively to generate a list of interim wordlist files.
- create a list of the base words
- mutate the words
- generate permutations of mutated words
Steps
- Generate a wordlist containing the base word converted to leetspeak
echo "[PASSWORD]" | hashcat --quiet -r /usr/share/hashcat/rules/Incisive-leetspeak.rule --stdout >> word.leet
- Iterate through each of the words in the wordlist, toggling the case of each letter.
hashcat --quiet word.leet -r /usr/share/hashcat/rules/toggles3.rule --stdout >> word.toggle3
Typically, I would not go beyond using toggle4.rule ruleset, especially if I will be eventually writing the output of later steps to disk as well.
- Prepend a mask using hashcat
hashcat --quiet word.toggle3 [--stdout] -a 6 -i --increment-max [N] [MASK]
When append masks to the end of wordlist’s entries, I prefer to keep this workload in memory. However, there have been cases where I need to pipe to the output into subsequent commands (see in the below sections) - in those cases, I would include the --stdout flag in step 3 as well.
Typical final use case
Below is the command is the typically format I would use in demonstrations, I like to use -i --increment-max [N] to still emulate somewhat speculative bruteforcing - rather than 100% min-max precision.
echo "[KNOWN PASSWORD]" | hashcat --quiet word.toggle3 -a 6 -i --increment-max 2 ?d?d
Generating the NT hashes
While I originally created this process for PSK cracking, it is easily appliable to other scenarios. Over this weekend, I was asked to answer the question (which also prompted me to write a blogpost about it) could I generate a list of NT hashes for a password starting with the letter “p” and ending with the number “1”. The essence of the questin was could I generate a NT hash table. I modified the step 3 (see above) to directly the pipe the hashcat output through a OpenSSL operation that would perform MD4 hashing - resulting in the NT hash.
[HASHCAT] | xargs -I{} bash -c 'hash=$(echo -n "{}" | iconv -f UTF-8 -t UTF-16LE | openssl md4 | cut -d" " -f2); printf "%s,%s,%s\n" "{}" "$hash" "${hash^^}"' >> [OUTUT CSV]