0

I am currently working on a solution to at least try to implement a working/modern "change password" option to chntpw.

First of all: Windows uses this format in its hive file:

root@rescue /mnt/Windows/System32/config # samdump2 SYSTEM SAM

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* :503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

This consists of: USERNAME:USER-ID:LM-HASH:NTLM-HASH

At least that is what I am told it would be.

the LM hash is indeed correct: It corresponds to the hypothetical password .Testpassword123

However running online NTLM hash generatores does not yield in the hash that is stored in the SAM hive file:

31d6cfe0d16ae931b73c59d7e0c089c0

but instead the online hash generator:

236DD9FC77E26DFE29978024603800AE

The version of windows used in this case is Windows Server 2019. But I am not sure, if that does matter indeed. I guess, this is the reason, why changing the password does not work in chntpw (At least it never did for me).

What really is odd, that after deleting the password and setting it again, the hash is still 31d6cfe0d16ae931b73c59d7e0c089c0.

So I would think, that there is no "salt" involved regarding the system time. But something else is at play here.

Does anyone know, how to get the NTLM hash, that is actually dumped from samdump2 in this example? Without getting this to work, I guess there is no chance to actually implement this password change feature into chntpw ever.

There is a lot of conflicting and especially incomplete (unofficial) documentation in this regard.

So how would one build such a hash, that actually is valid for the input of the password as in this example.

Improve this question

1 Answer 1

Reset to default
1

I don't really know what generators you used to calculate the LM hash online, but it isn't correct, the values you got for both hashes are the default values (the ones you get when you hash an empty value).

The LM hash can be calculated using this algorithm, and the NT (also called NTLM) hash can be calculated using this one.

Both hashes are unsalted and are derived only from the password of a user.

Improve this answer
3
  • I checked with another password on tobtu.com/lmntlm.php and found out, that this generator did not change the LM hash when changing the .Testpassword123 to .Testpassword124. But the NTLM hash is changing. And this hash matches, what I can find from other online tools aswell. I tried with another tool: hash.darkbyte.ru > indeed, this one appears to generate an LM hash, that differs per password. Strange, the tool from the first link appears to be broken and I trusted it. I will try again. But the 2nd linked tool also gives the same NTLM hash as the first one. Sure its wrong?
    – HeartOfGermany
    Jan 12 at 7:38
  • Oh, I found the culprit: The first generator does not cut after character 14 - this is what LM is required to do and this hash function is not accepting or doing. I will try it again with the new findings.
    – HeartOfGermany
    Jan 12 at 7:45
  • You might want to dump the registry again or try doing it on another computer (preferably with a non-server version of Windows). Is the computer you god the registry dumps from a domain controller? If that's the case then the SAM won't contain much information at all, domain controllers keep the accounts in either NTDS.dit or in an mssql server (not really sure about the sql server option).
    – Zicar
    Jan 12 at 20:33

You must log in to answer this question.

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