Group Policy Abuse for Privilege Addition
editGroup Policy Abuse for Privilege Addition
editDetects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins.
Rule type: eql
Rule indices:
- logs-system.security*
- logs-windows.forwarded*
- winlogbeat-*
Severity: high
Risk score: 73
Runs every: 5m
Searches indices from: None (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
Tags:
- Domain: Endpoint
- OS: Windows
- Use Case: Threat Detection
- Tactic: Privilege Escalation
- Data Source: Active Directory
- Resources: Investigation Guide
- Use Case: Active Directory Monitoring
- Data Source: Windows Security Event Logs
Version: 215
Rule authors:
- Elastic
Rule license: Elastic License v2
Investigation guide
editTriage and analysis
Investigating Group Policy Abuse for Privilege Addition
Possible investigation steps
- What GPO extension change was preserved?
-
Focus:
winlog.event_data.AttributeLDAPDisplayName,winlog.event_data.AttributeValue,winlog.event_data.OperationType,winlog.event_data.ObjectDN, andwinlog.event_data.ObjectGUIDconfirm the 5136 "gPCMachineExtensionNames" GPO change. - Implication: escalate when the value enables Security CSE GUID "827D319E-6EAC-11D2-A4EA-00C04F79F83A" plus Computer Restricted Groups GUID "803E14A0-B4FB-11D0-A0D0-00A0C90F574B" on an unexpected GPO; lower concern only when artifacts/scope confirm a recognized hardening refresh.
- Who changed the GPO, and from where?
-
Focus: identify the writer:
winlog.event_data.SubjectUserSid,winlog.event_data.SubjectUserName,winlog.event_data.SubjectLogonId, andwinlog.computer_name. -
Hint: on
winlog.computer_name, find "4624" wherewinlog.event_data.TargetLogonIdequals the 5136winlog.event_data.SubjectLogonId; search "4648" onwinlog.event_data.SubjectLogonIdfor explicit credentials, then checksource.ip,winlog.logon.type,winlog.event_data.TargetUserName, andwinlog.event_data.TargetServerName. Missing logon telemetry is unresolved, not benign. - !{investigate{"description":"","label":"Linked logon for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
- !{investigate{"description":"","label":"Explicit-credential events for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}
- Implication: escalate when the writer is outside GPO admin cohort, uses an unusual source or direct domain-controller session, or shows alternate-credential use; lower concern when account/session match a recognized GPO administration path.
- Do surrounding directory changes show a coordinated GPO update?
-
Why: "5136" can record related object modifications;
winlog.event_data.OpCorrelationIDseparates one GPO edit from directory noise. -
Focus: reconstruct surrounding "5136" records from the same domain controller with
winlog.event_data.OpCorrelationID,winlog.event_data.SubjectLogonId,winlog.event_data.ObjectGUID, changed attribute, and operation type. -
Hint: prefer one
winlog.event_data.OpCorrelationID; if absent, use the samewinlog.event_data.SubjectLogonIdplus tight@timestampandwinlog.record_idordering. !{investigate{"description":"","label":"5136 events in this GPO change operation","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} - Implication: escalate when the operation touches other sensitive GPO attributes or combines this privilege path with GPO execution or persistence; lower concern when the 5136 set stays narrow and artifact/scope checks confirm one recognized security-template task.
- What grants and recipients does the SYSVOL template define?
- Why: the alert proves machine security extensions were enabled; rights or local group membership live in "GptTmpl.inf" under the SYSVOL policy folder.
-
Focus: use the policy GUID from the CN portion of
winlog.event_data.ObjectDNwithwinlog.event_data.DSNameto inspect "Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf"; map SIDs/groups to admin tier, service-account role, and whetherwinlog.event_data.SubjectUserSidbenefits. Treatwinlog.event_data.ObjectGUIDas the AD object pivot, not the SYSVOL folder name, unless it matches the CN. -
Hint: if SYSVOL is unavailable, preserve
winlog.event_data.ObjectDN,winlog.event_data.ObjectGUID,winlog.event_data.DSName, and expected policy path; suspicious writer/session or companion 5136 evidence makes the missing grant an evidence gap. - Implication: escalate when "[Privilege Rights]" grants high-impact rights ("SeDebugPrivilege", "SeTakeOwnershipPrivilege", "SeEnableDelegationPrivilege", or "SeImpersonatePrivilege"), when "[Group Membership]" adds broad/unexpected identities to local Administrators ("S-1-5-32-544"), or when the writer benefits; lower concern when entries and recipients match the recognized baseline for that GPO.
- Which computers consume the changed GPO?
- Why: GPO privilege abuse scales with link scope, security filtering, WMI filters, and reach to admin workstations, servers, or domain controllers.
-
Focus: use
winlog.event_data.ObjectDNand the recovered policy-folder GUID to review GPO links, security filtering, WMI filters, and roles. -
Hint: if scope data is unavailable, preserve
winlog.event_data.ObjectDNandwinlog.event_data.ObjectGUID; do not assume narrow scope, and escalate if writer/session, companion-change, or grant evidence is suspicious. - Implication: prioritize escalation when the GPO reaches domain controllers, admin workstations, servers, or broad workstations; lower urgency only when scope matches the recognized maintenance/test population established by the grant evidence.
- If evidence remains suspicious or unresolved, do related events show broader abuse?
-
Focus: after confirming
user.idis the writer, review recent modifying-account activity. !{investigate{"description":"","label":"Recent events associated with the source account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} -
Hint: compare with activity scoped to the same
winlog.event_data.ObjectGUID. !{investigate{"description":"","label":"Events associated with the modified GPO","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} - Implication: escalate scope when the writer or same GPO appears in other GPO abuse, credential access, privilege escalation, or lateral movement; quiet history only narrows scope and cannot close unresolved grant or blast-radius questions.
- Escalate for unexpected writer/session, companion change, high-impact grant, sensitive scope, or related abuse; close only when the same GPO, writer/session, recovered grants, and scope prove one recognized hardening or restricted-groups workflow; if evidence stays mixed or incomplete, preserve GPO artifacts and escalate.
False positive analysis
-
Authorized GPO hardening, restricted-groups maintenance, red-team, or detection-validation can update "gPCMachineExtensionNames" and "GptTmpl.inf". Confirm only when writer/session, GPO object,
winlog.event_data.OpCorrelationID, recovered template entries, and linked scope match the admin tier, change window, template, or test plan. Quiet history supports but cannot replace that proof; if any anchor diverges, do not close as benign. -
For exceptions, validate one authorized workflow matching writer SID, GPO object, grant pattern, and linked OU/host scope. Build the exception from that pattern, not broad
event.code, "gPCMachineExtensionNames", or GPO modification activity.
Related rules
- Scheduled Task Execution at Scale via GPO - 15a8ba77-1c13-4274-88fe-6bd14133861e
- Startup/Logon Script added to Group Policy Object - 16fac1a1-21ee-4ca6-b720-458e3855d046
Response and remediation
- If confirmed benign, reverse temporary containment and document writer SID, GPO object, logon/correlation IDs, recovered "GptTmpl.inf", and OU/host scope matching the workflow. Keep exceptions narrow and tied to that stable pattern.
-
If suspicious but unconfirmed, preserve the "5136" event, object and writer/session IDs,
winlog.event_data.OpCorrelationID,winlog.computer_name, exported "GptTmpl.inf", available SYSVOL metadata, linked "4624"/"4648" events, and related activity before containment. Use reversible controls first: restrict affected-GPO edits, limit the writer’s GPO admin path, or monitor linked systems during scoping. Disable accounts or roll back GPOs only if follow-on abuse or malicious grants are confirmed. -
If confirmed malicious, preserve evidence first, remove unauthorized "[Privilege Rights]" or "[Group Membership]" entries, roll the GPO back to known-good state, and verify exported SYSVOL metadata before forcing policy refresh. Use identity/endpoint response to contain the writer account and admin workstation identified by
source.iporwinlog.logon.type; if unavailable, escalate with writer/session, GPO, correlation, and SYSVOL artifacts. - Review linked OUs and affected computers before deleting artifacts or forcing "gpupdate"; complete scoping before evidence changes.
- Harden: restrict GPO edit rights to dedicated admin tiers, retain "5136" auditing, keep security-template baselines, and document abuse variants or visibility gaps for detection engineering.
Setup
editSetup
Audit Directory Service Changes must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-directory-service-changes
Rule query
editany where host.os.type == "windows" and event.code: "5136" and winlog.event_data.AttributeLDAPDisplayName: "gPCMachineExtensionNames" and winlog.event_data.AttributeValue: "*827D319E-6EAC-11D2-A4EA-00C04F79F83A*" and winlog.event_data.AttributeValue: "*803E14A0-B4FB-11D0-A0D0-00A0C90F574B*"
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
-
Technique:
- Name: Domain or Tenant Policy Modification
- ID: T1484
- Reference URL: https://attack.mitre.org/techniques/T1484/
-
Sub-technique:
- Name: Group Policy Modification
- ID: T1484.001
- Reference URL: https://attack.mitre.org/techniques/T1484/001/