hashcat Forum

So I just put together a Tyan machine with 8 980s, and I've been running a big domain we had captured in a previous engagement as a test.

With the 8 cards we can brute force 7-character NTLM pretty quickly, so before I ran any wordlists and rules, I cranked out the following:

cudaHashcat64.bin -a 3 -m 1000 -i /path/to/hash-file.txt ?a?a?a?a?a?a?a

That spit out a whole bunch of plain 1 to 7 characters, easy enough.

When I moved on to using wordlists though, I noticed a large number of 7 character passwords getting spit out as well. I know its removing the previously cracked hashes - I get the message at the beginning of the crack that x number of hashes were found in the cudaHashcat.pot file (am I wrong in thinking that it removes those?).

I went back and tried the following just in case:

cudaHashcat64.bin -a 3 -m 1000 -i --markov-disable -1 ?u?l?d?s /path/to/hash-file.txt ?1?1?1?1?1?1?1

That spit out even more plains. I went back and used another wordlists based attack with a different rules file, and again, more 7 character plains were returned.

Now, I'll admit that this domain we're running is a bit screwy, so I suppose there could be spaces or something at the end of what I think are 7 character passwords - I haven't looked at that quite yet. But it seems right now like something odd is going on - every time I run a 7 character brute, it says that it finds x number of hashes in the pot file, and then proceeds to crack more 7 character passwords.

Any ideas? Am I missing something in the command? I don't think I am because the recovered number keeps increasing every time I run the brute force, so I'm pretty sure its correctly removing the previous cracked hashes from each run.

As reference, the domain I'm going after has 389,093 unique NTLM hashes. I have driver 346.47, and cudaHashcat-1.35.

Please file a bug report on Trac, providing easily-verifiable test cases for us to reproduce.

He did not use the --remove switch so yeah, they always gonna be there...

@mastercracker: no, hashcat supports potfiles now, and he specifically stated that "it finds x number of hashes in the pot file", referring to the "INFO: removed X hashes found in pot file" line, so he wasn't running with --potfile-disable.

MD5 is broken in cudaHashcat 1.35, so it's not outside the realm of possibility that MD4 is similarly broken. I totally intended to kick off a test suite run against 1.36b25 on GTX 980 before I left the office tonight, but completely spaced it.

(04-18-2015, 09:41 AM)epixoip Wrote: [ -> ]@mastercracker: no, hashcat supports potfiles now, and he specifically stated that "it finds x number of hashes in the pot file", referring to the "INFO: removed X hashes found in pot file" line, so he wasn't running with --potfile-disable.

MD5 is broken in cudaHashcat 1.35, so it's not outside the realm of possibility that MD4 is similarly broken. I totally intended to kick off a test suite run against 1.36b25 on GTX 980 before I left the office tonight, but completely spaced it.

You are right, I missed that part.

Thanks for the advice guys. I'll kick off a bug report on Trac with my exact command history and the results I was seeing.

I went back and reran a 7 character brute with the exact same command I had run previously (where I used the markov-disable flag) and didn't get any new hashes, but I later cracked additional 7 character hashes when using rulegen and maskgen.

Odd stuff. Would it help if I went and tried the same attempts using version 1.33?

Ticket #615 was submitted. I tried a test using a set of 396 randomly generated 7 character passwords that were then hashed into NTLM. When I ran them using:

./cudaHashcat64.bin -a 3 -m 1000 /path/to/sample_ntlm ?a?a?a?a?a?a?a

I recovered only 22 of the 396 hashes.

So I guess this issue is already being taken care of in 1.36. philsmd confirmed in my Trac ticket that this fix has been implemented in 1.36. So yay!

Any word on a release date for 1.36? I have a slew of NTLMs waiting to be cracked.

hopefully soon