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

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

While updating the various rule sets is fine and dandy, but whatabout taking it a step further and rearranging the order in which they'reapplied? Running the complete KoreLogicrule set takes a lot of time, especially when running them against a respectabledictionary and salted hashes (NTLMv2, Crypt, etc...) When you have limited time during a pentestthis 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 lesssuccessful rules as "Hail Mary passes."

But how do you determine what rules will net the greatestsuccess? Comparing them against oneclient or even a few clients isn't going to give you the sample size you'relooking for. It's time to queue thepassword study from the Global Security Report; once again (spoiler alert) weare collecting hashes to perform a study on for the 2013 Global SecurityReport. Using over 2 million hashes thathave been collected so far as a sample size that cross industries, geographicregions, and encompass large and small businesses, we can give ourselves an ideaof which rules statistically speaking will give us the highest probability ofcracking a password. Then by orderingthese rules properly, one can hope to crack a large percentage of their hasheswithin the first few hours of cracking.

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

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

As you can see, the number ofcracked hashes drops off fairly significantly after ReplaceLettersCaps. However there are some rules that in myopinion should still be applied, specifically ones that prepend and appendnumbers, given that our top rule was AppendJustNumbers. The time tradeoff required for a few additionalrules seems like a worthwhile compromise when you look at their success. Based off this information, here's the listof rules that I'm proposing complete with modifications and rule additions:

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

• Why are you not including 5 and 6 digits inPrependAppendJustNumbers?
  • 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 achievesextremely high success.

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

• What was the wordlist size and hardware was usedto crack the hashes?
  • 8 x 2.6ghz AMD Opteron Cores (Bulldozer) and a 1,167,382word dictionary. Remember, since NThashes are unsalted, the number of hashes you are attempting to crack will notaffect the cracking time, assuming you aren't taking into account possibleprogram 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.