AN1025: Analytic 1025
Detection of domain group enumeration through command-line utilities such as 'net group /domain' or PowerShell cmdlets, followed by suspicious access to API calls or LSASS memory.
Analyst context for executives and security teams
This analytic matters because domain group enumeration can be an early warning that an actor is mapping privileged access paths before moving deeper in a Windows environment. The described behavior combines command-line discovery, such as domain group queries, with later suspicious access to APIs or LSASS memory, making it relevant to identity risk, SOC triage, and incident response scoping.
Executive priority
Treat this as a validation point for identity and endpoint monitoring readiness. Leaders should ask whether the organization can reliably see Windows command-line group enumeration, correlate it with sensitive process or memory access, and preserve that evidence for investigation and audit needs. Priority is higher in environments where domain groups govern administrative access or critical business systems.
Technical view
For Windows endpoints, validate visibility into command-line utilities and PowerShell activity that enumerate domain groups, then correlate that activity with suspicious access to API calls or LSASS memory. Because no ATT&CK tactic or formal detection logic is supplied, detection engineering should focus on behavioral correlation rather than a single command string. IR teams should use this pattern to decide whether observed enumeration is benign administration, authorized troubleshooting, or part of a broader identity discovery and credential-access concern.
Likely telemetry
- Windows process creation events with full command line
- PowerShell execution and script/block logging where available
- Endpoint telemetry showing process access to LSASS memory
- Endpoint telemetry for suspicious API access patterns
- User, host, and parent-child process context for command execution
Detection direction
- Confirm that command-line arguments are captured for Windows process execution, not just process names.
- Tune for domain group enumeration patterns such as net group /domain and relevant PowerShell cmdlets, while accounting for legitimate administrative scripts.
- Correlate enumeration with subsequent suspicious LSASS memory or API access rather than alerting only on discovery commands.
- Baseline expected administrators, management servers, and automation accounts to reduce false positives.
- Review alert gaps where PowerShell logging, endpoint process telemetry, or LSASS access visibility is absent.
Mitigation priorities
- Prioritize least-privilege review of domain groups that grant administrative or sensitive access.
- Limit and monitor who can perform privileged administration from Windows endpoints.
- Harden endpoint visibility and logging for command-line, PowerShell, and sensitive process access evidence.
- Use incident response playbooks that escalate when group enumeration is followed by suspicious LSASS or API access.
- Maintain audit-ready evidence that identity discovery and sensitive process access monitoring are enabled and reviewed.
Analyst notes and limits
This is a detection analytic object for Windows in the enterprise ATT&CK domain. The official description is the primary source: domain group enumeration via command-line utilities or PowerShell followed by suspicious API or LSASS memory access. No tactic, relationship context, aliases, or official detection logic were provided.
The supplied object does not include a formal detection query, data source list, ATT&CK technique relationships, or tactic mapping. Local validation is required to determine whether the behavior is visible, how often legitimate administrators trigger it, and what correlation window is appropriate.
Analytic 1025
Detection of domain group enumeration through command-line utilities such as 'net group /domain' or PowerShell cmdlets, followed by suspicious access to API calls or LSASS memory.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 41e29e7a648d… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1025Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.