Bruteforce not finding simple 4 letter hash?

[led5150]

Hi,

I must be doing something wrong, because I can't seem to have hashcat crack a simple 4 letter hash using brute-force.  Here is what I'm trying.

The hash is:

NOTE: Edited below per the 'rules' section! Sorry for posting the hash.. didn't know that wasn't allowed. Have masked now.

Code:

cindybear:1001:aad3b435b51404eeaad3b435b51404ee:B28XX81XXX43XX086XX2XXX7XXXDXXX65:::

The password for this hash should be "what".  Four lowercase letters w, h, a, t

The command I'm running is:

Code:

hashcat -m 1000 -a 3 -i --increment-min=4  easyntlm.txt ?l?l?l?l -O

But hashcat does not find it!  What am I doing wrong?  Is there a flag I'm missing?

Please help!  I've been running a 10 char brute force for a while now using a similar method and I'm afraid that I've lost a lot of time because the command I ran is wrong.

Thanks!

[led5150]

OMG! is it the -O flag??? I just ran it without and it found it. Oh no... oh dear no! So much wasted time... : ( : ( : (

like days of time.... Okay okay... So what does that -O flag actually do? Does it not actually run all of the permutations? Does it "optimize" by using some built in masks or something?

Does this affect all -a types? For example running with -a 0 and -O, will this skip some words in a wordlist for the sake of speed?

[undeath]

-O is using a different kernel that has some optimizations and should run faster but only works for passwords up to a certain length (depending on the specific hashing function). This length is usually around 15 bytes.

If you can't crack a hash with -O that has such a short length there is probably some bug with either the kernel or the opencl runtime you are using.

Can you share the hash that is causing this problem and the full output of the unsuccessful hashcat run?

[led5150]

Sure!  The hash is NTLM unsalted.  it is:

Code:

cindybear:1001:aad3b435b51404eeaad3b435b51404ee:B2898109643D7086DF2D0D780CD78865:::

The password now is the four letter word "what".

Here is the full output:

Code:

$ hashcat -m 1000 -a 3 -i --increment-min=4  easyntlm.txt ?l?l?l?l -O
hashcat (v6.0.0-4-g5628317d) starting...

OpenCL API (OpenCL 1.2 (Jun 15 2018 20:52:09)) - Platform #1 [Apple]
====================================================================
* Device #1: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz, skipped
* Device #2: Iris Pro, 1472/1536 MB (384 MB allocatable), 40MCU
* Device #3: AMD Radeon R9 M370X Compute Engine, skipped

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 27

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Optimized-Kernel
* Zero-Byte
* Precompute-Init
* Meet-In-The-Middle
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.

Host memory required for this attack: 409 MB

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted. 

Session..........: hashcat                     
Status...........: Exhausted
Hash.Name........: NTLM
Hash.Target......: b2898109643d7086df2d0d780cd78865
Time.Started.....: Wed Jun 24 11:59:14 2020 (0 secs)
Time.Estimated...: Wed Jun 24 11:59:14 2020 (0 secs)
Guess.Mask.......: ?l?l?l?l [4]
Guess.Queue......: 1/1 (100.00%)
Speed.#2.........:  140.4 MH/s (0.87ms) @ Accel:8 Loops:26 Thr:512 Vec:1
Recovered........: 0/1 (0.00%) Digests
Progress.........: 456976/456976 (100.00%)
Rejected.........: 0/456976 (0.00%)
Restore.Point....: 17576/17576 (100.00%)
Restore.Sub.#2...: Salt:0 Amplifier:0-26 Iteration:0-26
Candidates.#2....: snaa -> xqzz

Started: Wed Jun 24 11:59:12 2020
Stopped: Wed Jun 24 11:59:15 2020

[philsmd]

does it work with -D 1 added to the command line:

Code:

hashcat -m 1000 -a 3 -O -D 1 easyntlm.txt ?l?l?l?l

To me this really seems like a (very dangerous) driver bug. since the self-test seems to be successfull, but on your system it seems to be not cracking your target hash (so only successful on some occassions, which makes the problem even worse and more difficult to understand). btw the hash cracks perfectly fine on every system I just tested.
macOS Apple driver bugs again !?

[led5150]

Hey,

Yes that command did find the hash!  What is that -D flag?

Also when you say my original command is 'very dangerous' do you mean to my system?  Because I am currently running a very similar command for 24 hours now, just without the -O flag.

Please advise!  Is the above command safe to run?  (I noticed it was a very fast crack rate)

Thanks!

Matt

[philsmd]

the -D 1 parameter does whitelist your CPU device (the Intel i7) cpu (see --help for all the command line parameters that hashcat supports and what they mean).
that means that with -D 1 you are testing with your CPU, instead of your GPU

When I say dangerous, I mean that it could be a real resource waste for the hashcat users. This problem of false negatives (not cracking hashes while they should crack) we consider quite a serious/dangerous problem... but as you can see if one device (your CPU) works, while the other does not, it really is a driver issue with your GPU

[led5150]

Ah I see.

I just tried using -D 2 and same thing.  So yeah that GPU is basically useless since you can only update those drivers by updating the OS...  thanks Apple.

Funny enough, it does find it without the -O flag.  Would it be safe/reliable to use without it?  Or would you say the speed loss is not a good tradeoff?

Thanks a lot for helping with this.  It's been a journey figuring all this out!

[undeath]

Funny enough, it does find it without the -O flag.  Would it be safe/reliable to use without it?

Unfortunately that's not safe to say. Fact is, there is some hitherto unknown problem with the opencl runtime installed on your system. It is possible that this problem only occurs with the optimized kernel (as you experienced) or that the problem may also occur with the standard kernel just under slightly different circumstances. This also applies to all other hash modes.

The only reliable solution would be for the hashcat developers to figure out what's going on and adding a workaround for that.