LM & NTLM Hashes

[cgsupport]

Hello, sorry, I can't see this has been implemented, and I'm missing it, or at has already been mentioned so please forgive me if it has!

We currently crack our hashes via a pwdump file through a custom written script; this script takes all LM hashes, cracks them (-1?u?d?s ?1?1?1?1?1?1?1), adds them together in a wordlist (left cracked half hash + right cracked half hash), and uses the "toggles-lm-ntlm.rule" to find out the NTLM password; this takes (at most) 18 minutes on just one of our GPUs, and then carries on cracking the leftover NTLM hashes.

Is there a way to do this in hashview? I've figured out how to add the maskmode task, but not a way to add the cracked LM hashes into a wordlist and then run the "toggles-lm-ntlm.rule" rules.

Is this currently possible?

Thanks.

[i128]

Unfortunately no. The challenge we ran into with LM has to do with the reassembly of left cracked and right cracked. Currently, Hashview stores the ciphertext and plaintext of each hash submitted (and a bool isCracked). So with pwdump's, Hashview has to split the hash in half, and then run each one independently (like what you are currently doing). However, we run into the problem with reassembly. Even if we went back and reassembled like you mentioned above (right half/left half), there could be instances where only one half is cracked, leaving the question, what do you do with the other half? How do we mark this, track it, etc. As a result this results in a partial cracked state and messes up a lot of the internal logic.

So for now LM is not supported. (There is some old code in there that allows for LM cracking, but that should be removed as to not confuse users)

[cgsupport]

That's a shame. A lot of our first time customers still have LM hashes in use; which at-least with the way we're currently working, all NTLM hashes using LM are cracked. Guaranteeing a crack up to 14 characters. We have had the odd half that errors (never understand why, we assume there must be a problem with the actual hash), but we're only checking for uppercase, numbers and specials - which is all that should be there anyway.

Not sure if its something you'll try and add in the future, there shouldn't be a need to add the LM hashes to the database, as they're only 7 characters, and they're useless without the NT counterpart, might just be worth just running a job called something like "pre-processing LM hashes" if "aad3b435b51404eeaad3b435b51404ee" doesn't exist, and this shows nothing to the user until it starts cracking the NT counterpart.