dump password history hashes with secretsdump.py about impacket

[GoogleCodeExporter]

Hey man...

Thanks so much for contributing this patch!.. Actually that's something I had 
pending to do.. so thanks again.. the code looks great ( thanks for adapting it 
to the structures used ) and I would love to incorporate it ( I would make it 
optional tho, since there are some ADs that store a lot of password histories).

There's something, however, that look strange:

1) If you take a look at the nthash for the first history, it always matches 
the current one.. I'm still not sure why
2) if you look at the lmhash, most of them are not blank 
(aad3b435b51404eeaad3b435b51404ee), which doesn't make much sense, since 
Windows 2008 R2 won't store the lmhashes I think.. So there's gotta be 
something wrong there (could be my mappings of lmPwdHistory maybe).. Did you 
notice that?

cheers!
beto

Original comment by [email protected] on 22 Nov 2013 at 1:40

[GoogleCodeExporter]

Nothing wrong on our end i believe, since I get the same results when using 
libesedb+NTDSXtract or quarkspwdump.

1) The first hash in the password history is always the current password.
2) I'm guessing Windows must be doing something behind the scenes, like maybe 
generating random hex values since I can't even crack those, they might not 
even be real DES encrypted data. Would need to do a bit of Windows reversing to 
find out what's really going on...

Original comment by [email protected] on 24 Nov 2013 at 10:55

[GoogleCodeExporter]

Hey man..

1) I didn't know that! thanks!

2) Hmm.. interesting.. we should delve deeper then.. 'cause looks like right 
now they are not even crackable..  maybe just printing the lmhash? (assuming 
those are the right history nthashes)

thanks for researching this mate.

bto

Original comment by [email protected] on 24 Nov 2013 at 10:59

[GoogleCodeExporter]

2) Yeah or more likely Windows just doesn't initialize the data. Also, a LM 
history hash changes everytime it is pushed back by a new password.
Like say you have:
Administrator_history1:500:bb93e73077e57692e426438283784264:a881324bad161293dedc
71817988d944:::
Then you change your password, you'll have a different LM hash:
Administrator_history2:500:e3ceb65b0a35f41ad9330eb9fcb4fdaf:a881324bad161293dedc
71817988d944:::

Original comment by [email protected] on 27 Nov 2013 at 2:51

[GoogleCodeExporter]

2) Could it be the target Windows doesn't store LM hashes? (check 
http://support.microsoft.com/kb/299656).. It'd be interesting to see what 
happens if you enable storing LM hashes.... I'm wondering if there's a way to 
detect that when reading ntdis (it must be there.. )

Original comment by [email protected] on 27 Nov 2013 at 8:20

[GoogleCodeExporter]

Remember mate, I am testing against Windows 2008 so no, the target doesn't 
store LM hashes.

If I enable storing LM hashes on my Windows 2008 domain controller, then I do 
see actual LM hashes pushed in the password history, and I can crack them fine 
indeed.

To detect whether LM hashes are actually stored, you simply need to read 
hklm\system\ccs\control\lsa\nolmhash.

Now by default though, storing LM hashes is disabled as you know. And when you 
set a new password for a user, every LM history hashes for that user are 
changed in the password history. This makes total sense now that I think about 
it because that way Windows resets every previous LM hash that could still be 
recovered.

Anyway, the attached patch is what I'm currently happy with. I added the 
-history option, I don't print the first hash in the password history since it 
is always the current password, and I read the NoLmHash from the registry to 
dump LM hashes or not.

Enjoy

Original comment by [email protected] on 28 Nov 2013 at 10:12

Attachments:

• secretsdump.py.pwhistory-patch

[GoogleCodeExporter]

Yep.. I remember... but that was a subtle request to force it to store the 
hashes and check how they behave.. :) :)

Excellent news!.. thanks so much for researching on this. 

I just applied the patch, made a few minor changes (basically taking off from 
getBootKey() the check of NoLmHash, made its own method (checkNoLMHashPolicy), 
and made it available also if the target is not LOCAL but a real target machine.

Let me know if it works for you.. and thanks again!
beto

Original comment by [email protected] on 28 Nov 2013 at 5:15

• Changed state: Fixed