Detecting T1615 Group Policy discovery

What T1615 Group Policy discovery reveals about your environment

When your SOC sees T1615 Group Policy Discovery, an intruder is most likely orienting inside Active Directory. Group Policy Objects hold a detailed map of domain configuration: which settings apply to which organizational units, where logon scripts and software deployments point, how security baselines are enforced and which administrative paths are trusted. Reading that map tells an adversary where controls are weak, where privileged systems sit and where to move next. The practical question for the SOC lead is whether the query came from an administrator's expected tooling or from an unfamiliar process on a workstation that has no reason to enumerate policy.

ATT&CK's Discovery tactic, TA0007, is described by MITRE as the adversary trying to figure out your environment. Discovery techniques cover the questions an intruder asks after gaining a foothold: which accounts exist, which hosts are reachable, which software and security tools are installed, and how the domain is configured. T1615 sits among these identity and configuration techniques, alongside account, domain trust and permission group discovery. Because these queries are cheap and often use built-in functions, they frequently appear early in an intrusion, which makes them a useful signal to catch before lateral movement begins. Detection value is highest when Discovery events are correlated with the account, host and time of the surrounding activity.

This page maps to Enterprise ATT&CK version 20.0, released by MITRE on 2026-10-13. Detection strategies, analytics and data component references can change between ATT&CK releases, and techniques can be renamed, deprecated or revoked. Before you build or audit a rule, confirm the technique and data component IDs against the version your SOC actually uses, and record that version in the rule metadata so that a later review can tell whether a mapping has moved. The MITRE ATT&CK updates page lists each release and its changes.

Telemetry sources that expose Group Policy discovery on Windows

This table maps each ATT&CK data component referenced for Discovery work to the signal it gives for Group Policy discovery on Windows, the open-source collector that captures it, and what must be enabled first. Read it as a checklist: a row is only useful once the listed logging is confirmed on the endpoints and sensors in your environment. Process Access is included as a coverage item to review, not as a primary source.

Data component	Signal for T1615	Collector and prerequisites
Process Creation (DC0032)	Parent-child process lineage and the image that started a host-side query tool, which shows whether an unexpected binary or account ran the activity	Wazuh agent or Windows event collection with process creation auditing enabled and command line capture turned on; confirm the event source reaches the manager or SIEM
Command Execution (DC0064)	Command content, including the arguments passed to Group Policy query tooling and scripting hosts, which separates routine administration from enumeration	Sysmon-style logging or equivalent endpoint telemetry with command line recording; confirm PowerShell script block logging is enabled where scripting hosts are in use
Network Traffic Content (DC0085)	Directory query traffic to domain controllers over LDAP and related protocols, showing which hosts requested policy objects and at what volume	Zeek or Suricata sensors positioned to see traffic to domain controllers; confirm protocol parsers are enabled and that domain controller segments are mirrored or tapped
Process Access (DC0035)	Reviewed for related Discovery work; it can show a process reading directory or policy-related data from another process, but coverage varies by tooling	Sysmon-style process access events with filters scoped to avoid noise; confirm the rule set is reviewed and that volume is tested before enabling broadly
Domain controller event logging	Directory service access and object query records that corroborate network and endpoint signals on the server side	Windows event collection from domain controllers via Wazuh agent or log forwarder; confirm directory service access auditing is enabled and that the audit policy is applied by GPO
Logon and account context	Identity of the account and session performing the query, needed to judge whether the activity fits the user's role	Windows security event collection with logon auditing enabled; confirm the events are correlated with process and network records by host and time

How to write detection logic for T1615 without false alarms

T1615 Group Policy Discovery is hard to alert on because administrators, backup agents and compliance scanners read the same policy objects that an intruder would. The cards below pair each detection idea with its tuning thresholds and the benign sources that will flood it if left unchecked, so every rule starts from a baseline your environment has already measured.

Endpoint process and command logic

Start with process creation and command execution events on Windows hosts that run policy query utilities, scripts or PowerShell cmdlets that enumerate Group Policy Objects and their links. The key question is whether the parent process and the user context match a known management workflow. Tune by allow-listing signed management binaries from known paths and by alerting when the same process runs from a user profile or temporary directory. False positive sources include backup agents, inventory tools, management consoles and administrators troubleshooting policy application on their own workstations. Confirm the list of approved tools with your Windows administration team before enabling the rule.

Directory queries from non-administrative hosts

Directory query telemetry from the domain controller side, or network traffic content for LDAP and SMB sessions, shows which hosts request policy containers. A workstation that is not used for administration and that reads policy objects across many containers deserves review. Tune by building a per-host baseline over a window of normal operation, then flag hosts whose query set falls outside their role. Expect false positives from endpoint management agents, vulnerability scanners and compliance tools that query policy to report configuration state. Ask your directory team which service accounts and hosts are expected to read policy, and record that list as the allow-list source.

Policy read volume per account

A single account reading many policy objects in a short window is a stronger signal than one query, because enumeration produces repetition. Count distinct policy reads per account over a rolling window and alert when the count exceeds the account's own historical range. Tune the window and threshold against measured behavior rather than a published number, since no supplied figure exists for a safe threshold in your estate. False positives come from scheduled compliance scans, GPO reporting jobs and administrators preparing change reviews, all of which read many policies at predictable times. Suppress known schedules by time of day and service account name, and keep the suppression list under change control.

Correlation with logon and lateral activity

Discovery gains meaning when it follows a new logon or a remote session from an unusual source. Correlate policy read events with logon session creation and with remote administration activity on the same account within a short period. A policy read from an account that logged on minutes earlier from a host it rarely uses is a higher-priority lead than the read alone. Tune the correlation window and the list of rarely used source hosts with your identity team. False positives come from helpdesk sessions, jump host use and patch windows, so tag those hosts and accounts explicitly. Rehearse this correlation in a private cyber range before relying on it in production, so the join logic and time windows are tested against known benign and simulated activity.

Validating the T1615 detection in a lab before production

This sequence proves that the T1615 Group Policy Discovery detection fires on benign discovery activity in a private lab before it reaches production. It produces a tested rule set, measured alert timing, a list of missing telemetry and a coverage record tied to a named ATT&CK version.

Agree scope and rules of engagement
The security engineering lead, the Windows administrator and the owner of the cyber range agree in writing which hosts, accounts, log sources and time windows are in scope. They also set the rules of engagement: only benign discovery actions, no changes to domain policy objects, a named stop contact and a clear point at which the exercise is halted. Done means a signed scope sheet exists and every participant knows the stop procedure. Ask DeployOpen or your range provider to confirm which Windows domain controller and workstation images are available in the range before writing the scope.
Map benign actions to T1615 analytics
The detection engineer reviews the T1615 technique page and its linked detection strategies in the ATT&CK version the team targets, then selects a small set of read-only discovery actions that correspond to the analytics. Each action is recorded by its description and expected telemetry, not by a command line in shared documents. Done means each chosen action has a written expected signal in Process Creation, Command Execution or Network Traffic Content, and the list is approved by the team lead.
Prepare the test workstation and standard account
The range operator builds a test workstation joined to the lab domain with the same logging policy, forwarding agent and endpoint configuration used in production. A standard user account, without local administrator or domain privileges, is created to run the actions, so the test reflects the access level of a typical compromised user. Done means the operator confirms that the agent is reporting, the account is unprivileged and a baseline of normal activity has been captured for at least the test window agreed in step one.
Run the actions and record the evidence
The operator runs the approved actions from the test workstation under the standard account, following the written list in order. For each action, the observer records the UTC timestamp, source host, account name and the action identifier, in a shared log that is separate from the SIEM. Done means the run log has one entry per action, and any action that failed or was not executed is marked with the reason so the results are not misread later.
Check which rules fired and when
The detection engineer searches the SIEM, which may be Wazuh or another platform that receives Windows Security and Sysmon events, for alerts matching each action in the run log. For each rule, the engineer notes whether it fired, the delay between the action and the alert, and any duplicate or noisy hits. Done means a results table lists every action against the rule outcome and alert latency, and any unexplained gap is flagged for follow-up.
Identify missing telemetry
The engineer compares the events that should exist for each action with what the collector actually received, checking audit policy settings, Sysmon configuration, forwarding health and parsing. Missing fields, dropped events and misconfigured audit subcategories are logged as findings with an owner. Done means each gap has a named owner, a suspected cause and a retest date set by the team, rather than being left as a general note.
Tune the rule and record coverage
The team reviews false positives and misses with the Windows and SIEM owners, adjusts the rule logic or exclusions with a documented reason, and reruns the actions to confirm the change. The final coverage record names the ATT&CK version, the data components used, the rule identifiers, the test date, the range build and the open gaps. Done means the record is approved, stored with the detection content, and scheduled for review whenever ATT&CK releases change the T1615 mapping.

Preventive controls that limit Group Policy discovery

Group Policy discovery succeeds when any authenticated account can read directory objects and reach domain controllers freely. The mitigations ATT&CK maps to Discovery techniques address that exposure from several angles: account hygiene, network paths, audit visibility, system configuration and inspection of traffic. None of them removes the ability to read policy objects, which Active Directory allows by design, so each control is best judged by how much it narrows what a low-privilege account can reach.

User account management

ATT&CK mitigation M1018 covers controls over who holds accounts and what those accounts can do. For T1615, the question is whether standard user and service accounts can read GPO content beyond what they need, and whether dormant or over-scoped accounts can be used to enumerate policy. Review delegated rights on the Policies container and on GPO objects, remove unused accounts, and confirm that service accounts used for software deployment are not also used interactively. Ask your directory team to show the current delegation report rather than relying on the design document.

Network segmentation of domain controllers

ATT&CK mitigation M1030 limits which hosts can reach domain controllers over the protocols used for directory queries and SYSVOL access. If workstation subnets can reach every domain controller, any compromised endpoint can run policy enumeration from anywhere. Confirm that user segments only reach the domain controller ports they need, that server and management zones are separated, and that administrative paths are restricted. Test the rules from a workstation segment in your range, because firewall intent and firewall reality often differ.

Audit policy for directory access

ATT&CK mitigation M1047 is about producing the records that make T1615 visible. Enable auditing for directory service access and object access on the Policies container and on SYSVOL policy folders, and forward those events to your central log platform. Without these settings, a burst of reads against GPO objects leaves no trace for Wazuh or Security Onion to correlate. Verify the effective audit policy on each domain controller with your own tooling, since local and domain-applied settings can disagree.

Operating system configuration

ATT&CK mitigation M1028 covers hardening settings on Windows endpoints and servers that shape what local tools and scripts can do. Restrict the use of built-in scripting and management binaries for standard users through application control, and set PowerShell logging so that script block content is recorded. These settings do not block directory reads by themselves, but they raise the cost of running discovery from a workstation and improve the evidence available when it happens. Confirm the configuration with Group Policy results from a sample of standard workstations.

Network intrusion prevention rules

ATT&CK mitigation M1031 covers inspection and blocking of network traffic. Suricata or a comparable sensor can carry rules that flag unusual volumes of directory and SMB requests to domain controllers from a single non-administrative host, which is a pattern often seen during policy enumeration. Treat these as detection tuning first: many administrative tools generate the same traffic, so block only after baselining. Confirm the sensor sees traffic to domain controllers on your segmentation design, including east-west paths.

Triage steps when a T1615 alert fires

The first decision on a T1615 alert is whether the Group Policy queries came from an administrator, a management tool or an intruder. Start by identifying the account that ran the query, the host it ran from, and the parent process that launched the activity. An administrator using a console or a scheduled inventory job usually shows a known account, a known management workstation and a parent process that matches the approved tool. Check the time of day against the account's normal working pattern and compare the event with recent authentication history for that account, including failed logons, new logon types and sessions from unfamiliar addresses. Confirm with the owning team, through a change or ticket reference where one exists, before drawing a conclusion. Record each check in the case notes so the decision can be reviewed later.

If the activity cannot be explained by approved work, contain it in proportion to the risk. Options include restricting or disabling the account, isolating the source host from the network while keeping it powered on, and revoking active sessions or tokens for the account. Prefer the narrowest action that stops further reconnaissance, because a broad lockout can disrupt legitimate operations and destroy the context you need. Before changing anything, preserve evidence: export the relevant Windows Security and process creation logs, capture the host's volatile state under your incident response procedure, and keep copies of the Group Policy objects that were read. Escalate to the identity team early, since they can review directory audit logs, reset credentials and check whether any policy was changed. Document who approved each containment step and when.

Rehearsing T1615 detection in a private cyber range

This tab covers a private range with a domain controller, at least one monitored Windows endpoint and a standard user account with no administrative rights. The goal is to confirm that Group Policy discovery activity from a non-administrative host is recorded in process creation and command execution telemetry, forwarded to the SIEM, and mapped to the right analytics. Build the lab as a copy of your production logging configuration, not a simplified one, so that the rehearsal tests what you will actually see.

Logging baseline: Confirm that process creation auditing and command line capture are enabled on the endpoint and the domain controller, and that the agent forwards them without drops.
Account scope: Use a low-privilege test account so the rehearsal reflects an authenticated user with limited rights.
Telemetry checks: Verify that events from both hosts arrive in the SIEM with consistent timestamps and host names.
Analytic mapping: Record which ATT&CK version and detection strategy your rules target, and test each rule against the events it should match.
Success measure: Track time from activity to alert, and confirm that the alert names the host, account and parent process.

Check that the lab telemetry matches the production schema, because a rule that works only in the lab gives false confidence.

How the detection pieces connect across endpoint and network

The core idea is that no single source proves Group Policy discovery on its own, so the detection case is built by joining endpoint process telemetry, domain controller logs and network content around the same actor, host and time window. On a Windows endpoint, Process Creation and Command Execution records show that a process ran a Group Policy query utility or a PowerShell cmdlet that reads policy objects, and they name the account and parent process that started it. Those records are the trigger for the case. Domain controller logs then show whether the same account asked the directory for policy objects, linked GPOs or their settings, and whether that activity matches the endpoint event. Network Traffic Content, where your sensors can inspect directory protocol traffic, adds the remote side, such as which host reached which domain controller and what it requested. Correlating the three sources lowers false positives because routine administration, software deployment and management agents also read policy, but they rarely do so from an unexpected parent process, under an unexpected account, against a range of domain controllers the host normally never touches.

Each source has blind spots that the others partly cover. Endpoint telemetry cannot see directory queries made by a different machine or by a tool that talks to LDAP directly without spawning a process on the endpoint, so the host view can look clean while the activity is happening elsewhere. Domain controller logs record what the directory was asked, but they usually cannot tell you which process on which workstation made the request, and their audit depth depends on which subcategories your organization has enabled and whether the logs are forwarded off the controller. Network content can show the protocol exchange, but encrypted sessions, unusual ports and sensor placement limit what it reveals. Before relying on this case, confirm with your own environment which audit settings are active on domain controllers, whether the endpoint agent records command lines for the tools in scope, and where network sensors sit relative to domain controller traffic.

For the cyber range, build the exercise so that a single controlled query produces evidence in all three sources, then check that the Wazuh or Security Onion alert fires only when the endpoint and directory events line up. Record the time skew between sources, because a correlation window that is too tight will miss events and one that is too loose will attach unrelated activity to the case. Document the baseline of legitimate policy reads from your administrative workstations and management servers first, so the team knows which parent processes and accounts to expect. Decide in advance who owns the alert when only one source fires, and what the triage step is for that single-source case. Map the final rule and its correlation logic to the ATT&CK version you target, since detection mappings can change between releases. Keep the cyber range and production rules separate, and treat any tuning decision as a change that needs a written record and a retest.

Questions SOC leads ask about detecting Group Policy discovery

How do I separate routine admin GPO work from Group Policy discovery?

Separate them by context, not by the query alone: who ran the activity, from which host, at what time, and whether it matches a change ticket or a known administrative workflow. Routine GPO management usually comes from a small set of named administrator accounts working from privileged access workstations during change windows. Discovery tends to come from accounts that do not normally touch GPOs, from workstations or service hosts, or in bursts that enumerate many policy objects in a short period. Build an allowlist of approved administrative accounts and hosts, then alert on exceptions and review them with the change calendar. Confirm with your own administrators which tools they use, because that baseline is specific to your environment and cannot be taken from a generic template.

Which Windows logs must be enabled on domain controllers to detect T1615?

At minimum, you need process creation events with command line capture, so that the names and arguments of GPO-related tools are recorded. Confirm that the process creation auditing policy is enabled on domain controllers and administrative hosts, and that command line logging is included in the event data. Directory service access auditing on the relevant GPO objects adds visibility into who read or changed policy. Forward these events to your SIEM or Wazuh manager and check that the Windows event channels are not truncated by log size limits. Map each log source to the ATT&CK data components referenced for this technique, and verify coverage on a test domain controller before relying on it in production. The exact event IDs and audit subcategories depend on your Windows version, so confirm them against Microsoft documentation for your build.

Can Security Onion or Zeek help with Group Policy discovery detection?

Network telemetry can support T1615 detection, but it rarely identifies the activity on its own. Zeek logs and Suricata alerts can show authenticated SMB or RPC sessions from unusual sources to domain controllers, which is a useful corroborating signal. Network Traffic Content is the relevant data component, so content inspection of the protocols used to query directory and policy data is where these tools add value. Expect encrypted or tunneled traffic to limit what you see, and test whether your sensors capture east-west traffic to domain controllers at all. Use network detections to add context to host-based alerts rather than as a standalone rule. Confirm the protocol fields your Zeek version exposes before writing any detection that depends on them.

How often should I re-validate T1615 detections after an ATT&CK release?

Re-validate whenever the ATT&CK version your rules target changes, and check the release notes for any change to this technique, its data components or its detection guidance. ATT&CK releases can rename, deprecate or revoke techniques, and v18 replaced technique-level detections with detection strategies and analytics, so mappings written against older versions may need rework. Record the ATT&CK version in each rule's metadata, and schedule a review after each release you adopt. Between releases, re-run your validation tests after any change to logging configuration, SIEM parsing or Windows builds on domain controllers. The release cadence and review effort depend on your own change process, so agree the trigger points with your detection engineering team.

How do I measure detection coverage for Group Policy discovery?

Measure coverage by testing, not by counting rules. Start with a list of the data sources and analytics that should fire for T1615, then record which of them are enabled, forwarded and parsed on each domain controller and administrative host. Next, run controlled exercises in a private cyber range and record whether each expected alert fired, how long it took to reach the analyst queue, and which fields were populated. Track the results per ATT&CK version and per environment, and keep the evidence in a versioned repository. Coverage gaps usually appear in log forwarding, field parsing and allowlist drift rather than in rule logic. Ask any partner to show the measurement method and the evidence format before agreeing the scope in writing.

What is the difference between T1615 and related permission or account discovery?

T1615 covers enumeration of Group Policy objects and their settings, while account and permission discovery techniques focus on users, groups and their memberships. The two often appear together during reconnaissance, so an analyst may see both in the same session. Keep the detection logic separate so that each alert states which object type was queried, and correlate them only in the SIEM. This separation also makes it easier to tune allowlists, because approved administrative workflows for policy and for accounts differ. Review the sibling discovery techniques in your ATT&CK coverage matrix to avoid gaps at their boundaries.

Can we rehearse T1615 detection ourselves, or do we need outside help?

Your team can rehearse detection internally if it has a lab domain, the logging described above, and people who can run and document controlled exercises. Outside help is most useful for designing the exercise scope, building an isolated range that mirrors your domain controller configuration, and producing evidence in a form auditors can review. DeployOpen runs private cyber ranges and security testing, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask any provider to define the test cases, the expected telemetry, the success criteria and the handling of production-like data before the exercise begins.

Official ATT&CK sources for T1615 and Discovery

Start with the primary MITRE sources before you write any detection logic for T1615 Group Policy Discovery. The first is the MITRE ATT&CK tactic page for Discovery, which defines the tactic as TA0007 and frames its goal as an adversary trying to figure out your environment. Read it to confirm which techniques sit under Discovery and to understand the intent your detections must cover. Group Policy Discovery is one of the techniques listed there, so the tactic page is the right place to check the current technique name, description and any sub-technique structure before you map your rules.

Next, review the ATT&CK updates page, which lists each release and what changed. This matters for T1615 because ATT&CK v18 replaced technique-level detections with detection strategies, analytics and data components (DC IDs), and deprecated data sources. Confirm which ATT&CK version your detection library targets, then check the release notes for that version and any later releases before relying on a mapping. Record the version in every Sigma rule or detection document so that later renames, deprecations or revocations can be traced to your own content.

The enterprise-attack 20.0 STIX bundle, published in the mitre-attack/attack-stix-data repository, is the machine-readable source for the technique. Open it to see the data components that ATT&CK associates with T1615, the mitigations mapped to it and the relationships to related techniques. Your team can parse it into a mapping sheet that links each detection to a data component and a mitigation. Confirm the bundle's technique entry and its detection guidance against the version your SIEM content targets, and ask your implementation partner to include that check in the written scope.

How DeployOpen builds T1615 detections and range exercises

DeployOpen approaches T1615 Group Policy discovery as a fixed-scope piece of work inside your own environment, with detection logic, telemetry checks and cyber range rehearsals agreed in writing before any build starts. The output is a detection set your team can run, test and maintain under your own change control.

How we scope

Confirm which Windows domains, Group Policy sources and telemetry pipelines the written scope covers for T1615.
Record the ATT&CK version the detection mappings target, since releases can rename or revise techniques.
Agree which data components, such as Process Creation and Command Execution, are in place and which need collection work.

How we build

Write detection logic in Sigma or the rule format of your SIEM, mapped to the T1615 technique and its data components.
Deploy and tune the rules in your open-source stack, such as Wazuh or Security Onion, against your own baseline of administrative activity.
Test each rule against controlled activity in a private cyber range before it reaches production, and record what fired and what did not.

How we hand over

Deliver rule documentation covering logic, required fields, known false positives and the response steps your analysts follow.
Provide the range exercise runbook so your team can repeat the rehearsal and compare results after each change.
Walk through validation evidence with your security engineers and agree the handover acceptance criteria in writing.

How we support

Engagements are fixed-scope, so changes after handover are scoped and quoted separately from the original work.
Ongoing support, rule upgrades and repeated range testing are available as a retainer if your team wants continuity.
Ask any provider to confirm how they will handle ATT&CK version changes and revalidation of existing rules.

T1615 Group Policy discovery