[FEATURE REQUEST] dumping history entries

[c0d3z3r0]

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

[C-Sto]

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]

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]

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]

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]

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]

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]

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

[c0d3z3r0]

Two problems on the latest commit:

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

[C-Sto]

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]

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]

Looks better now but the history hashes are still wrong

[C-Sto]

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 https://github.com/C-Sto/gosecretsdump/blob/c4fe3eba303d8f2529873b1bc4467bb526e0d260/pkg/ditreader/records.go#L125 and here https://github.com/C-Sto/gosecretsdump/blob/c4fe3eba303d8f2529873b1bc4467bb526e0d260/pkg/ditreader/records.go#L137

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]

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

[c0d3z3r0]

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

[C-Sto]

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]

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