AN1087: Analytic 1087
Enumeration of identity roles and users via API calls such as `Get-MsolRoleMember`, `az ad user list`, or Graph API tokens from unauthorized users or automation accounts.
Analyst context for executives and security teams
AN1087 focuses on detecting suspicious enumeration of identity-provider users and roles through API calls. For executives and security leaders, the practical issue is that role and user discovery can give an intruder or misused automation account a map of privileged identities, administrative groups, and possible targets before more damaging activity occurs.
Executive priority
Prioritize this analytic where cloud identity or centralized identity-provider accounts control access to business-critical systems. Leaders should ask whether identity audit logs are retained, whether automation accounts are governed, and whether the SOC can distinguish approved administrative inventory activity from unauthorized role and user enumeration. This is relevant to incident readiness, identity governance evidence, and control assurance, especially where privileged roles are material to business continuity.
Technical view
The supplied ATT&CK object applies to the Identity Provider platform and describes enumeration of identity roles and users through API calls such as Get-MsolRoleMember, az ad user list, or Graph API token usage by unauthorized users or automation accounts. Because no official detection logic or tactic mapping is provided, teams should validate their own identity-provider logging, API audit visibility, account context, and baselines for legitimate administrative enumeration before operationalizing alerts.
Likely telemetry
- Identity provider audit logs for role membership and user listing operations
- API activity logs showing caller identity, application or automation account, source, timestamp, and request type
- Authentication and token usage records associated with Graph API or similar identity APIs
- Administrative role assignment and membership change context
- Service account and automation account inventory with approved use cases
Detection direction
- Baseline expected identity inventory and role-review activity by administrators, security tools, and automation accounts.
- Alert or investigate user and role enumeration by accounts without an approved administrative or automation purpose.
- Correlate enumeration activity with authentication context such as unusual account, token, source location, or timing where available.
- Tune carefully for false positives from legitimate governance, compliance, directory synchronization, and security inventory workflows.
- Document blind spots where API audit logs, token context, or automation account ownership are missing.
Mitigation priorities
- Maintain an inventory of authorized identity administration and automation accounts.
- Apply least privilege to accounts that can enumerate users, groups, and role memberships where supported by the identity provider.
- Review and govern automation accounts, including ownership, purpose, and logging requirements.
- Ensure identity-provider API audit logging is enabled, retained, and available to SOC and incident response workflows.
- Use periodic access reviews to validate privileged role membership and reduce unnecessary visibility into sensitive identity structures.
Analyst notes and limits
This object is a detection analytic, not a technique entry. The available description is narrow and identity-focused, with examples of API-based role and user enumeration. The most useful implementation work is local validation: which accounts are expected to perform this activity, what logs prove it, and how quickly the SOC can determine whether the caller was authorized.
No official detection text, tactics, relationships, aliases, or labels were supplied. The take therefore avoids claims about adversary attribution, active exploitation, impact, or guaranteed detection coverage. Local identity-provider capabilities and logging configuration will determine practical coverage.
Analytic 1087
Enumeration of identity roles and users via API calls such as `Get-MsolRoleMember`, `az ad user list`, or Graph API tokens from unauthorized users or automation accounts.
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 | 9e8901e0d56b… |
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 AN1087Open 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.