MITRE ATT&CK T1615 Group Policy Discovery: Spotting Enumeration Early

Group Policy tells an intruder which security controls apply where, which groups are local administrators on which machines, and which policy objects they could change to take over the domain. MITRE ATT&CK T1615 Group Policy Discovery covers adversaries gathering information on Group Policy settings to identify paths for privilege escalation, the security measures applied within a domain, and patterns in domain objects they can manipulate or use to blend in. It sits in the Discovery tactic (TA0007), applies to Windows, and has no sub-techniques in ATT&CK v20. The difficulty for defenders is that every domain-joined computer reads Group Policy as part of normal operation, so the signal is in who reads it, how much and with which tool. This guide is for detection engineers, SOC analysts and Active Directory administrators. Securing Group Policy itself, including delegation, SYSVOL permissions and secrets in policy, is in the Group Policy Security Guide; this page stays on spotting enumeration early.

Key takeaways

• Enumeration precedes modification. ATT&CK links T1615 to follow-on T1484 Domain or Tenant Policy Modification: adversaries look for GPOs they can edit before they edit one.
• Reading policy is normal; bulk reading is not. Computers and users process their own policy all the time. A single workstation process querying every groupPolicyContainer object, or reading every folder under SYSVOL Policies, stands out against that baseline.
• ATT&CK names four log sources. Its analytic for T1615 uses Security event 4661, Sysmon event 1, PowerShell events 4103 to 4106, and network flow showing high-volume LDAP queries targeting groupPolicyContainer attributes.
• No preventive mitigation is mapped. ATT&CK v20 lists no mitigation for T1615; Group Policy must stay readable for clients to apply it. Reduce what policy reveals and make the dangerous paths unusable.
• The tooling is well known. ATT&CK records gpresult use by Turla and Emissary, Group Policy modules in Empire, local admin collection through GPOs in BloodHound, and Group Policy collection in LunarWeb and DUSTTRAP.

What T1615 covers

ATT&CK describes Group Policy Objects (GPOs) as containers for policy settings made up of files stored under a predictable network path, the domain's SYSVOL share under Policies. Each GPO also has a groupPolicyContainer object in Active Directory that holds its attributes and links. An adversary can read three layers:

The output shapes later steps: which hosts lack EDR or logging policy, where a user's group gives local admin (T1078 and lateral movement), and which GPO an account can write to (T1484.001 Group Policy Modification). Related discovery of accounts and groups is covered in T1087 and T1069 Account and Permission Group Discovery.

How adversaries use it: recorded cases

From ATT&CK v20 and the reports it cites; attribution is as stated by those sources.

See the Turla Threat Actor Profile and APT41 Threat Actor Profile. Because BloodHound and similar collectors are also used by defenders and authorised testers, an alert should check the account, host and change record before escalation. See the BloodHound and Active Directory Attack Path Guide.

What to detect and where

ATT&CK v20 detection strategy DET0055 for T1615 describes detecting suspicious command execution (gpresult), PowerShell enumeration (Get-DomainGPO, Get-DomainGPOLocalGroup) and abnormal LDAP queries targeting groupPolicyContainer objects, observing unusual process lineage and script execution. The table maps its log sources to practical analytics.

Microsoft documents that event 4662 (an operation was performed on an Active Directory object) is generated only when the object has a SACL that matches the operation, under the Audit Directory Service Access subcategory, and that its Object Type field can be groupPolicyContainer. Auditing reads on every GPO will be noisy because clients read them constantly; scope any SACL to sensitive GPOs or to write operations, and rely on LDAP and EDR telemetry for read patterns. Microsoft also recommends Protected Event Logging when script block logging is used beyond diagnostics, because logged script content can include credentials.

Sequences beat single events. Group Policy discovery seldom happens alone. A higher-confidence detection combines it, within minutes on one host or account, with domain trust, account and group, and remote system discovery. The ATT&CK Discovery Tactic (TA0007) Guide covers sequence-based detection across the tactic, and the Active Directory Security Monitoring and Event IDs Guide covers audit policy for domain controllers.

Reducing what discovery reveals

ATT&CK v20 maps no mitigation to T1615. The following are NHI Mgmt Group recommendations that make the information less useful.

1. Remove secrets from policy: search SYSVOL for stored credentials in Group Policy Preferences, scripts and configuration files and remove them, rotating any credential found. See the secrets section of the Group Policy Security Guide.
2. Fix who can edit GPOs: review edit, delete and modify-security rights on every GPO and on the OUs they link to; enumeration is only dangerous where it finds writable policy. See MITRE ATT&CK T1484 Domain or Tenant Policy Modification.
3. Narrow local admin grants: replace broad groups added to local Administrators through policy with tiered, per-host or just-in-time models, so a map of who is admin where is short.
4. Remove stale GPOs: unlinked and legacy GPOs carry old scripts, paths and group names that guide an adversary and that nobody monitors.
5. Turn on the telemetry: enable PowerShell script block logging (the "Turn on PowerShell Script Block Logging" policy), Sysmon or EDR process creation with command lines, and LDAP query visibility on domain controllers.
6. Plant tripwires: a decoy GPO with an attractive name and no links, or a decoy account referenced in policy, gives high-confidence alerts when read or used. See Decoy accounts in Active Directory.

Where identity fits

Group Policy is a map of identity: which groups and service accounts are local administrators, which accounts run scheduled tasks and startup scripts, and which identities hold rights to edit policy. Service accounts are frequent findings because they are often granted local admin across many servers through a single GPO and rarely reviewed. Inventory accounts referenced in GPOs, give each an owner, remove broad local admin grants, and alert when a service account runs interactive discovery tools such as gpresult or PowerShell enumeration, since service accounts should not do that. See How to build a service account inventory from Active Directory.

How to test detection

1. Prepare: agree scope and a change record, use a lab domain or a test OU first, and tell the SOC which test account and host you will use.
2. Single host: run gpresult with summary and verbose output for the test user from an ordinary workstation and confirm Sysmon or EDR captures the command line and parent process.
3. PowerShell: run an authorised AD module query that lists all GPOs and confirm the script block reaches the SIEM.
4. Directory: run an authorised collector in the test OU (for example the BloodHound collector the AD team already uses) and confirm LDAP volume and handle requests are visible.
5. Tune: compare with the baseline, exclude named admin hosts and tools by host and account, not by command line, and record the false positive rate after two weeks.
6. Roll back: remove test accounts, decoys you do not keep and any temporary SACLs; keep the detection rules.

Measuring it

• Telemetry coverage: percentage of Windows endpoints and servers sending process command lines and PowerShell script block events.
• Detection test pass rate: share of the test steps above that alerted, run each quarter.
• Writable GPO exposure: count of GPOs editable by non-tier-0 principals, trending to zero.
• Local admin breadth: number of hosts where a single non-admin group is granted local admin through policy.
• Secrets in SYSVOL: credentials found per scan (target zero).

Common failure patterns

• Alerting on gpresult alone: help desk use floods the queue and the rule is disabled; use context such as parent process, host role and account type.
• SACLs on every GPO read: 4662 volume overwhelms the SIEM and auditing is turned off, losing the write events that matter most.
• No command lines: process creation is logged without command line arguments, so gpresult /z cannot be told from routine use.
• Ignoring authorised tools: tester and admin BloodHound runs are excluded by tool name, which also excludes an adversary using the same tool.
• Treating discovery as harmless: enumeration alerts are closed as informational, while the same account edits a GPO hours later.

Framework mapping

Practitioner checklist

• Process creation with command lines and PowerShell script block logging are collected from all Windows hosts.
• Domain controller LDAP query telemetry is available to the SOC.
• Detections combine Group Policy discovery with other discovery on the same host or account within a short window.
• Admin and help desk hosts that legitimately run gpresult are baselined by host and account.
• SYSVOL contains no stored credentials, and any found have been rotated.
• Only tier-0 principals can edit GPOs linked to tier-0 assets.
• Service accounts referenced in GPOs are inventoried and alerting covers interactive tool use by them.
• Detection is tested each quarter with an authorised, recorded exercise.

Standards and references

• MITRE ATT&CK: T1615 Group Policy Discovery
• Microsoft Learn: gpresult
• Microsoft Learn: 4662(S, F) An operation was performed on an object
• Microsoft Learn: about_Logging_Windows
• ESET WeLiveSecurity: From Agent.BTZ to ComRAT v4, a ten-year journey
• Google Cloud (Mandiant): APT41 Has Arisen From the DUST
• MITRE ATT&CK: T1484.001 Group Policy Modification

Related NHI Mgmt Group resources: Group Policy Security Guide, Discovery and Reconnaissance Techniques Guide, LDAP Security Deep Dive Guide, PowerShell Security Guide.