Detecting and Mitigating Group Policy Discovery (T1615)

Group Policy Discovery (T1615) is a Discovery technique on Windows. Adversaries gather information about Group Policy settings to find ways to escalate privileges, learn which security measures apply in the domain, and spot patterns in domain objects they can manipulate or use to blend in.

Group Policy lets Active Directory administrators manage settings for users and computers centrally. The objects that hold those settings, Group Policy Objects (GPOs), are readable by design, because every machine must be able to apply them.

How attackers use it

MITRE explains that GPOs are containers for settings, with files stored in a predictable network path under the SYSVOL share of the domain. Adversaries may use commands such as gpresult or publicly available PowerShell functions such as Get-DomainGPO and Get-DomainGPOLocalGroup. The information shapes later steps, including finding attack paths and opportunities to change policy, as in Domain or Tenant Policy Modification (T1484).

Tools and malware on the MITRE page that do this include BloodHound, which can collect local admin information via GPO, Empire modules for enumerating Group Policy, and Emissary, which can run gpresult. Turla surveys a system on check-in using gpresult, and DUSTTRAP and LunarWeb capture Group Policy information.

How to detect it

MITRE's analytic looks for three things together: suspicious command execution such as gpresult, PowerShell enumeration with functions like Get-DomainGPO, and abnormal LDAP queries aimed at groupPolicyContainer objects. Defenders watch for unusual process lineage, script execution and LDAP filter activity against domain controllers.

Practical collection points:

• Process creation logs with command lines (Security Event ID 4688 with command line auditing, or Sysmon Event ID 1).
• PowerShell script block logging (Event ID 4104), which records the function names in a script.
• Domain controller telemetry for LDAP searches that filter for groupPolicyContainer.

The question to ask is whether the source is a normal workstation doing its routine refresh, or an unusual host or user running enumeration. Authenticated users can read this data, so the signal is volume, timing and who is asking.

How to reduce the risk

MITRE states this technique cannot easily be mitigated with preventive controls, since it abuses system features. You can reduce what discovery reveals and what a stolen policy edit could do:

1. Limit who can edit GPOs and who can link them.
2. Audit changes to GPOs and to the SYSVOL share.
3. Avoid placing secrets in policy files, since they are broadly readable.
4. Treat discovery logs as an early warning for lateral movement and review them with the same care as account discovery.

Check your own environment

Read-only (Windows, run as a standard user to see what any user sees):

gpresult /r

Then ask:

• Which accounts can modify GPOs? Is that list short and reviewed?
• Do you collect LDAP query and PowerShell script block logs?
• Do any policy files hold passwords or scripts with embedded credentials?
• Would your tools notice a workstation enumerating every GPO in the domain?

Quick check

Sources

• MITRE ATT&CK T1615 Group Policy Discovery