Hashes getting skipped

[lessdangerous]

I'm a new registered user, but I've been learning a lot from the forums over the last couple of years, so let me start off by saying thank you to everyone who works on this project. 

I have a system with two AMD Pro Duos that I use for demo purposes at my school, and I'm running the attack against a large file of NTLM hashes.  I've recently found that some hashes are not getting identified by hashcat during bruteforce runs, but are later showing up as a result of combinator or appending/prepending attacks.  

Steps taken: 

1) quick bruteforce with NTLM up to 12 characters and confirmed they dump to the potfile
2) append/prepend attack
3) combinator attack

I'm seeing passwords that are less than 12 chars and composed of u/l/d show up in steps 2 & 3 that should've easily been caught by the bruteforce attack.

What am I missing?

[philsmd]

Maybe it depends on the mask you use in step #1 ?

It's difficult to say without a more detailed example for each step.

As you might have already noticed, hashcat prefers a mask attack (see https://hashcat.net/wiki/mask_attack ) over a "full-bruteforce" attack. But the settings for this mask attack (aka the mask itself) is very crucial to understand what should be cracked and what not.

Maybe you can provide for each step the full command and also the password (we do not yet need the hash, because it should be easy to generate the hash and it's actually prohibited to post hashes here without the admin requesting it).

It would also be interesting to know if this only happens with multi-hashes or with a single hash too.
Thanks

also note: one particularity of NTML is that it uses UTF-16 (little endian) so the password length is actually doubled (see https://hashcat.net/faq#what_is_the_maxi...ord_length for maximum password length)

[lessdangerous]

Maybe it depends on the mask you use in step #1 ?

It's difficult to say without a more detailed example for each step.

As you might have already noticed, hashcat prefers a mask attack (see https://hashcat.net/wiki/mask_attack ) over a "full-bruteforce" attack. But the settings for this mask attack (aka the mask itself) is very crucial to understand what should be cracked and what not.

Maybe you can provide for each step the full command and also the password (we do not yet need the  hash, because it should be easy to generate a similar hash - different salt - and it's actually prohibited to post hashes here without the admin requesting it).

It would also be interesting to know if this only happens with multi-hashes or with a single hash too.
Thanks

I keep it simple with the commands I'm running, since it's just for demo purposes for students to grasp password security and hashing in general.  I know the mask attacks are ideal, and I do use those to demonstrate the decreased workload too.  The exact commands:

hashcat64.exe -m 1000 -a 3 test.txt
hashcat64.exe -m 1000 -a 6 test.txt wordlistfile ?d?d?d?d?d
hashcat64.exe -m 1000 -a 7 test.txt ?d?d?d?d?d wordlistfile

The password that just turned up running the "a 6" attack is "6Tommy" which should've been caught by the bruteforce, correct?

Thanks for the quick reply!

[philsmd]

This:

Code:

hashcat64.exe -m 1000 -a 3 test.txt

means that hashcat should use the default mask: https://hashcat.net/wiki/hashcat#default_values

which is not a "full-bruteforce" (but currently is set to --custom-charset1 ?l?d?u --custom-charset2 ?l?d --custom-charset3 '?l?d*!$@_' ?1?2?2?2?2?2?2?3?3?3?3?d?d?d?d)

so this could definitely be the reason why "not all" hashes are cracked

You need to add a mask to your argument list such that hashcat doesn't use the default mask:

Code:

hashcat64.exe -m 1000 -a 3 --increment --increment-min 1 test.txt ?a?a?a?a?a?a?a?a?a?a?a?a

note: ?a also doesn't brute-force all chars (?b instead would use the full range 0x00-0xff)

[lessdangerous]

You need to add a mask to your argument list such that hashcat doesn't use the default mask:

Code:

hashcat64.exe -m 1000 -a 3 --increment --increment-min 1 test.txt ?a?a?a?a?a?a?a?a?a?a?a?a

note: ?a also doesn't brute-force all chars (?b instead would use the full range 0x00-0xff)

OK that helps a bit. I'm unclear on why the 6Tommy password doesn't come up even with the default charset, but that's my own lack of knowledge of hashcat and I need to do more reading on it. 

You also helped clarify the --increment option, which I thought was redundant based on my (inaccurate) assumption of how the -a 3 attack works. 

Many thanks!!!

[philsmd]

All of this information is documented in the wiki, I even linked it.

I will try to explain it anyway:

1. --custom-charset2 ?l?d means "define a custom charset with all lower letters and digits" (and which can be used within the mask with ?2 ). The default mask ist ?1?2.... The password "6Tommy" has an uppercase letter at position 2, so the custom charset 2 (?2) does not overlap with this (it doesn't include uppercase letters)
2. Whenever you specify a mask, hashcat only uses the exact length of the mask as minimum and maximum password length. You need to specify --increment --inrement-min x and --increment-max y if you want different lower and upper bounds for the password length

[lessdangerous]

1. --custom-charset2 ?l?d means "define a custom charset with all lower letters and digits" (and which can be used within the mask with ?2 ). The default mask ist ?1?2.... The password "6Tommy" has an uppercase letter at position 2, so the custom charset 2 (?2) does not overlap with this (it doesn't include uppercase letters)

That's what I was missing. 

I read through the wiki, but I haven't used the custom character sets as variables yet, so I was thrown off by the ?1, ?2, ?3.  I know I've read multiple times that a brute force attack isn't actually recommended because of the amount of time required, but it wasn't as clear to me that there was still a default mask in use even with a -3.  My assumption based on the name, my fault. 

I really appreciate your clarification, it will help me explain it to anyone else who asks.