SandboxEscaper explained the bug as follows:
The task scheduler service has an alpc endpoint, supporting the method “SchRpcSetSecurity”.
Tasks created by the task scheduler will create a corresponding folder/file in c:\windows\system32\tasks. This function seems to be designed to write the DACL of tasks located there, and will do so while impersonating. However, for some reason it will also check if a .job file exists under c:\windows\tasks and try to set the DACL while not impersonating. Since a user, and even a user belonging to the guests group can create files in this folder, we can simply create a hardlink to another file (all we need is read access). Because of the hardlink, we can let the task scheduler write an arbitrary DACL (see second parameter of SchRpcSetSecurity) to a file of our choosing.
So any file that we have read access over as a user and that system has the write DACL permission for, we can pivot into full control and overwrite it.
I was able to review the source and recompile the exploit as is. This provided me a notepad.exe process running as SYSTEM. There are already tons of demos showing this behavior (including the .mp4 included with the exploit); therefore, I will have no screenshots documenting that process.
However, I wanted to run something a bit more malicious as NT SYSTEM. I decided to try a few different “out-of-the-box” payloads with the exploit.
This was then added to the project in Visual Studio, replacing the pre-existing exploit.dll file. You will need to edit line 52 of Resource.rc to change the relative path to the new .dll. There were so many Visual Studio errors during build that it became too cumbersome and I found another blog post here that just used CFF Explorer to modify the pre-existing APLC-TaskSched-LPE.dll.
Results thus far:
|Meterpreter||X||This works right out of the box, but Windows Defender does no like it.|
|Empire||X||I haven’t sussed out why this didn’t work; more research required.|
|Merlin||X||I spent a bit of time modifying the original merlindllagent and had no issues running it with regsvr32 or rundll32.|
These issues might just be based on the expected execution method and the exploit itself will need to be modified completely. More time will be dedicated on getting the project sorted out in Visual Studio and hacking it from there instead of just modifying a resource in a pre-existing .dll.