How to detect AD Group Policy abuse

Threat snapshot

Group Policy is one of the most powerful administrative mechanisms in Active Directory. A single GPO linked to the domain root or to a high-level OU can push configuration changes, scripts, scheduled tasks, and software deployments to every domain-joined machine simultaneously. For an attacker who has compromised an account with GPO edit rights, this is the most efficient possible lateral movement and persistence mechanism: modify one policy, and every machine in scope executes the payload at the next Group Policy refresh cycle, typically within 90 minutes without any further attacker action.

GPO abuse is not a new technique, but it has gained renewed operational relevance as organizations deploy EDR and application control solutions that make traditional lateral movement noisier. Dropping a binary on a remote machine via PsExec or SMB triggers endpoint alerts. Adding a startup script or scheduled task via Group Policy does not: the execution is performed by the legitimate Windows Group Policy Client service, the binary is fetched from SYSVOL (a trusted location), and the process creation event shows a legitimate parent process. Without specific GPO change monitoring, the deployment is largely invisible at the endpoint level.

This page covers the attack paths attackers use to abuse Group Policy, the specific modifications most commonly seen in intrusions, and the Log360 detection rules that catch unauthorized GPO changes before they execute across the domain.

GPO abuse, at a glance

How GPO abuse attacks work

Group Policy Objects define machine and user configurations that are applied across all objects within their scope. An attacker who can modify a GPO linked at the domain or OU level can deploy any configuration to potentially thousands of machines. The three most operationally significant abuse paths are startup script injection, scheduled task creation, and privilege escalation via restricted groups or local administrator assignment.

Startup and logon script injection (T1484.001)

Group Policy allows administrators to define scripts that execute at machine startup, machine shutdown, user logon, and user logoff. These scripts are stored in the SYSVOL share on domain controllers and are delivered to machines as part of policy application. An attacker who can edit a GPO linked to a broad scope (the domain root or a high-level OU containing all workstations or all servers) can add a script to the Computer Startup section that executes as SYSTEM on every machine in scope at the next reboot or policy refresh.

The detection challenge is that legitimate startup and logon scripts are common in enterprise environments. The signal is not the script execution itself but the GPO modification event that precedes it: specifically, a change to the Scripts section of a GPO's SYSVOL folder by an account that does not normally perform GPO administration, or a change made outside normal business hours.

Log signals: Windows Security Event 5136 (directory service object modified) on domain controllers for changes to GPO objects in Active Directory. File modification events in SYSVOL (specifically the Scripts subfolder within a GPO's machine or user path). The script file itself will appear as a new or modified file in the relevant SYSVOL path.

Scheduled task creation via GPO (T1484.001)

Group Policy Preferences allows administrators to create, modify, or delete scheduled tasks on all machines within a GPO's scope. The Immediate Task type executes once as soon as the policy is applied, making it particularly useful for attackers who want rapid execution across many machines without waiting for a reboot. A scheduled task created via GPO runs under the context specified in the task definition, which can include SYSTEM, a domain account, or any local account, giving the attacker significant flexibility in execution context.

Ransomware operators have used this technique to deploy encryption payloads across entire domains simultaneously. The deployment is particularly difficult to detect at the endpoint because the scheduled task is created by the legitimate Group Policy Client service and the task itself may be configured to delete itself after execution, leaving minimal forensic evidence on individual machines.

Log signals: Windows Security Event 5136 for GPO modifications. Changes to the ScheduledTasks.xml file in the GPO's machine preferences path in SYSVOL. Task Scheduler Event 4698 (scheduled task created) on domain-joined machines when the GPO applies, where the creating process is svchost.exe (Group Policy Client).

Privilege escalation via Restricted Groups or Local Administrators (T1484.001)

Group Policy's Restricted Groups setting allows domain administrators to define the membership of local groups on all machines in scope. An attacker who modifies the Restricted Groups section of a broadly-linked GPO to add their compromised account (or a new account they have created) to the local Administrators group on all domain-joined machines achieves persistent local administrator access across the entire domain at the next policy refresh. This is one of the most operationally efficient privilege escalation techniques available to an attacker with GPO edit rights, as it requires a single policy change to achieve broad persistent access.

Log signals: Windows Security Event 5136 for GPO modifications. Changes to the Groups.xml file in the GPO's machine preferences path. Windows Security Event 4732 (member added to security-enabled local group) on target machines when the GPO applies.

Real-world campaigns

Ryuk and Conti ransomware: GPO-based domain-wide payload deployment

Ryuk and Conti ransomware operators are the most documented users of GPO-based payload deployment. The standard technique involves the operator first compromising a domain admin account through credential dumping or Kerberoasting, then creating or modifying a GPO to deploy the ransomware binary via a startup script or immediate scheduled task linked to the domain root. When the policy applies at the next refresh cycle, every domain-joined machine simultaneously executes the ransomware binary. The Conti playbook leak explicitly describes this technique as the preferred mass deployment method, noting that it is faster and less detectable than PsExec-based deployment because the execution is attributed to the Group Policy Client service rather than a lateral movement tool.

LockBit affiliates: GPO-based AV disabling before encryption

LockBit affiliates have been documented using GPO modifications specifically to disable Windows Defender and other security controls across all domain-joined machines before deploying the encryption payload. By modifying the Windows Defender group policy settings to disable real-time protection across the domain, the operator ensures that endpoint defenses are simultaneously blinded before the ransomware binary reaches any machine. The Modify Group Policy Settings rule in Log360 directly targets this pattern, catching modifications to security-relevant GPO sections including those controlling Windows Defender, audit policy, and firewall rules.

APT campaigns: GPO logon scripts for persistent credential harvesting

Several APT groups have used GPO logon scripts to deploy credential harvesting tools that execute silently each time a domain user logs on. A logon script that runs a password dumping tool or keylogger under the user's context on every logon provides persistent credential collection across the environment without requiring repeated lateral movement. The Group Policy change is made once; the harvesting runs continuously on every user logon across every machine in scope without further attacker action.

Attack technique reference table

Business impact

• Domain-wide execution from a single change. GPO abuse converts a single policy modification into simultaneous execution on hundreds or thousands of machines. The blast radius of a single unauthorized GPO change linked at the domain root is every domain-joined machine in the organization. No other lateral movement technique achieves this scale from a single action.
• Execution disguised as legitimate administration. Payload execution via GPO uses the legitimate Group Policy Client service as the execution parent. At the endpoint, the process creation looks like a normal policy application event. Without monitoring of the GPO modification event itself in Active Directory, the execution is effectively invisible at the machine level.
• Persistence that survives endpoint remediation. A malicious startup script or logon script added to a GPO continues to execute on every machine in scope every time the policy refreshes, even after the initial compromise host has been remediated. Cleaning the GPO object in Active Directory is required; cleaning individual machines without removing the GPO change is insufficient.
• Regulatory exposure from unauthorized configuration changes. Unauthorized GPO modifications that disable security controls such as audit logging, firewall rules, or endpoint protection represent control failures under PCI-DSS Requirement 6.4 (protecting system components from known vulnerabilities) and NIST CSF PR.AC-4 (managing access permissions). Organizations may face compliance findings independent of whether a data breach occurred.

Detecting AD Group Policy abuse with Log360

Log360's five detection rules for this use case cover GPO modifications across three dimensions: what was changed (settings, scripts, privilege assignments), when it was changed (after-hours anomaly detection), and how it was changed (PowerShell-based modification via ScriptBlockLogging). For these rules to fire, Windows Security event logs from domain controllers must be forwarding to Log360, specifically Event 5136 (directory service object modified) and Event 5137 (directory service object created). GPO audit logging must be enabled via the Advanced Audit Policy on domain controllers.

Attack chain visibility

GPO abuse is a late-stage attack technique. By the time an attacker modifies a GPO, they typically have already compromised a privileged account. The sequences below show the full chain from credential compromise to GPO-based domain-wide execution.

Sequence A: Ransomware deployment via GPO startup script

Sequence B: GPO-based privilege escalation for persistent access

Investigation playbook

GPO abuse investigations are time-sensitive because the impact of a malicious GPO change scales with time. Every machine that refreshes policy before the GPO is remediated executes the malicious configuration. The investigation goal is to determine what was changed, how broadly it has already applied, and whether the change must be reverted before it applies to additional machines.

Step 1: Triage - identify what was changed and its scope

Step 2: Determine how broadly the policy has already applied

• Check the time of the GPO modification against the default Group Policy refresh interval (90 minutes for computers, 90 to 120 minutes for users). If more than 90 minutes have passed since the modification, machines in scope will have already applied the malicious policy.
• Query Windows Event 4698 (scheduled task created) or look for the specific execution events on domain-joined machines to determine which machines have already applied the change. The presence of Event 4698 attributed to the Group Policy Client service on a machine confirms that machine has already received and applied the malicious policy.
• For startup script injection: machines that have rebooted since the GPO change will have executed the script. Check for the script's process creation events (Sysmon Event 1) on machines in scope to identify which hosts have already run the payload.
• For privilege escalation via Restricted Groups: check Event 4732 on domain machines to identify which hosts have already added the attacker's account to the local Administrators group.

Step 3: Investigate using the Incident Workbench

• Click on the account that made the GPO modification in the alert to open the Incident Workbench. Use the User analytics tab to review the account's activity history and UEBA risk score. A legitimate admin account that has never previously modified Group Policy suddenly making changes at 2 AM is a maximum-anomaly event.
• Use the Process analytics tab on the host where the GPO modification originated to view the full process tree. For PowerShell-based GPO modifications (caught by the ScriptBlockLogging rule), the process tree shows what spawned the PowerShell session, which may reveal the C2 or lateral movement path the attacker used to reach the host where the change was made.
• Check the User analytics tab for any prior authentication anomalies for the account used to make the GPO change, such as logons from new IPs or unusual hours in the days preceding the GPO modification. GPO abuse follows credential compromise; the credential theft may have occurred days before the GPO change.
• Save the Incident Workbench session to an incident. The process tree and user activity timeline document the full chain from credential compromise to GPO modification to execution.

Step 4: Determine full scope of the compromise

• Identify all GPOs that the compromised account had edit rights to, not just the one that fired the alert. An attacker with GPO edit rights may have modified multiple policies as part of the same operation.
• Check whether the same account was used for other administrative actions in the same time window: user account creation, group membership changes, ADCS certificate issuance, or other GPO links being created or modified. GPO abuse is often one step in a broader post-compromise operation.
• For script injection attacks: analyze the script that was added to the GPO. Understanding the payload tells you whether the attacker's objective was persistence, credential harvesting, ransomware deployment, or something else, which determines the scope of the incident response.
• Determine whether the domain admin account used for the GPO change was a legitimate admin account that was compromised, or a new account created specifically for this purpose. New admin accounts created shortly before a GPO modification indicate the attacker first escalated privileges before making the change.

Step 5: Collect evidence and build the timeline

• Export Event 5136 logs from all domain controllers for the relevant time period. Event 5136 records include the GPO object distinguished name, the attribute that was modified, the old value, the new value, and the account that made the change. This is the primary forensic record for the GPO modification.
• Preserve the contents of the modified GPO from SYSVOL before reverting. The malicious script, Groups.xml, or ScheduledTasks.xml file is forensic evidence showing exactly what the attacker intended to deploy.
• Export the process creation timeline from any machines that have already executed the malicious policy. This documents the extent of payload execution and is required for breach assessment.
• Export the Incident Workbench session timeline as the compliance artifact for NIST CSF DE.AE-5 (incident analysis) and HIPAA Section 164.308(a)(6) (security incident procedures).

Response and remediation

Immediate containment

• Revert the malicious GPO change immediately. For startup script injection: remove the malicious script entry from the GPO's Scripts section and delete the script file from SYSVOL. For Restricted Groups abuse: remove the attacker's account from the Groups.xml. For settings modifications: restore the previous setting values. The revert must happen in Active Directory and in SYSVOL, not just one location.
• Force a Group Policy update on all affected machines using gpupdate /force (for individual machines) or via a management tool that can push gpupdate across the OU scope. This applies the corrected policy before the next automatic refresh cycle and prevents additional machines from executing the malicious configuration.
• Disable the compromised account used to make the GPO change. Reset its password and revoke any active sessions. If the account is a service account, coordinate with the relevant team before disabling.
• On machines that have already applied the malicious policy: remove the malicious scheduled task, remove the startup script from local execution points, or remove the attacker's account from the local Administrators group, as appropriate to the specific change made.

Response actions by trigger

Hardening

• Apply the principle of least privilege to GPO edit permissions. Review which accounts have edit rights on each GPO, particularly GPOs linked at the domain root or to high-level OUs with broad machine scope. Reduce the number of accounts with GPO edit rights to the minimum necessary. Consider requiring separate, dedicated GPO administration accounts that are not used for day-to-day operations.
• Enable GPO change notifications via Active Directory audit logging. Ensure Event 5136 (DS object modified) is captured from all domain controllers and forwarding to Log360. Without this, GPO changes are invisible in the SIEM. Configure the Advanced Audit Policy category "DS Access: Audit Directory Service Changes" to Success on all DCs.
• Use GPO versioning and change approval workflows. Implement a change management process that requires approval before GPO modifications can be made in production. Tools such as Microsoft's Advanced Group Policy Management (AGPM) provide GPO versioning, offline editing, and approval workflows that create an audit trail and prevent unauthorized changes from taking effect immediately.
• Restrict write access to SYSVOL. Only domain controller machine accounts and explicitly authorized admin accounts should have write access to the SYSVOL share. Abnormal write operations to SYSVOL from standard user workstations are a reliable indicator of GPO abuse. Monitor SYSVOL write events via file auditing on domain controllers.
• Enable Protected Users security group membership for all GPO administrator accounts. Protected Users prevents those accounts from using NTLM authentication and limits their Kerberos ticket lifetimes, making credential theft and reuse harder for attackers targeting GPO admin accounts specifically.

False positive tuning