Assumption-based GPU Hash Cracking Theory

[Z3R0]

OG Author: m0rph
Date: July 25, 2014

NO WORDLISTS WERE USED IN THIS TUTORIAL
STRICTLY BRUTE FORCE MOTHAFUCKAAAAS

Good day ladies and gents! Today I'd like to propose an assumption-based method to cracking complex 8-10 character passwords often used by regular users. This method is applicable to typical user-passwords in current day systems. As the times change, we must also change!

A typical password today consists of these criteria:

• At least 1 special character
• 8 characters minimum
• At least 1 upper case character
• At least 1 lower case character
• At least 1 number

Damn...one would assume if these rules are followed, the chances of cracking a hash are minimal without some ridiculously complex ruleset or ultra-mega huge word list; however, I assure you, for the vast majority of the sheep in the flock, this isn't necessarily true.

Out of 10 people, how many would you say use the minimum 8 characters for their password? Without a doubt, over half. Out of 10 people, how many would you say use an exclamation point as their special character? Shit, an exclamation point is right there, easy to remember...probably over half. Out of 10 people, how many would you assume put a digit at the end of their password? With the history of the epic password "abc123" I think it's safe to say, over half.

So how can we leverage these assumptions in a program like hashcat for faster cracking? With a simple special charset and a mask! That's how!

Let's examine the exponent potential for such a password. If we assume we have an "!" in the first position of the password, we have 1¹. 1 possibility.

If we assume, we have an "!" and any digit (0-9) at the end of our password, what's our range of possibilities now?
1 + 10¹ = 11. And if we add another digit we have 1 + 10² = 101 possibilities.

Here's an example of the templates for our assumed password(s):

Code: [Select]

!xxxxxxN for 8 chars w/ 1 digit
!xxxxxxxN for 9 chars w/ 1 digit
!xxxxxxNN for 9 chars w/ 2 digits
!xxxxxxxxN for 10 chars w/ 1 digit
!xxxxxxxNN for 10 chars w/ 2 digits
!xxxxxxNNN for 10 chars w/ 3 digits
We are assuming people are lazy, have met the minimum extra-requirements for their password security and now have to come up with any random 6-8 character string + any combo of 1-3 digits.

Let's try to calculate the max number of possibilities UpperLowerAlpha with the most complex of these: 10 chars w/ 1 digit.

1¹ for our exclamation point (or any other specified special character..."!" being the most commonly used) since we are using both Upper and Lower case, per-digit becomes 56 combos:

(1)(56)(56)(56)(56)(56)(56)(56)(56)(10) = X number of Total Possible Passwords
Or
1 * 56⁸ * 10¹ = X
1 * 96717311574016 * 10 = 967173115740160

Although that's a big number, that can easily be cracked in a week with a low-end GeForce GTX460 @ 1008M c/s (or 1008000000 tries per second) for $130 (source: http://golubev.com/gpuest.htm) when used with a charset like this:

Code: [Select]

--custom-charset1=! --custom-charset2=?l?u <hash> ?1?2?2?2?d

The above tags in hashcat will append a 1 to the beginning of every guess, brute-force uppercase & lowercase letters as it guesses, and append one digit from 0-9 at the end of every guess. It will cause hashcat to attempt to crack 5 character hashes that look similar this until it finally cracks the hash:

Code: [Select]

!aBCD0
!qweR5
!JfXX3
!PaSs9 <-- cracked

Here are some benchmarks I've performed on some test hashes with my GPU @ ~1050M c/s.







More benchmarks to come in the future. I realize this isn't going to cover every 8-10 character password imaginable, but it should at least work on a very large number of modern hashes. Thoughts?

[Daemon]

Notice me senpai!

Lol but on the real, thats interesting. However if your assuming that the password starts that way and/or ends with a number, you are also setting yourself up to take twice as long to crack it if they are in the half that doesnt because first you go through and bruteforce every possible combination, then realize it didnt work, then have to bruteforce again but this time with those 3 positions unset.

I'm just being a pessimist though, in reality your idea should speed up cracking at least 50% of the time. Though it might be worth coming up with a few other rules to run in parallel on other machines. Such as passwords that end with !! instead of numbers. Or end with ?.

[Darkvision]

If you are doing your ruleset as a do this first then all remaining possibilities it makes a lot of since, i mean if we KNOW they impose some character restrictions(must use a number etc) then we know that the password cant be all alpha/caps/numeric/specials but has to be a mixture of. Also a number of studies have been done on where special/numbers appear in passwords(by ofc breaking tons of them) and they do tend to be at the front or back of a password. I would also suggest as a potential extra rule: first letter capitalized. Think about it since kindergarten we engrish speakers have been taught to capitalize the first letter of the word of a sentence. Meaning if the ruleset for the PW requires a capital letter it is most likely to appear as the first letter.