Forgive me if this is a simple question or has been answered elsewhere here (I couldn't find it, if so). I'm still quite new to oclHashcat. I've searched the forums, Google, etc. and have been unable to find a straight answer anywhere.
What is the best approach for cracking an NTLM hash that corresponds to a simple 3-5 word sentence?
For example, let's say I have three NTLM hashes corresponding to the following passphrases:
This is a password!
Going 2 the store?
I like ur dress 2day.
I have a dictionary that contains all the individual words used in the passphrases above. I DO NOT have a wordlist with phrases, e.g., Wikipedia, Google n-grams, etc.
The length is too long for straight brute force, so what is the best approach?
I don't think I'm ready to start building my own rules to tackle this. Are there pre-built rules, e.g., best64.rule, that are best suited to these types of passphrases? Would rule chaining work best? A four or five way combinator might work, but the lists quickly become far too massive when talking about n-way combinations, so I'm sure that approach isn't practical (think of a combinator3 on realuniq.lst!).
Any advice is very much appreciated. Thank you in advance.
(11-17-2015, 12:39 AM)Betawave Wrote: [ -> ]I DO NOT have a wordlist with phrases
You've already identified the best approach.
Ok, but let's assume I don't have such a phrase list.
There are a few reasons for leaving aside that approach for the moment. One reason is that I have relatively few hashes which I know or expect use such phrasing (~1400) and I don't have the bandwidth or storage space to acquire large phrase lists that might not even be useful.
The more important reason is for my own learning (and hopefully other newbies reading the forum). In my test set of hashes, I was able to crack some phrases using the rules provided with cudaHashcat, but other hashes, which had similar pass phrases, have not been cracked (I control the accounts, so I know or am able to simply ask for the password). Since I'm new to this, I'm having a hell of a time figuring out why the same sets of rules work on one hash but fail on others when the passwords are similarly constructed.
For example:
Using just the provided rules, I was able to crack: Jump in the fire!
Using just the provided rules, I was NOT able to crack: Never not learning!
I can't explain the difference. The same rules were applied in the same order, using the same wordlist, which contains all of the words in both passwords. No rules were chained and the approach was always -a 0. Unfortunately, since I ran through all of the rules on all of the hashes quickly, I don't know which rule worked its magic. Re-running everything again and paying more close attention isn't really an option since I'm paying for GPU time. I honestly didn't expect to go down this rabbit hole... but now that I have, I want to learn as much as I can. I figure if an expert on here can narrow the approach or rules to use, I'll have a better chance of reading the rules and understanding exactly what's happening and anyone else reading the forum with the same issue might also learn something. Once I have a grasp on the fundamentals, I can then move to n-grams and other phrase lists.
Thanks again for the advice.
Quote:Using just the provided rules, I was able to crack: Jump in the fire!
Using just the provided rules, I was NOT able to crack: Never not learning!
I guess the "!" char was not part of the password, in that case the second one is > length 16 which is not supported for some of the algorithms. See here for details:
https://hashcat.net/wiki/doku.php?id=fre...ord_length
For testing, look at the help file for these switches:
--debug-mode=NUM Defines the debug mode (hybrid only by using rules), see references below
--debug-file=FILE Output file for debugging rules (see also --debug-mode)
* Debug mode output formats (for hybrid mode only, by using rules):
1 = save finding rule
2 = save original word
3 = save original word and finding rule
4 = save original word, finding rule and modified plain
(11-19-2015, 12:16 PM)atom Wrote: [ -> ]Quote:Using just the provided rules, I was able to crack: Jump in the fire!
Using just the provided rules, I was NOT able to crack: Never not learning!
I guess the "!" char was not part of the password, in that case the second one is > length 16 which is not supported for some of the algorithms. See here for details: https://hashcat.net/wiki/doku.php?id=fre...ord_length
Thanks for responding Atom. The "!" was indeed part of each password, as were the spaces. Further, some of the passwords that were in a similar vein used leet-speak style transcoding, e.g., 2 for to or too, 3 for E, 4 for A, etc., resulting in passphrases that were long (the longest cracked was length 22) and complex (upper, lower, digits and symbols). At this point, I can only figure that these long phrases were cracked using a generate or generate2 rule (at least if I'm understanding correctly how these rules work... I'm still very new!).
I'm aware of some of the length limitations and think I have a grasp on the reasons for the limitations. What keeps nagging at me is that there must be a way to use probability (maybe not strictly Markov, but a statistical approach) and human nature to get at some of the longer passphrases.
So much to learn! I really appreciate and any all advice. Thank you.
(11-21-2015, 10:40 PM)mastercracker Wrote: [ -> ]For testing, look at the help file for these switches:
--debug-mode=NUM Defines the debug mode (hybrid only by using rules), see references below
--debug-file=FILE Output file for debugging rules (see also --debug-mode)
* Debug mode output formats (for hybrid mode only, by using rules):
1 = save finding rule
2 = save original word
3 = save original word and finding rule
4 = save original word, finding rule and modified plain
Thank you mastercracker! This is SO helpful. I had overlooked these switches in the help file. Thank you so much. Being able to match finding rule against plain will massively increase the speed of my learning. Thanks again.