OneRuleToRuleThemStill: New and Improved.
tl;dr – You can find the new OneRuleToRuleThemStill on Github.
It’s been a few years since Will Hunt created the hashcat rule OneRuleToRuleThemAll.rule, the original blog post of which can be found here. It’s had a tweak or two since, but the aim was to create an efficient set of rules that were suited to attacking fast hashes such as NTLM, MD5, SHA1/2 etc.
OneRuleToRuleThemAll was derived from tests against the circa 4.3 million unsalted MD5 hashes from the Minecraft Lifeboat community breach data in 2016. It has 52,000 rules which comprise the top performing rules from the hashcat default, and non-default rulesets shown below.
The new and improved OneRuleToRuleThemStill was tested and created using an AWS g5.xlarge instance and hashcat 6.2.6. The G5 series use the NVIDIA A10G cards which are only ~7% slower than an RTX 3090, making them great for hashcat.
Rule vs Candidate De-Duplication
OneRuleToRuleThemAll has been received well by the community, but there’s always room for improvement. Although it was de-duplicated to remove literal rules that appeared in several of the above tested rulesets, it didn’t account for de-duplication in resulting candidate generation. For example, the rules $0Z5 and $0$0$0$0$0$0 produce the same plaintext (both of them add six zeroes to the end of the candidate) as the $ and Z references show in hashcat’s wiki.
Thanks to duprule which looks for situations like this, OneRuleToRuleThemAll could be brought down from 52,000 rules to 50,088 without any drop in plaintext recovery against the lifeboat hashes. You can see some of the identified candidate duplicates below.
Non-efficient Rule Removal
We’re not done yet though. Not every rule in OneRuleToRuleThemAll resulted in a crack against the Lifeboat data set, so we could also look to remove rules that weren’t efficient at all. To make the test a little more robust and give it more credence, let’s also throw another data breach into the mix to normalise our rules over a larger set of real life passwords.
We used the LastFM breach from 2016 which comprised a little under 21 million unsalted MD5s after de-duplication and found that a further 623 rules didn’t produce a single crack in either Lifeboat or LastFM data sets, so these rules were also removed.
On a side note, it’s worth highlighting that although it won’t matter too much during your cracking sessions, it’s not uncommon to find minor variants in the password count of rockyou.txt depending on the source. For example, some of the rockyou.txt lists found on the default kali install, the Praetorian GitHub, SkullSecurity and Weakpass (which is in fact taken from Daniel Miessler’s Seclists) have slight variations as shown below. The SkullSecurity rockyou.txt variant was used in this testing.
The final total was brought down from 52,000 to 49,465 rules, a circa 5% reduction. This may not seem like a lot, but that’s still 2,535 rules per candidate worth of redundant compute time (against these data breaches as a means of modelling real passwords). As expected, some marginal time gains were observed as a result, however with fast GPUs they won’t be overly noticeable.
The results of OneRuleToRuleThemStill compared to its predecessor are shown below, confirming the 0% performance drop against the breach datasets and resulting in cracking 63.36% of Lifeboat and 69.8% of LastFM hashes.
|Lifeboat (~4.3m unique hashes)||2,960,729 cracked||2,960,729 cracked|
|LastFM (~21m unique hashes)||14,634,893 cracked||14,634,893 cracked|
So Where’s the Rule?
OneRuleToRuleThemStill is available on Github and we hope you find it useful!
If you’re looking to level up your password cracking-fu, our free Password Cracking 101+1 training is available here and contains 15 videos of progressively deeper and more complex attack techniques that go way beyond traditional methods, along with a VM to download containing all the challenges.
You can also join our Discord server where you’ll find a dedicated channel to discuss the training and ask questions.
Finally, a shout out to team hashcat for their ongoing work and in particular to one of the core developers, Chick3nman, who’s been very helpful in answering questions along the way.