1

I'm using mimikatz to retrieve a user's password hashes from Active Directory with the following command:
lsadump::dcsync /user:mimikatz
The user's password is Pa55w.rd.

The output is

...

Credentials:
  Hash NTLM: 377565f7d41787414481a2832c86696e
    ntlm- 0: 377565f7d41787414481a2832c86696e
    lm  - 0: 3bad9482ff88c8d842970f4174fbebd7

...

I was surprised to see a value for the LM hash (3bad...). I checked the effective group policy setting on the domain controller, and in fact, LM hashes should not be stored:

enter image description here

I believe the LM hash 3bad... is not the LM hash, as I believed, but a different kind of hash. But what is it?

Improve this question

1 Answer 1

Reset to default
1

Without additional info, it's hard to say for certain. Microsoft indicates that LM hashes will not be stored when the user changes passwords.

However, in a SANS article by Mike Pilkington, he applies the appropriate mitigation settings, yet still have instances where LM hashes can be found in memory.

[After dumping the SAM db] As expected, no LM hashes are available. The first 2 accounts are disabled by default and no password was ever set for them. For user account MIKE, only his NT hash is available. So far, so good!

[After dumping credentials in-memory] It turns out that Windows calculates and stores the LM hash in memory, assuming the password is less than 15 characters, regardless of what the host or domain settings are for LM hash storage and LM challenge-response!

A little deeper

After calculating the NT and LM hashes of the Pa55w.rd, the value for NT is 377565F7D41787414481A2832C86696E and LM is C321C0EE1F8388924A3B108F3FA6CB6D, neither of which match what you have above. So I'm wondering, perhaps you copied the wrong hash? Or, did you copy the password incorrectly?

On various pentests I've been on, I have noticed that legacy environments have a really tough time getting rid of LM hashes, even if they push out that GPO to not store LM hashes and disable LMv1/2 on the network. This could certainly be related to hashes still being calculated and stored in memory as the article indicated.

Improve this answer
1
  • The 377... NT hash does match what I have above. And doing a LM hash of Pa55w.rd is exactly the reason why I ask, what exactly is stored in the ntds.dit, because the value is completely different from the calculated LM hash value. What mimikatz shows me, is not a memory hash either, because I see an LM hash also for user accounts that are not signed in at all. But maybe that is a problem with mimikatz, and not with the actual password database. Oh, and I was testing this on a fresh Server 2019, so no old or legacy environment.
    – Daniel
    Feb 2 at 16:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .