The only thing that the user needs is write privileges over the specific group policy as such:

Escalating to domain admin:

• Group policy linked to the domain controllers → DA/Local Flag
• Group policy linked to a workstation which has a session of a DA → Second XML technique

Escalating to local admin:

• Group policy linked to a workstation → Local Flag

1. Download the entire repo
2. Import-Module .\Microsoft.ActiveDirectory.Management.dll
3. *If Import-Module failed, Open the DLL's properties and "Unblock" the file
4. Run Invoke-GPOwned using the following flags:

6. If you get an error at the end of execution that removing the scheduled task failed, don't forget to remove it manually

7. When using the second XML technique, note that it may take up to 24 hours for the scheduled task to remove itself, best practice would be to unregister the scheduled task manually to assure proper clean-up.

In the case of control over a GPO that is linked to the domain but not to the domain controllers, this attack would grant the attacker DA privileges by using a second scheduled task. The rationale behind it is that the GPO Immediate Task is always executed with NT Authority\SYSTEM privileges, which is sufficient for escalation to DA from domain controllers yet not from a workstation. MultiTasking attack essentially runs an immediate task on a workstation, which executes a powershell Register-ScheduledTask command as admin, adding a second scheduled task that is pre-built to add the attacker's user to the domain admin group, by running in the context of the "highest available privileges" of the users group("S-1-5-32-545"), as a session of a domain admin is in place, the command would run in its context. A visual explanation of it would look something along the lines of this:

graph TD;
    A[Vulnerable GPO which doesn't apply on DCs] -- contains --> B[400 Computers];
    B -- contains --> C[3 Domain Admin Sessions];
    C --> D[Regular Method];
    C --> E[MultiTasking];
    E -- Runs 1st Schtask as SYSTEM --> H[NT AUTHORITY\SYSTEM];
    D -- Runs Schtask as SYSTEM --> F[NT AUTHORITY\SYSTEM];
    F -- fails --> G[Insufficient permissions to make AD changes];
    H -- Schtask runs pre-configured batch file --> I[Powershell Register-ScheduledTask running]
    I -- 2nd Schtask as highest-available USER --> J[Domain Admin's session is used to run command]

And a live example(Using gpupdate to speed things up):

This PowerShell function checks for writable Group Policy Objects (GPOs) in an Active Directory environment and can identify where these GPOs are linked. It's particularly useful for security assessments and identifying potential privilege escalation paths through GPO modifications.

Check a specific GPO by name: Get-GPRecon -GPO "Default Domain Policy"

Check a specific GPO by name and show computers in linked OUs: Get-GPRecon -GPO "Default Domain Policy" -Full

Check a specific GPO by GUID: Get-GPRecon -GPO "{31B2F340-016D-11D2-945F-00C04FB984F9}"

Check all GPOs in the domain: Get-GPRecon -All

Check all GPOs and show computers in linked OUs: Get-GPRecon -All -Full

• The tool now checks the GPO status to see if computer policy is disabled and enables it automatically, special thanks to @mattmcnabb for the gist that made this possible!
• Interval parameter is fixed
• Auto ADModule loading bugs are fixed