How do you detect GPO abuse?

Detect GPO abuse by watching both halves of a policy. In the directory, enable Audit Directory Service Changes and alert on Events 5136 and 5137 for groupPolicyContainer objects and gPLink changes. In SYSVOL, alert on Event 5145 writes to ScheduledTasks.xml, Scripts, GptTmpl.inf and similar files. Then compare the actor and time against an allowlist of GPO administrators and your change calendar, and prioritise anything linked at the domain root or the Domain Controllers OU.

Detecting GPO Abuse: Unexpected Policy Edits and SYSVOL Changes

Attackers with rights over a GPO or its link can push scheduled tasks, startup scripts or security-setting changes to thousands of hosts, and ransomware crews use this to deploy at scale. A GPO has two parts, a directory object and a folder in SYSVOL, and both leave events. Watching both, and comparing against your change calendar, makes abuse stand out.

Signals at a Glance

Signal	Where	ATT&CK
New groupPolicyContainer object created	DC Security 5137	T1484.001
Change to gPLink on the domain root or an OU	DC Security 5136	T1484.001
Edit to gPCMachineExtensionNames or versionNumber outside a change window	DC Security 5136	T1484.001
Write to ScheduledTasks.xml, Scripts or GptTmpl.inf in SYSVOL	DC Security 5145	T1484.001
Edit by an account that is not a GPO administrator	5136 + identity data	T1484.001

Directory Changes

Enable the Audit Directory Service Changes subcategory and make sure the GPO container and OU objects carry a SACL. Event ID 5136 then records the attribute, the old and new value and the account. The attributes that matter are gPLink, gPCMachineExtensionNames, gPCUserExtensionNames and gPCFileSysPath:

title: Group Policy Object Or Link Modified
status: experimental
logsource:
  product: windows
  service: security
detection:
  gpo_object:
    EventID: 5136
    ObjectClass: 'groupPolicyContainer'
    AttributeLDAPDisplayName:
      - 'gPCMachineExtensionNames'
      - 'gPCUserExtensionNames'
      - 'gPCFileSysPath'
  link_change:
    EventID: 5136
    AttributeLDAPDisplayName: 'gPLink'
  gpo_created:
    EventID: 5137
    ObjectClass: 'groupPolicyContainer'
  filter_admins:
    SubjectUserName|startswith: 'gpo-admin-'   # tune/validate: your naming convention
  condition: (gpo_object or link_change or gpo_created) and not filter_admins
level: high
# versionNumber changes on every edit; use it only to count edits, not to alert.

Directory events do not show what a policy actually does. The body of a policy is in SYSVOL, so watch writes to the files that run code or change security settings:

SecurityEvent
| where EventID == 5145 and ShareName endswith "SYSVOL"
| where AccessList has "%%4417" or AccessMask == "0x2"   // WriteData / AddFile
| where RelativeTargetName has_any ("ScheduledTasks.xml", "Scripts", "GptTmpl.inf",
                                    "Registry.pol", "Services.xml", "Files.xml")
| where SubjectUserName !startswith "gpo-admin-"   // tune/validate
| project TimeGenerated, Computer, SubjectUserName, IpAddress, RelativeTargetName

Tie It to Change Control

Legitimate administrators edit GPOs constantly, so the detection is about who, when and what. A short list of controls keeps the alert useful:

Maintain a list of accounts allowed to edit Group Policy and alert on every edit by anyone else.
Alert on any scheduled-task, immediate-task or startup-script change to a GPO linked at the domain root or to a Domain Controllers OU, regardless of who made it.
Compare edits against your change calendar; an edit with no ticket is a lead even from an admin account.
Review who has GpoEdit, GpoEditDeleteModifySecurity or write rights on OUs; those delegations are the attack path.
Back up GPOs on a schedule so unexpected changes can be diffed.

Vetted sources

Use the SigmaHQ and Elastic Group Policy rules, the Splunk ESCU GPO analytics and Microsoft’s guidance on delegating Group Policy administration. Baseline your own environment — versionNumber and extension-name updates occur on every legitimate edit, so alert on the actor and the content, not on the existence of a change.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Directory Changes

Tie It to Change Control

Build Detections That Fire

Active Directory Attack Detection

Detection Hub

AD ACL Abuse Detection