Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] dumping history entries #8

Open
c0d3z3r0 opened this issue Apr 9, 2020 · 16 comments
Open

[FEATURE REQUEST] dumping history entries #8

c0d3z3r0 opened this issue Apr 9, 2020 · 16 comments

Comments

@c0d3z3r0
Copy link

c0d3z3r0 commented Apr 9, 2020

secretsdump.py provies -history for that. Would be awesome to have that in gosecretsdump :-)

@C-Sto
Copy link
Owner

C-Sto commented Apr 14, 2020

Sure - I initially left it out because I didn't have a lot of use for it and it would slow things down, but if I remember correctly it wouldn't be too hard to add, I'll try to get around to it at some point in the near future :)

@c0d3z3r0
Copy link
Author

Awesome :-) I had a short look at the code secretsdump.py is using, it's pretty simple (just one additional flag to check IIRC)

@C-Sto
Copy link
Owner

C-Sto commented Apr 15, 2020

FYI, it's in on this branch https://github.com/C-Sto/gosecretsdump/tree/history - I'll merge in once I've tidied it up a bit, and made sure it doesn't slow things down too much

@c0d3z3r0
Copy link
Author

doesn't seem to work unfortunately. the output stays the same, no history. at least I measured no slowdown at all with that massive ntds from #2

@c0d3z3r0
Copy link
Author

oh. my fault. guess I will never get used to go's strange behaviours...
Tested with a ntds from Win 2016, which leads to "panic: Not yet implemented"

@C-Sto
Copy link
Owner

C-Sto commented Apr 15, 2020

That's expected - the format for 2016 is slightly different, and I haven't got to it yet. I'd expect to see something like:

camtest123:1121:aad3b435b51404eeaad3b435b51404ee:6be408f1e80386822f4b2052f1f84b4e:::
camtest123:CLEARTEXT:
camtest123:aes256-cts-hmac-sha1-96:63da4f472aefb90380b9ae6c0251e1c9250289db82adc7f2c277a99eb300f066
camtest123:aes128-cts-hmac-sha1-96:aed282fa47e8bc84b6e3d54d3427d57a
camtest123:des-cbc-md5:2092feaeae97c8f4
camtest123_history0:1121:aad3b435b51404eeaad3b435b51404ee:04a01e4577bac0d76aea3a766fa18c3b:::
camtest123_history1:1121:aad3b435b51404eeaad3b435b51404ee:6be408f1e80386822f4b2052f1f84b4e:::
camtest123_history2:1121:aad3b435b51404eeaad3b435b51404ee:c9ab9d08cc7da5a55d8a82d869e01ea8:::
camtest123_history3:1121:aad3b435b51404eeaad3b435b51404ee:6be408f1e80386822f4b2052f1f84b4e:::
camtest123_history4:1121:aad3b435b51404eeaad3b435b51404ee:766b62d3db023f90443469d86393ca66:::
camtest123_history5:1121:aad3b435b51404eeaad3b435b51404ee:5e5c04a4181fcffa0bf8c1034c5e30a6:::
camtest123_history6:1121:aad3b435b51404eeaad3b435b51404ee:766b62d3db023f90443469d86393ca66:::
camtest123_history7:1121:aad3b435b51404eeaad3b435b51404ee:ae974876d974abd805a989ebead86846:::
camtest123_history8:1121:aad3b435b51404eeaad3b435b51404ee:c9ab9d08cc7da5a55d8a82d869e01ea8:::
camtest123_history9:1121:aad3b435b51404eeaad3b435b51404ee:c9ab9d08cc7da5a55d8a82d869e01ea8:::

@C-Sto
Copy link
Owner

C-Sto commented Apr 15, 2020

on the off chance that it works, would you be able to try the latest commit (408e629)? I don't have a 2016 .dit handy, but it might work.. You will need to use the -history flag also

@c0d3z3r0
Copy link
Author

Two problems on the latest commit:

  • the decrypted hash is wrong
  • only the first history entry is getting printed

@C-Sto
Copy link
Owner

C-Sto commented Apr 15, 2020

so close, yet so far 😄

I'll spin up a 2016 DC over the next few days with a bit of luck, and update the issue once I can test it properly

@C-Sto
Copy link
Owner

C-Sto commented Apr 16, 2020

Alright, I got ahold of a 2016.dit and the bugs were very obvious - it should be good to go now, but I'd appreciate a confirm before I merge (#9)

@c0d3z3r0
Copy link
Author

Looks better now but the history hashes are still wrong

@C-Sto
Copy link
Owner

C-Sto commented May 2, 2020

so after some digging, unsurprisingly I was getting bitten by trying to replicate impackets logic. The values should be right, but there will be 2 entries that are garbage (the first and last). Impacket drops the first value, but not the last - I think the last is likely to be an initialisation value, since between here

tmphst, err = decryptAES(d.pek[pekIndex[4]], encryptedNTW.EncryptedHash[:], encryptedNTW.KeyMaterial[:])
and here
hst2, err := removeDES(hst1, dh.Rid)

Digging into it has also revealed that there are LM hashes generated for each history entry even if LM is disabled; but when LM is disabled they appear to also be garbage. I'm going to make the output of this tool inline with impacket so that there isn't any confusion, but it seems that password history records are even more strangerer than I anticipated...

@C-Sto C-Sto mentioned this issue May 2, 2020
@C-Sto
Copy link
Owner

C-Sto commented May 2, 2020

^ that should resolve, I'd be interested to know if you're still getting invalid output before I close the issue though

@c0d3z3r0
Copy link
Author

c0d3z3r0 commented May 4, 2020

outfile does not work anymore (no file gets written) and the history nt hashes are still wrong

@C-Sto
Copy link
Owner

C-Sto commented May 5, 2020

well that's embarrassing - resolved the race in output in 0.2.1, but I'm not sure about wrong nt hashes. Is there any crossover (eg, are some of them right)? What version exactly is the .dit from?

@c0d3z3r0
Copy link
Author

c0d3z3r0 commented May 5, 2020

Ohh! Thanks for broad hint... Server 2012 hashes are just fine, both current and history. The problem is still with Server 2016 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants