Does "--just-clean" work?

[jsdhasfedssad]

Hi,

The other day I tested GPOddity in my lab. Today I added a secondary DC to a domain in my lab and as part of that I executed the command dcdiag in order to check for problems. As it happens I got an error related to GPO updates, "Windows attempted to read the file \\10.0.0.220\share\gpt.ini from a domain controller and was not successful". "\\10.0.0.220\share" is what I used in my earlier testing of your tool and at that time it pointed to my Kali VM. It seems gPCFileSysPath has not been restored successfully.

Sure enough, attempting to execute gpupdate on a different DC fails with the same error. This seem to effectively break GPO updating which in a live environment would be bad.

In order to fix this I attempted to use the parameter --just-clean but I get an error using that.

Testing another way of using the --just-clean parameter I also get an error.

Am I executing the cleanup command incorrectly? If no, what is the correct command? Is there a bug in GPOddity? Also, are you certain that the automatic cleanup in GPOddity always works in cases where it is not interrupted? The account I authenticate with in the first attempt is a DA so there cannot be a permission problem. I also tested to add the parameter --no-smb-server due to the code on the erroring line but that did not help.

Update 1 I fixed it. It turned out I had a GPO on domain level that had the gPCFileSysPath attribute still set to "\\10.0.0.220\share". The leason I learned is that without access to earlier executed commands, restoring the changed attributes may not be possible. Is this the design?

[jsdhasfedssad]

Suggestion On every attack, the file "cleaning/to_clean.txt" is overwritten. This means that the values from previous attacks are lost forever. Configuration for earlier abused GPOs can no longer be restored. I suggest that you store the values for every attack grouping them by GPO ID. This would make it possible to restore the settings for all previously abused GPOs.

It would also be good if the use of --just-clean does not hinge on having access to earlier attack commands. Given that the previous suggestion is put in place the clean command could be made generic, "python3 gpoddity.py --gpo-id [GPO ID] --domain [domain] --username [username/sAMAccountName] --password/--hash [password/NTLM hash] --just-clean".

[q-roland]

Hi,

Thanks for opening this issue and for your suggestions. The cleaning functionality could indeed be improved - as you noted, for the moment, the very (too?) simple design is to assume that the user would perform the exploit and clean sequentially before re-launching the attack, which is why the "cleaning/to_clean.txt" file is overwritten each time the tool is executed.

As suggested, a better approach would be to 1. keep track of all changes performed on the GPO attributes in case of successive attacks targeting a single GPO with no cleaning applied in between, and 2. keep track of the attacked GPOs in case of successive attacks targeting different GPOs.

Such an implementation would require a little bit of thinking on a more modular way to generate, name and delete cleaning files. I will try to implement this when I can. In the meantime, I will keep this issue opened.

[q-roland]

Considering this issue resolved with the commit f1cf03401aecb090fe95ade757b5faf8e4321769