The core syntax of hashcat is as follows:
hashcat -a <$attack mode> -m <$hash_algorithm> <$hash (stdin/file)> <$dictionary>
$hash and $dictionary are your target hashes and dictionary/wordlist file. We’ll touch on the other parts below.
This is the type of hash you’re trying to crack. Hashcat supports hundreds of hashes and the chosen hash mode needs to be stated for hashcat to know what to attack. The modes can be found using hashcat –help (note: hashcat cannot attack multiple hash types in a single session but there are other tools that can). Recent versions of hashcat also support hash auto-detection if -m <$mode> isn’t passed, however as several hash types are constructed similarly, false positives can occur and therefore it isn’t encouraged.
For example, MD5 would be -m 0, SHA1 would be -m 100 and so on.
This is the type of password attack you’d like to carry out. Dictionary (referred to as ‘Straight’ in hashcat) is attack mode 0. This is also the default attack type and doesn’t need to be explicitly added if a dictionary attack is being performed. Hashcat’s supported attack modes are shown below and again can also be found by using hashcat –help. This post is only going to cover dictionary attacks, however, future guides might address more.
Enough Talk, Let’s Crack
So now we’ve got an idea of the basic syntactical construction, let’s crack some hashes.
We’re going to use the (arguably) most well known dictionary available, rockyou.txt (available from https://wiki.skullsecurity.org/Passwords amongst other places). It contains circa 14.5 million passwords, was derived from ‘real’ passwords and has shown to be very successful for several years. In the below example we’re going to crack an MD5 hash.
hashcat -m 0 42f749ade7f9e195bf475f37a44cafcb ..\wordlists\rockyou.txt
After you kick off the session, you can get status updates by pressing ‘s’ which will show you speed of attack, ETA for completion and a number of other things. If you’re attacking multiple hashes in a file, cracked ones will be displayed on screen in real time as they’re cracked.
In the above example, the clear text password of Password123 was in the rockyou.txt list so it was successfully cracked.
If you’ve cracked several hashes from a file, you can run hashcat -m <$hash_algorithm> <$hash_file> –show at the end of the session to see all your results.
You might also have usernames with your hashes and hashcat supports this in a username:hash format So you can match the usernames back to the cracked hashes at the end, make sure you run –username when you start cracking, and similarly, –username –show to retrieve them at the end.
Increasing Success with Rules
What if the password isn’t in your dictionary?
Rules do things like substituting letters for numbers, adding a special character at the end etc. that we as society have done for years in the belief it makes our passwords stronger and less guessable.
For example, if the clear text password is [email protected] and your dictionary contains Password, it wouldn’t crack. However if a rule set has been applied that tells hashcat to try replacing a with @ every time it sees it then we’ll get a hit.
Rules, although optional, significantly increase your chances of success and they’re generally worth using in most situations. Hashcat comes shipped with a several rulesets. Below is an excerpt of one of these rules called best64.rule. We’re not going to cover how these rule sets are constructed, but in the lower section we can see hashcat will try appending a number to the end of each candidate in our dictionary.
For very fast hashes like MD5, NTLM, SHA1, I also created a rule called OneRuleToRuleThemAll.rule that works quite well. A streamlined/updated version of this is in the pipeline!
You can use –rules or -r to tell hashcat to use a rule file, e.g. hashcat -m 0 <$hash/file> rockyou.txt -r rules\OneRuleToRuleThemAll.rule
Hashcat might give errors when running, and although we can’t cover them all (many are hardware/driver/runtime related), some basic errors and what they might mean are provided below.
In this example, the file pwned_hashes.txt doesn’t exist in the specified location (hashcat’s own folder by default). Check the file path of your hash list.
Your dictionary doesn’t exist in the specified location. Check the file path.
If the hashes are displayed on screen in the error then it could be a few things:
- You’ve supplied the wrong hash mode (in this instance those were MD5 hashes but -m100 was supplied which is SHA1).
- We can see that the hash file contains usernames at the start, however –username might not have been supplied.
- Your hash file contains special characters that aren’t expected for the algorithm you’ve selected, e.g. a bcrypt hash would contain special characters, however an MD5 would not. Check the expected format of your hashes with, for exmaple, hashcat.exe -m3200 –example-hash