Group Policy Abuse: Active Directory Attacks

How the Attack Works

A Group Policy object is linked to a site, a domain or an organisational unit, so every machine and user beneath that container reads it and applies what it says. Each object has a half in the directory, the groupPolicyContainer, and a half in files on the SYSVOL share, and a machine re-reads both at startup, at sign-in and on a background refresh. With write access to a policy that many machines read, one change reaches all of them, which is why a single edit can switch off a defence or add a scheduled task everywhere the policy applies. A domain controller records the directory change, and the file change shows on the SYSVOL share it holds.

Read first Authentication and Authorisation

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

A policy linked to the finance servers is changed from ws-042, the directory and SYSVOL changes land on dc-01, and each finance server applies it at its next refresh.Step through it

ws-042 Foothold

dc-01 Domain controller

srv-fin-01 File server

Step 1 of 3, Policy Changed, ws-042 to dc-01
Step 2 of 3, SYSVOL Write, ws-042 to dc-01
Step 3 of 3, Applied Everywhere, on srv-fin-01

Step 1 of 3: Policy Changed
ws-042 Foothold to dc-01 Domain controller
The groupPolicyContainer for a policy linked to the finance servers is modified, and the policy's version number rises.
Logged
- 5136 A directory service object was modified
  On dc-01, in the Security log When enabled
  A Group Policy object modified, with the account that changed it.
What Defenders See
The Security log on dc-01 shows event 5136 on the groupPolicyContainer, naming the policy and the account that changed it.
Step 2 of 3: SYSVOL Write
ws-042 Foothold to dc-01 Domain controller
A file inside the policy's folder on the SYSVOL share is written, such as the one that defines a scheduled task.
Logged
- 4663 An attempt was made to access an object
  On dc-01, in the Security log When enabled
  A write to a policy file in SYSVOL, with the access right used.
What Defenders See
The Security log on dc-01 shows event 4663 on the SYSVOL file, with a write access right, dating when the file changed.
Step 3 of 3: Applied Everywhere
On srv-fin-01 File server
At its next refresh srv-fin-01 reads the changed policy and applies it, as does every machine the policy is linked to.
What Defenders See
On srv-fin-01 the effect shows, such as a new scheduled task or Microsoft Defender Antivirus switched off, with the Group Policy copy of the setting in the Registry.

Needs First

What the attacker must already hold for this attack to be possible.

Write Access to a Directory Object or Domain Admin RightsWrite access to a Group Policy object, from a delegated edit right up to Domain Admin.

Comes From

Directory Write: DCShadow
Domain Admin: Golden Ticket, Diamond and Sapphire Tickets, Certificate Services Abuse, noPac (sAMAccountName Spoofing) every attack that gives it: Domain Admin Rights

Gives the Attacker

What running it hands the attacker to use next.

Local Admin RightsA setting or a task on every machine the policy reaches, so control of each at its next refresh.

Leads To

Local Admin: LSASS Memory Theft, SAM, LSA Secrets and Cached Logons, Clearing and Silencing Logs

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and Log	Written On	Look For	Switch It On
5136 `A directory service object was modified` (opens in a new tab) Security log	Domain controllers, for objects with a matching audit entry	A Group Policy object (Class groupPolicyContainer) modified, read with the account that changed it and whether a change request explains it.	Audit Directory Service Changes, and an audit entry (SACL) on the object
5137 `A directory service object was created` (opens in a new tab) Security log	Domain controllers, for objects with a matching audit entry	A new Group Policy object created that no change request explains, read with the account that created it.	Audit Directory Service Changes, and an audit entry (SACL) on the parent container
5141 `A directory service object was deleted` (opens in a new tab) Security log	Domain controllers, for objects with a matching audit entry	A Group Policy object deleted, which can remove a setting or a whole policy and the protection it carried.	Audit Directory Service Changes, and an audit entry (SACL) on the object
4663 `An attempt was made to access an object` (opens in a new tab) Security log	The computer that holds the object, a domain controller for the files in SYSVOL	A write to a file in a policy's SYSVOL folder, such as the one defining a scheduled task, which dates the file change.	Audit File System, and an audit entry (SACL) on the object

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

5136 A directory service object was modified

In the Security log on dc-01, 15 Oct 2026, 16:20:00 UTC

A Group Policy object modified on dc-01, a policy linked to the finance servers.

The attribute that changed. A policy's version number rises on every edit, so a bump with no change request is the thread to pull.
As Windows writes it: LDAP Display Name versionNumber
The policy object that changed, named by its GUID under the Policies container. Match the GUID to the policy and see which machines it is linked to.
As Windows writes it: DN CN={7b9a1c43-0e2f-4d58-9a6b-2c3d4e5f6a7b},CN=Policies,CN=System,DC=corp,DC=example
The object is a Group Policy object, so this is a change to a policy rather than to a single account.
As Windows writes it: Class groupPolicyContainer
The account that made the change. Match its Logon ID to event 4624 to see where the change was made from.
As Windows writes it: Subject Account Name adm-alice

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Group Policy Tampering (opens in a new tab)Raised for the case Microsoft documents, a Group Policy change that switches off Microsoft Defender Antivirus. It does not cover every policy change, so read it with events 5136 and 4663.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

Events 5136, 5137 and 5141 are written only on domain controllers, and only where Audit Directory Service Changes is on with an audit entry on the policy objects. Without that, a change to a policy leaves nothing in the directory log.
Event 4663 needs Audit File System and an audit entry on SYSVOL, which is rarely set, so the file change often has no event. The policy's version number and the SYSVOL file dates are then the only record.

Look for It on a Machine

The Registry keys on an endpoint that hold a trace of this, each opening its own page.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Needs Defender for Identity sensors on every domain controller. The alert covers only the Microsoft Defender Antivirus case, not the SYSVOL file write or every policy change, so confirm it against events 5136 and 4663.

KQLDefender XDR, Advanced hunting

// Defender for Identity Group Policy Tampering alertsAlertInfo| where Timestamp > ago(30d)| where Title == "Group Policy Tampering"| join kind=inner AlertEvidence on AlertId| summarize FirstSeen = min(Timestamp), Accounts = make_set(AccountName), Devices = make_set(DeviceName) by AlertId, Title| order by FirstSeen desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Least-privilege administration (opens in a new tab)
Keep the right to edit each Group Policy object to the few who own it, and review who holds it.
Tiered administration (opens in a new tab)
Make Group Policy changes only from a privileged access workstation, so a change from an everyday machine is a flag.

Attacks tied to this one that its needs and gives do not already name, such as another form of it or its reverse, each with how the two connect.

Backdoor Accounts and Group Changes
Another quiet way to keep access, a new account or a group change that leaves its own event.

How the Attack Works

How It Plays Out

Step 1 of 3: Policy Changed

Step 2 of 3: SYSVOL Write

Step 3 of 3: Applied Everywhere