TL;DR The ability to edit Group Policy Object (GPOs) from non-domain joined computers using the native Group Policy editor has been on my list for a long time. This blog post takes a deep dive into what steps were taken to find out why domain joined machines are needed in the first place and what options we had to trick the Group Policy Manager MMC snap-in into believing the computer was domain joined. For those of you who just want the tool that was created as part of this research, head over to GitHub and take a look at the DGPOEdit project. Introduction For those that a familiar with articles and tools that I have released in the past, you will realise that I advocate the use of legitimate tooling on Windows. One reason I like to use native Windows tooling is to limit indicators of compromise (IOC) on both network traffic and local execution. Unless modified from their defaults, tools such as impacket can often include hardcoded defaults that can often be detected as IOC’s when a target environment leverages an intrusion detection system. The second reason I advocate their use is speed. After importing Kerberos TGT’s within your own attacking VM using tools like Rubeus, providing DNS is fully functional and both TCP and UDP is accessible to your target environment, everything just works. Windows will automatically try to determine the nearest domain controller, fetch the relevant service tickets needed for accessing a particular service and offer these tickets as a form…Read More