-
Notifications
You must be signed in to change notification settings - Fork 48
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
Comments
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 :) |
Awesome :-) I had a short look at the code secretsdump.py is using, it's pretty simple (just one additional flag to check IIRC) |
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 |
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 |
oh. my fault. guess I will never get used to go's strange behaviours... |
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:
|
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 |
Two problems on the latest commit:
|
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 |
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) |
Looks better now but the history hashes are still wrong |
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 gosecretsdump/pkg/ditreader/records.go Line 125 in c4fe3eb
gosecretsdump/pkg/ditreader/records.go Line 137 in c4fe3eb
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... |
^ that should resolve, I'd be interested to know if you're still getting invalid output before I close the issue though |
outfile does not work anymore (no file gets written) and the history nt hashes are still wrong |
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? |
Ohh! Thanks for broad hint... Server 2012 hashes are just fine, both current and history. The problem is still with Server 2016 :-) |
secretsdump.py provies
-history
for that. Would be awesome to have that in gosecretsdump :-)The text was updated successfully, but these errors were encountered: