AN0846: Analytic 0846
Adversary enumeration of local user accounts using Net.exe, WMI, or PowerShell.
Analyst context for executives and security teams
This analytic concerns attempts to enumerate local Windows user accounts using built-in administration interfaces such as Net.exe, WMI, or PowerShell. For leaders, the practical issue is visibility: local account discovery can help an intruder understand where privileges, dormant users, or reusable credentials may exist before expanding access. Even without a supplied ATT&CK tactic or detection logic, this is a useful coverage checkpoint for Windows endpoint monitoring and incident triage.
Executive priority
Prioritize this as a Windows visibility and identity hygiene question rather than a standalone high-confidence incident signal. Security leaders should ask whether SOC teams can reliably show when local accounts are queried, whether privileged or dormant local accounts are governed, and whether this evidence supports incident response and audit needs. The value is in confirming that common built-in tools do not create a blind spot in account discovery monitoring.
Technical view
Validate monitoring for Windows execution and command activity involving Net.exe, WMI, and PowerShell when used to enumerate local user accounts. Because the object provides no official detection logic and no tactic mapping, teams should treat this as a detection engineering prompt: define expected administrative baselines, identify suspicious contexts, and correlate with surrounding endpoint, authentication, and privilege activity before escalating.
Likely telemetry
- Windows process creation telemetry, including command line arguments where available
- PowerShell execution telemetry and script or command logging where enabled
- WMI activity telemetry, including process creation or management queries where available
- Endpoint detection and response events for built-in Windows administrative tools
- Local account and authentication-related Windows security events where collected
Detection direction
- Confirm that Net.exe, WMI, and PowerShell activity is visible on Windows endpoints, not just blocked or summarized by tooling.
- Baseline legitimate administrative enumeration by IT operations, help desk tooling, management platforms, and scripts to reduce false positives.
- Prioritize detections where local user enumeration appears in unusual user, host, time, or execution-chain contexts.
- Correlate account enumeration with nearby indicators such as new process execution, privilege changes, authentication attempts, or access to additional systems.
- Document gaps explicitly because the ATT&CK object does not provide official detection logic or relationship context.
Mitigation priorities
- Strengthen governance of local Windows accounts, especially privileged, stale, shared, or unmanaged accounts.
- Limit unnecessary administrative access that would make local account enumeration more useful to an intruder.
- Ensure endpoint logging policies capture process, PowerShell, and WMI activity needed for investigation.
- Review operational scripts and management tools so legitimate enumeration is understood and auditable.
- Use findings from detection validation to support identity hygiene, incident response readiness, and compliance evidence.
Analyst notes and limits
This is a detection analytic object for Windows focused on adversary enumeration of local user accounts using Net.exe, WMI, or PowerShell. No official detection text, tactics, aliases, labels, or relationships were supplied, so conclusions should remain focused on defensive validation rather than inferred attacker objectives.
The supplied ATT&CK fields are sparse. There is no official detection logic, no related techniques or groups, and no tactic mapping. Local environment baselines are required to distinguish authorized administration from suspicious enumeration.
Analytic 0846
Adversary enumeration of local user accounts using Net.exe, WMI, or PowerShell.
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 | 490c5e18a728… |
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 AN0846Open 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.