Hack and /

In the first two parts of this series, I explained what hardware to get and then described how to use the hashcat software suite to perform dictionary and brute-force attacks. If you have been following along, by this point, you should have had plenty of time to build your own password-cracking hardware and experiment with oclhashcat. As I mentioned in my last column, password cracking is a pretty dense subject. In this article, I finish the series by describing how to tune and refine your attacks further so they can be more effective.

The first area where you can fine-tune your attacks is to put more or less load on your GPU. The -n option, when passed to oclhashcat, changes how much of your GPU will be used for an attack. The documentation says that this value is set to 80 by default; however, on my computer, it seemed like the default was set closer to 40. When I first ran a brute-force attack, the output told me I was using around 70–80% of my GPU. Once I added -n 80 to my oclhashcat command, I noticed I was using between 96–98% of my GPU and had added an extra 40,000 comparisons per second:

/path/to/mp32.bin -1 ?d?l?u ?1?1?1?1?1?1 | \
/path/to/oclHashcat-plus32.bin -m 400 -n 80 \
-o recovered_hashes phpass-hashes

Experiment with passing different values to -n, and see whether your comparisons per second and the percentage of GPU used increases. Be careful though; the higher the number, the more power your GPU is going to use (and if it's not well-cooled, the hotter it will run). Also, if you plan to use the system for other things while you crack passwords, you may notice a greater impact on graphics performance.

Although it may seem like increasing the -n setting is a no-brainer, it turns out that a higher setting really only benefits brute-force attacks. The hashcat documentation recommends you try lower -n values when attempting dictionary attacks. Ultimately, the key is to experiment with both high and low values and see what gives you the best results.

In Part II of this series, I described two types of attacks: a dictionary attack and a brute-force attack. With a dictionary attack, you provide the cracking software with a dictionary full of possible passwords to try, such as all of the words in the English dictionary. A brute-force attack iterates through all possible combinations for a password of a certain length. Because a dictionary attack generally has way fewer passwords to try, it is much faster than a brute-force attack. Although a brute-force attack takes a long time, it also ultimately will find the passwords you are looking for.

It turns out you aren't limited by either a fast, possibly ineffective, attack or a highly effective, but slow, attack. With mask attacks, you can combine the speed of dictionary attacks with some of the thoroughness of a brute-force attack. Mask attacks work by making some educated guesses about the characters that might be used in a password. With a mask attack, you perform a brute-force attack only with a far smaller list of combinations to try all based on a pattern.

Mask attacks make more sense once you see an example. Let's say that you are attempting to crack a password, and you know the password policy requires the user to select at least one uppercase letter and at least one number. As I mentioned in my previous article, you can calculate how many combinations are in a particular type of password by taking the number of characters in the character set, figuring out how long the password is going to be, then raising the first number to the power of the second. So, for instance, if you wanted to do a thorough brute-force attack against the above password policy, you would have 62 characters in your character set (A–Za–z0–9) and with an eight-character password, the number of combinations would be: 62⁸ = 218 trillion combinations.

At 350,000 comparisons per second on my password-cracking hardware, it would take me approximately 7,200 days, or 19 years, to complete the attack.

The fact of the matter is, when you tell most users to create an eight-character password that has at least one uppercase character and at least one number, most users aren't going to generate a truly random password. Instead, they likely will make the first letter uppercase and then use lowercase characters until they get to the end of the password, where they either will add a single number to the end of the password or they will put a four-digit year at the end—usually the year they were born, the year they graduated high school or the current year. A mask attack against the same password policy would build a brute-force pattern where you would just try an uppercase letter as the first character, lowercase for the next three, then either lowercase or numbers for the final four characters. In that case, the number of combinations would be: (26) * (26³) * (36⁴) = ~ 767 billion combinations.

On my hardware, that would take a bit more than 600 hours, or 25 days. Although that's a long time to crack a password, it's still a lot better than 19 years and likely will be effective against a large number of weaker passwords.

To describe this pattern, I use the same custom pattern language with maskprocessor that I used in the previous column for regular brute-force attacks, only in this case, I combine a custom pattern that includes all lowercase characters and numbers with a regular set of character patterns. The final maskprocessor command would look like:

/path/to/mp32.bin -1 ?d?l ?u?l?l?l?1?1?1?1

As you can see, I defined a special mask of ?d?l (0–9a–z) and assigned it to 1, then I created a password pattern where the first character was ?u (A–Z), the next three were ?l (a–z), and the final four were ?1 (0–9a–z). The complete command to attempt this mask attack against my phpass hashes with my new custom GPU tuning would be:

/path/to/mp32.bin -1 ?d?l ?u?l?l?l?1?1?1?1 | \
/path/to/oclHashcat-plus32.bin -m 400 -n 80 \
-o recovered_hashes phpass-hashes

The final way to improve your attacks further is by applying rules to your dictionary attacks. A rule allows you to perform some sort of transformation against all the words in your dictionary. You might, for instance, not only try all your dictionary words, but also create a rule that adds a single digit to the end of the dictionary word. That will catch even more weak passwords and only increases the number of overall combinations by ten times.

Here's an even better example of how rules can help crack more tricky passwords. With the new requirement that users must have numbers in their password, a lot of users have resorted to “leet speak”. For instance, instead of using “password” they might use “p455w0rd”. The fact of the matter is, they still are using a dictionary word—they are just applying a basic transformation to it where a becomes 4, s becomes 5, o becomes 0, e becomes 3 and so on. When you want to crack such a password, all you have to do is add the -r option to hashcat and point it to a file that contains the rule you want to apply. Hashcat uses a custom language to define rules, but it's not too tricky to figure out, and the installation directory for oclhashcat has a rules directory that contains a number of rule files you can use as a reference. It even already includes a rule for leet speak, so if you wanted to perform a dictionary attack that took leet speak into account, it would look something like this if you ran it from within the oclhashcat-plus directory:

/path/to/oclHashcat-plus32.bin -m 400 \
-r ./rules/leetspeak.rule \
-o recovered_hashes example400.hash example.dict

For more information about rules, check out the documentation on the Hashcat Wiki at hashcat.net/wiki/rule_based_attack.

You now should have everything you need to refine your (completely legitimate and white hat) password-cracking attacks. On the Hashcat Wiki, you will find even more examples of types of attacks and examples you can use to improve your odds of cracking a password hash.