Error 0xc00ce558 or 0x00ce557 - GPO permanently breaks

[jsdhasfedssad]

Hi,

This tool looks promising but during testing I encountered an error that simply breaks the targeted GPO rendering it unusable for me as a pentester and for my client. The broken GPO cannot even be deleted. This is as you understand really bad and as long as this is not fixed I cannot use your tool. pyGPOAbuse suffers from the same issue so to me it seems something has changed on the Windows Server side making both tools incompatible.

I whish I could write the specific scenario that triggers this but I have yet to find a pattern. It seems to happen more frequently when things go "wrong". For example when I forget to add the parameter "--force" or when I enter a GPO that does not exist or I do not have write access on. Just keep trying to execute various sheduled tasks and you will eventually get an error in your shell. Once you get that , access your DC and open Group Policy Management. In that, rightclick your targeted GPO and select "Edit...". Then expand "Preferences" under either "Computer Configuration" or "User configuration" depending on what object you are targeting. Finally leftclick "Control Panel Settings" and you will get the below error popup.

[jsdhasfedssad]

Update 1:

I managed to find a way to trigger a very similar error as above.

To trigger error 0x00ce557:

1. SharpGPOAbuse.exe --AddComputerTask --TaskName "test6" --Author adlab.local\domainadmin1 --Command "cmd.exe" --Arguments "dir \\10.0.0.220\whatever" --GPOName "demo_gpo7" --FilterEnabled --TargetDnsName client1.adlab.local
2. SharpGPOAbuse.exe --AddComputerTask --TaskName "test7" --Author adlab.local\domainadmin1 --Command "cmd.exe" --Arguments "dir \\10.0.0.220\whatever" --GPOName "demo_gpo7" --FilterEnabled --TargetDnsName client1.adlab.local --force

Step 2 will seem like it works but viewing "Control Panel Settings" as described above the error is revealed. My DC is running 2019 and I execute SharpGPOAbuse from a Windows 10 client logged in as a account with full access to the GPO in question. The GPO was empty and newly created before this test.

To me it seems like the file "\\adlab.local\SYSVOL\adlab.local\Policies\{[GPO unique ID]}\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml" gets incorrectly written when appending tasks to an existing file. I believe this because if I copy the file after the first abuse and overwrite the file after the second abuse the error no longer appears.