The rule-based attack (-a 0 with one or more -r rules files) is one of the most complicated of all the attack modes. The reason for this is very simple. The rule-based attack is like a programming language designed for password candidate generation. It has functions to modify, cut or extend words and has conditional operators to skip some, etc. That makes it the most flexible, accurate and efficient attack.
The rule-engine in Hashcat was written so that all functions that share the same letter-name are 100% compatible to John the Ripper and PasswordsPro rules and vice versa. Later we started to introduce some of our own functions that are not compatible. But these functions got their own letter-names to avoid conflicts.
This is a very unique hashcat feature. With hashcat you can generate random rules on the fly to be used for that session. This is a good thing if you are out of ideas on what to do next when you have already tried all your rules on all your dictionaries. There are three configuration parameters:
The 'p' character position code (see Github here) memorizes the position of the Nth instance of a character, and makes that position available for use in rules that work with positions within the string. 'p' becomes available automatically when using '%' (reject plains unless they have at least X occurrences of a specific character) and '/' (reject plains that do not contain a specific character).
Now that we can see the benefits of rules, we will now define some rules to use in our own rule-based attack. To define our own custom set of rules to use with hashcat, we need to store them in a file.
In this guide, we created and used our own custom rules in hashcat to perform a rule-based attack. We started by covering what rule-based attacks are and why they are used. We then proceeded to create our own rules and use the rockyou dictionary to crack MD5 hashes from the Battlefield Heroes leak in 2013.
All except d3adhob0, hob064, KoreLogicRulesPrependRockYou50000 and _NSAKEY.v2.dive are included with hashcat. A good mixture of rule files should allow us to identify which individual rules are the big hitters from which a custom rule can be created.
We can also look at the effectiveness of each rule set by comparing success relative to the total candidates tested. For example, we can see that the d3adhob0 rules had the fourth largest candidate size (825 billion), however it cracked only 39.54% of passwords. By comparison the InsidePro-PasswordsPro rule had only 45 billion candidates yet it cracked 47.48% of passwords. The latter rule is clearly more efficient!
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.
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.
Recently I was writing a blog on hashcat to cracking the hashes but the blog was going long so i thought about to write another blog to explain more about hashcat attacks,so that you can easily crack the has.So the rule-based attack is one of the most complicated of all the attack modes.The reason for this is very simple.the rule-based attack is like a programming language designed for password candidate generation. It has functions to modify,cut or extend words and has conditional operators to skip some, etc.That makes it the most flexible,accurate and efficient attack.
The rule-engine in hashcat was written so that all functions that share the same letter-name are 100% compatible to John the Ripper and Passwordpro rules and vice versa. Later we started to introduce some of our own functions that are not compatible. But these functions got their own letter-names to avoid conflicts.
The first thing which comes in our mind is, What are rules why we should use rule attack to cracking the hash.So First of all, consider the following scenario. You have a basic password wordlist containing the words below:
Now that we can see the benefits of rules,we will now define some rules to use in our own rule-based attack. To define our own custom set of rules to use with hashcat, we need to store them in a file,like best64.rule or something you as want.
Matched rules in cracking
So i got the output of hashes,hope this will help you to resolve queries of cracking the hash with hashcat.As previously mentioned, only the commonly used rule functions were covered in this tutorial. To view a full list of available rule functions, you can do so on the hashcat website here.Additionally recommend you to..
In this guide, we created and used our own custom rules in hashcat to perform a rule-based attack. We started by covering what rule-based attacks are and why they are used. We then proceeded to create our own rules and use the rockyou dictionary to crack MD5 hashes.
The science behind rule sets is very simple, however the correct application is very difficult. A rule set file consists of simple commands that temporarily change wordlist entries into a different ones. A rule can simply append number 1 to an entry (expressed with $1) or capitalise the first letter in an entry (expressed with c). There are a lot of rules that can be added to a particular rule set to maximise the potential of a successful password crack. The list of available rules can be read in this manual.
A custom made rule sets can be assembled to fit a particular password policy, however there are multiple sophisticated rule sets that come with hash cracking programs such as Hashcat or John the Ripper. To find these pre-made rule sets, go to root directory and type locate *.rule which should locate and print all files with the extension of .rule. The path in Kali Linux is /usr/share/hashcat/rules/.
Best64 rule set conducts multiple changes to words in wordlists. It tries to append number combinations to each word as well as rotate various chunks of each word. It also includes various other rules, you can check it out for yourself.
Note that rules are just modifications to words in your wordlist (capitalize first letter, leet-speak replacements, etc.). If the original word (or close to it) is not in your original wordlist, then you will not crack the hash.
Not ideal and I have no idea how long the password is.
Now the thing with this challenge was, I had no idea how long the password would be so I was trying all sorts of things with previous passwords from the CTF. Previous passwords were Afr1ca!, AfricanCTF2021 and ctf2021. So as you can see, there could be a pattern, so I tried a few mutations on those words but nothing came back. I hit a brickwall.
A hint came out and it was basically said to use rules with dictionaries or masking. The masking was pretty much explained as, passwords usually start with an uppercase, ends with a ! and most times end with the 2nd last and 3rd last characters are lowercase and it seemed like it was hinted that the password was 8 characters long. So with that in mind, you could do the following mask:
It may look weird but this is how prepend works in hashcat. The char ^ is the prepend function.
Say there is a word, dog, in the rockyou.txt file. You want to prepend the word cat to it. Your rule would look like ^t^a^c. So from left to right, hashcat will start with ^t and prepend it to dog making it tdog. The next one would be ^a and prepend that to tdog making it atdog. ^c prepends to atdog making it catdog. Done.
Append works the other way. You have the word dog and you want to append cat to it. Your rule would be ^c^a^t, thus ^c appends to dog making it dogc, ^a appends to dogc making it dogca and finally ^t appends to dogca making it dogcat. Simple.
So to use your rule file against a dictionary you would use the following:
I was baffled as to why I could not do words with the rules method so I took to our Hack South discord server and asked the question. With it being late Friday afternoon and a busy week behind me, someone mentioned why not just use the combinator attack. Wait what, how did I miss that, thanks Leon!
So essentially I could have just put those words in a file and run:
If your rules are simple, you can approximate your total keyspace by running your hashcat command against a baseline wordlist (say, 10,000 or 100,000 words), and then multiplying that keyspace by the total number of permutations expected to be generated by pp64 (using the number from its own --keyspace parameter. But that is going to be very back-of-the-napkin, because keyspace calculation isn't always linear and doesn't necessarily mean what you might expect.
That older togglecase example links to a newer article recommending rules be used, specifically the examples in rules/. For this example, let's use toggle5.rule, which the site explains "include[s] all possible toggle-case switches of the plaintext positions 1 to 15 of...5 characters at once".
Let's try cracking the md5 of the string HaShCaT and put that in our example.hash file (it's 41e24266141b6ef98bf0e1fb54b238a1) and use a dictionary of just the string hashcat for example.dict file. Go ahead and create these two files in whatever folder you're working in, with whatever editor you prefer.
You will see the hash printed followed by all candidates that would be tried if we were trying to crack a hash, which in this case is just the string hashcat. Note, no need for example.hash in the command when using --stdout.
df19127ead