Hey, I just met you, and this is crazy, but here's my hashes, so hack me maybe?

Those familiar with password cracking know that KoreLogic's rule set for John the Ripper has become the de facto standard for password cracking.

However, as with anything technology related, the rules are slightly starting to show their age, specifically with rules designed to take into account years. So, I decided to take on the task of making a few modifications to the rule set, this includes updating them to take into account the current and prior year, but also reworking some of the rules to eliminate some redundancy.

While updating the various rule sets is fine and dandy, but what about taking it a step further and rearranging the order in which they're applied? Running the complete KoreLogicrule set takes a lot of time, especially when running them against a respectable dictionary and salted hashes (NTLMv2, Crypt, etc...) When you have limited time during a pentest this can be fairly problematic - you want to utilize the rules that will net youthe greatest amount of success in the shortest amount of time, leaving the less successful rules as "Hail Mary passes."

But how do you determine what rules will net the greatest success? Comparing them against one client or even a few clients isn't going to give you the sample size you're looking for. It's time to queue the password study from the Global Security Report; once again (spoiler alert) we are collecting hashes to perform a study on for the 2013 Global Security Report. Using over 2 million hashes that have been collected so far as a sample size that cross industries, geographic regions, and encompass large and small businesses, we can give ourselves an idea of which rules statistically speaking will give us the highest probability of cracking a password. Then by ordering these rules properly, one can hope to crack a large percentage of their hashes within the first few hours of cracking.

What I did to achieve these rules was use each KoreLogic rule individually with a respectable dictionary against the set of hashes, capture the number of successfully cracked hashes, then delete the results and start again with the next rule until I had results for each rule. From this I was able to determine which rules netted us the greatest result, and the time it took to completely run each rule.

Below is a table of the results including the percentage of hashes cracked:

As you can see, the number of cracked hashes drops off fairly significantly after Replace Letters Caps. However there are some rules that in my opinion should still be applied, specifically ones that prepend and append numbers, given that our top rule was Append Just Numbers. The time tradeoff required for a few additional rules seems like a worthwhile compromise when you look at their success. Based off this information, here's the list of rules that I'm proposing complete with modifications and rule additions:

After looking at these rules, here are a few answers to questions you might have:

• Why are you not including 5 and 6 digits in Prepend Append Just Numbers?
  • It's simply a time versus success tradeoff. Cracking a 5^th and 6^thdigit takes a significant amount of time to crack with very little result, whereas cracking 1-4 digits not only takes very little time, but achieves extremely high success.

• Why are 2012 based rules netting little success?
  • While I don't have concrete evidence, my guess would be that users might not have been given enough opportunity to change their password yet. We've been collecting hashes since the 1^st of year, and given an average password expiration policy within corporations of approximately 90 days, users may have only changed their password once or twice during 2012 depending on when the hashes were collected.

• What was the wordlist size and hardware was used to crack the hashes?
  • 8 x 2.6ghz AMD Opteron Cores (Bulldozer) and a 1,167,382word dictionary. Remember, since NT hashes are unsalted, the number of hashes you are attempting to crack will not affect the cracking time, assuming you aren't taking into account possible program inefficiencies with large hash lists. The dictionary size and hardware specifications do factor into the time.

I've uploaded the updated ruleset with a few variations to the SpiderLabs github in the following formats:

• All rules built into 1 main John ruleset (Eliminates the need for loops in scripts)
• All rules but kept separated
• Top 7 based on stats built into 1 main John ruleset
• Top 7 but kept separated

We'll be hopefully making updates in the future, and suggestions are defintely welcome, feel free to clone the repository.