Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1612: Analytic 1612

Detection of processes performing local or domain account enumeration by invoking account directory queries or security APIs followed by structured output of account lists. The defender observes command execution or API invocation patterns that retrieve account information and produce enumeration artifacts shortly afterward.

EnterpriseAN1612AnalyticObject v1.1 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

AN1612 describes a Windows-focused detection analytic for spotting local or domain account enumeration: processes that query account directories or security APIs and then produce structured lists of accounts. For leaders, this matters because account discovery is often a precursor to broader identity abuse, but the value of this analytic depends on whether the organization can see both the query behavior and the resulting enumeration artifacts.

Executive priority

Prioritize this as an identity and SOC readiness validation item rather than a standalone assurance control. Security leaders should ask whether Windows endpoint and directory telemetry can prove when accounts are being enumerated, whether normal administrative inventory activity is baselined, and whether incident responders can quickly distinguish approved account discovery from suspicious activity. This also supports audit and compliance evidence around monitoring privileged identity exposure and directory visibility.

Technical view

For Windows environments, validate whether telemetry can identify processes invoking local or domain account queries or security APIs and correlate those events with structured account-list output shortly afterward. Because no specific tactic, relationship context, or official detection logic is supplied, detection engineering should treat AN1612 as a behavioral pattern: account information retrieval plus observable enumeration artifacts. Tune against known administrative tools, inventory scripts, IAM operations, and helpdesk workflows before escalating alerts.

Likely telemetry

  • Windows process creation events with command line and parent/child process context
  • Endpoint detection telemetry showing security API or account directory query activity
  • Directory service or domain controller logs that can evidence account lookups where available
  • Script execution logs, such as Windows scripting or PowerShell telemetry, when used for account queries
  • File creation or output artifacts containing structured account lists

Detection direction

  • Correlate account query behavior with subsequent creation or display of structured account lists rather than alerting on account lookup alone.
  • Baseline expected account enumeration from administrators, IAM tooling, asset inventory, compliance scans, and support scripts to reduce false positives.
  • Validate visibility on both local account enumeration and domain account enumeration paths on Windows systems.
  • Check whether EDR or Windows logging captures API-level or command-level evidence; many environments may only see one side of the behavior.
  • Use host, user privilege, parent process, execution location, and timing to prioritize unusual enumeration patterns for SOC review.

Mitigation priorities

  • Ensure Windows endpoint and directory logging is enabled and retained long enough to support investigation.
  • Apply least-privilege administration and review who or what can perform broad account discovery where permissions are configurable.
  • Maintain an approved inventory of administrative scripts and tools that enumerate accounts so detections can be tuned safely.
  • Prepare IR triage steps for account enumeration alerts, including validating the initiating user, host, process, and resulting account list artifacts.
  • Use findings from this analytic to inform identity hardening, privileged access reviews, and monitoring coverage gaps.
Analyst notes and limits

This object is a detection analytic, not a full ATT&CK technique description. Its decision value is in testing whether defenders can observe account enumeration behavior on Windows and distinguish authorized directory/account inventory from suspicious discovery activity.

The supplied ATT&CK fields do not include official detection logic, tactics, related techniques, procedures, mitigations, or data source mappings. Conclusions should therefore be validated against local Windows logging, EDR capabilities, directory architecture, and approved administrative workflows.

Official MITRE ATT&CK definition

Analytic 1612

Detection of processes performing local or domain account enumeration by invoking account directory queries or security APIs followed by structured output of account lists. The defender observes command execution or API invocation patterns that retrieve account information and produce enumeration artifacts shortly afterward.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
f5c355286441b179...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle f5c355286441…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1612
    Open source URL
Source and licensing

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.