LM (Lan Manager) Hash - Brute Force Failing

Question

I have a number of LM hashes that I have been attempting to crack with hashcat. My understanding was that LM splits passwords into two separate 7 character strings before they are hashed. I also believe that they only use uppercase letters, as well as digits and special characters.

I have attempted to run the following command in hashcat: hashcat64.exe -m 3000 -a 3 lm-out.txt -1 ?u?d?s --increment ?1?1?1?1?1?1?1

This should brute force every possible combination with the acceptable characters for LM from 1-7 characters long - however, after running this to completion, it has only recovered 0.20% of all passwords?

I was wondering if anyone could shed any light on this for me? I know that hashcat's special characters mask does not include the pound sign, but I can't understand why over 99% of the passwords would not be brute forced in this way? The fact that some were recovered as simple words leads me to believe that they can't be being altered in some way before being hashed.

(Also, I work in cyber security, so this is not a "Black Hat" request in any way!)

I tried the sample hashes from hashcat.net/wiki/doku.php?id=example_hashes , to rule out a problem with hashes getting corrupted, as Rory suggested, but it has managed to extract about 20 passwords from the hashes, which is what leads me to believe the hashes can't have been corrupted or that there isn't an additional layer of security somehow, as surely this would affect every hash, not just most of them?

All of the hashes were extracted at once from the NTDS.dit file by the same script, so they should either all be okay, or all be corrupt? Unless I've misunderstood that suggestion?

Relating to Royce's answer (Thanks for the comprehensive response):

• When I say pound - I am actually English so I mean literally the "£" symbol rather than "#". When I checked the special characters charset on the hashcat wiki the "£" symbol did not appear in that list? As it is an English hash dump as well, I wondered if that might be part of the problem? Apologies for the confusion!

• Regarding the hashes that have been cracked - they are all either 7 for the first part and blank for the second, or 7 for the first part and 1-6 for the second. They are alpha numeric with ! as the only special character. They are actual words, or words that have been mangled with numbers instead of letters.

• I do not have access to the target system any more, but surely the fact that some of the hashes have been cracked would mean that the problem can't be in the approach? In the sense that the ones that worked were extracted in the same way?

• I'm not sure I would know how to discover the system's default code page/character set, and as I do not have access to the system any more, I don't know I can answer that one. Would there be any difference between UK English and US English that might be causing problems if Hashcat is assuming US?

• If ALT characters were used that forced the passwords to be stored as NTLM, would this not replace all the LM hashes for those passwords with one standard "Blank" hash? That is something that has been confusing me, as all of the uncracked hashes are different, meaning I have assumed they are hashes of differing values. I had also thought it unlikely that over 99% of the users would have been using crazy, non-standard characters in their passwords! (Especially given the passwords that have been cracked!)

• To extract the hashes I made a volume shadow copy and grabbed NTDS.dit and SYSTEM. I then used esedbexport to extract the tables and ntdsxtract (specifically dsusers.py) to extract the hashes. I think this is a fairly standard route, but I can post links to the tools, or more exact information on my process there if you wanted it clarified.

Again though, I think the thing that keeps throwing me is that some of the hashes are cracking, so if there was an error in this process, or even with the system charset, would it not have made every single hash gibberish?

Thanks again for your help Royce, much appreciated.

(Also, advising against LM backwards compatibility is definitely something we have already done!)

Answer 1

First, some answers to your meta-questions:

• hashcat does indeed understand the 7-character split and optimizes accordingly.

• hashcat also knows that LM is case-insensitive, so you can drop the custom character set without changing the speed of the attack.

• I'm not sure where you got the idea that hashcat's ?s character set does not include '#'. it definitely does:

  $ hashcat --help | egrep ' s .*#'
    s |  !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
  

I would expect this approach to get all valid 7-bit ASCII hashes:

$ hashcat -m 3000 -a 3 -i lm.hashlist ?a?a?a?a?a?a?a

Next, some ideas for an answer:

• Does the list of hashes that have actually been cracked have anything in common - character set, length, pattern, etc.? This may give you a clue on what is missing.

• Do you have the ability to set a known password on the target system? If so, you can validate your approach directly against a known plaintext.

• What is the target system's default code page / character set? If it's not English / Windows-1252, then things get complex - the system converts the string to the OEM code page during conversion to a hash.

• If ALT characters are used in the password, some of them will work with LM passwords, and others will not. The following ALT characters are not LM-compatible, and using them will force the password to be stored only as NTLM, even if LM is the system default:

0128-0159 0306-0307 0312 0319-0320 0329-0331 0383 0385-0406 0408-0409 0411-0414 0418-0424 0426 0428-0429 0433-0437 0439-0447 0449-0450 0452-0460 0477 0480-0483 0494-0495 0497-0608 0610-0631 0633-0696 0699 0701-0707 0709 0711 0716 0718-0729 0731 0733-0767 0773-0775 0777 0779-0781 0783-0806 0808-0816 0819-0893 0895-0912 0914 0918-0919 0921-0927 0929-0930 0933 0935-0936 0938-0944 0947 0950-0955 0957-0959 0961-0962 0965 0967-1024

For example, this is the LM hash of "cañon", as cracked by hashcat (disclaimer: I used a Windows VM to use the ALT-key entry method to generate the string, and then used John the Ripper's pass_gen.pl to hash it):

272a43bc1fe85832:$HEX[4341a54f4e]

Note that if you try to replicate this on a utf-8-ready system, you'll get this result instead, which is not how Windows handles the data input:

de3fa2be44e8af61:CAñON (which is 41 43 b1c3 4e 4f)

I would expect this approach to pick up some of them:

$ hashcat -m 3000 -a 3 -i lm.hashlist ?b?b?b?b?b?b?b

But use of ALT characters is relatively rare. If you're auditing a real-world enterprise list of password hashes, I'd look into the validity of the hash extraction script next. If you post more about that I can try to assist more.

(Also, LM backwards compatibility should be unnecessary in the modern enterprise, and as an auditor you should advise disabling it.)