DET0587: Enumeration of User or Account Information Across Platforms
This detection strategy is about finding attempts to enumerate users, accounts, usernames, or email addresses across environments. For leaders, the value i...
Analyst context for executives and security teams
This detection strategy is about finding attempts to enumerate users, accounts, usernames, or email addresses across environments. For leaders, the value is early warning: account discovery often helps an intruder decide which identities to target next for brute force, phishing, or account takeover. Even though the ATT&CK detection-strategy object does not provide detailed detection logic, its relationship to Account Discovery makes it a useful prompt to validate whether identity, cloud, Linux, and ESXi account-enumeration activity is visible to the SOC.
Executive priority
Prioritize this as an identity and resilience control question: can the organization prove it can see unusual account listing or lookup activity before it becomes credential misuse? This matters for incident triage, audit evidence around account monitoring, and prioritizing telemetry from identity providers, IaaS control planes, Linux systems, and ESXi where those platforms exist. The main business decision is whether discovery-stage identity behavior is monitored consistently enough to support rapid containment and credential-risk decisions.
Technical view
DET0587 detects T1087 Account Discovery. Because the official detection-strategy object has no supplied detection text and no explicit platforms, defenders should derive validation from the related technique context: discovery of valid accounts across ESXi, IaaS, identity providers, and Linux. SOC and detection teams should test whether normal administrative account queries are distinguishable from unusual enumeration patterns, especially after an account compromise or from unexpected hosts, users, service accounts, or cloud/API contexts. IR teams should treat confirmed enumeration as context for possible follow-on Valid Accounts activity, brute-force attempts, spear-phishing preparation, or account takeover investigation, without assuming those outcomes occurred.
Likely telemetry
- Identity provider audit logs for user, group, directory, and account lookup activity
- IaaS control-plane audit logs for identity, IAM, user, role, and account listing operations
- Linux authentication and command/process logs showing local or directory-backed account enumeration
- ESXi management and authentication logs where account listing or administrative discovery is observable
- Endpoint or server process execution telemetry for built-in account discovery commands
Detection direction
- Validate coverage against the related ATT&CK technique T1087 Account Discovery rather than relying on DET0587 content alone, because no official detection logic is supplied.
- Baseline legitimate administrative, help desk, automation, and inventory activity to reduce false positives from normal account lookups.
- Look for unusual volume, timing, source, user role, or cross-platform spread of account enumeration activity, especially from identities or hosts that do not normally perform directory or account administration.
- Correlate enumeration with prior suspicious access and later credential-focused behavior, while avoiding unsupported assumptions that follow-on compromise occurred.
- Check blind spots in identity provider, IaaS, Linux, and ESXi logging, particularly where audit logs are disabled, short-retained, or not forwarded to the SOC.
Mitigation priorities
- Ensure audit logging is enabled and retained for identity provider, IaaS, Linux, and ESXi account-management activity where those technologies are in scope.
- Limit account and directory enumeration privileges to roles with a clear business need, and review service accounts or automation with broad listing permissions.
- Use least privilege and administrative separation so ordinary users or compromised low-privilege accounts cannot easily enumerate high-value identity data.
- Document response playbooks for account discovery events, including identity review, session containment, credential reset decisions, and follow-on monitoring.
- Use compliance and control testing to prove that account discovery telemetry is collected, searchable, and tied to accountable identities.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy named Enumeration of User or Account Information Across Platforms and is related to T1087 Account Discovery. The decision value is in validating visibility around identity discovery behavior across the platforms named in the related technique, not in implementing a specific MITRE-provided analytic, because none is included in the supplied fields.
The official object fields provided contain no description, no detection text, no tactics, and no platforms for DET0587 itself. Platform and tactic context comes only from the relationship to T1087 Account Discovery. Local logging architecture, identity provider features, IaaS provider configuration, and normal administrative patterns are required to turn this into reliable detections.
Enumeration of User or Account Information Across Platforms
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1087 | Account Discovery | This object detects Account Discovery. |
All related ATT&CK context
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 | fd9ea6821622… |
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 DET0587Open 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.