search

avonar / impacket

Automatically exported from code.google.com/p/impacket
Other
0 stars 0 forks source link

dump password history hashes with secretsdump.py #34

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This patch will also dump password history hashes. Output will look like this:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:27272719c2d1d2bb8d74d039a81f0
e49:::
Administrator_history0:500:43a6ed35a36f74e27eab299ffc718400:27272719c2d1d2bb8d74
d039a81f0e49:::
Administrator_history1:500:99edd16fb222f96a1d65d9a46ae841e5:a881324bad161293dedc
71817988d944:::
Administrator_history2:500:20bfe873abe902924cb257ea8beb22da:97f94ef9c49c0b2043d4
de224e1427e9:::
Administrator_history3:500:d456e6c39078198bcc5f58d2377c48ff:a881324bad161293dedc
71817988d944:::
WIN-LEK1BKKKKD8$:1003:aad3b435b51404eeaad3b435b51404ee:02e5b61204e2e970ceb6410b0
6648c25:::
WIN-LEK1BKKKKD8$_history0:1003:4ea35f0be7da7db8940146b02a77e793:02e5b61204e2e970
ceb6410b06648c25:::
WIN-LEK1BKKKKD8$_history1:1003::a44cf5558e85cb1c3f24b5fa90fdda30:::

It was tested successfully with r942 + this patch against Windows 2008 R2 SP1 
domain controller.

Cheers

Original issue reported on code.google.com by lanjelot@gmail.com on 22 Nov 2013 at 6:27

Attachments:

GoogleCodeExporter commented 9 years ago 
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 bet...@gmail.com on 22 Nov 2013 at 1:40

GoogleCodeExporter commented 9 years ago 
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 lanjelot@gmail.com on 24 Nov 2013 at 10:55

GoogleCodeExporter commented 9 years ago 
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 bet...@gmail.com on 24 Nov 2013 at 10:59

GoogleCodeExporter commented 9 years ago 
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 lanjelot@gmail.com on 27 Nov 2013 at 2:51

GoogleCodeExporter commented 9 years ago 
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 bet...@gmail.com on 27 Nov 2013 at 8:20

GoogleCodeExporter commented 9 years ago 
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 lanjelot@gmail.com on 28 Nov 2013 at 10:12

Attachments:

GoogleCodeExporter commented 9 years ago 
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 bet...@gmail.com on 28 Nov 2013 at 5:15