AN1089: Analytic 1089
Bulk enumeration of cloud user email identities through `Get-Recipient`, `Get-Mailbox`, `Get-User`, or Graph API directory listings by abnormal accounts or suspicious sessions.
Analyst context for executives and security teams
This analytic is about spotting unusual bulk enumeration of cloud email/user identities in an Office Suite environment. For leaders, the practical issue is that directory and mailbox enumeration can reveal who exists, which accounts are valuable, and how the organization is structured. Even without a confirmed intrusion, abnormal use of recipient, mailbox, user, or directory-listing queries should be treated as a signal to validate identity monitoring, session risk visibility, and cloud audit logging coverage.
Executive priority
Prioritize this as an identity and cloud visibility control check. Security leaders should ask whether the organization can prove who is performing large-scale user or mailbox lookups, from which sessions, and whether those sessions are expected. This supports incident triage, compliance evidence around administrative activity monitoring, and resilience planning because enumeration can precede broader misuse of cloud identities or mail resources.
Technical view
SOC and detection teams should validate monitoring for abnormal accounts or suspicious sessions using Office Suite audit evidence tied to bulk directory, recipient, mailbox, and user enumeration activity. The supplied object specifically references Get-Recipient, Get-Mailbox, Get-User, and Graph API directory listings. Since no official detection logic or tactic mapping is provided, teams should baseline expected administrative and automation activity, then tune for unusual volume, unusual account role, unexpected source/session context, or activity outside normal operational patterns.
Likely telemetry
- Office Suite audit logs for recipient, mailbox, user, and directory listing activity
- Administrative command activity involving Get-Recipient, Get-Mailbox, and Get-User
- Graph API directory listing activity logs
- User/session context such as account identity, source location, device/session indicators, and time of activity
- Volume and frequency metrics for directory or mailbox enumeration by account/session
Detection direction
- Confirm that cloud audit logging captures the referenced command and Graph API activity with enough detail to associate actions to accounts and sessions.
- Establish baselines for legitimate administrative, help desk, synchronization, discovery, and automation workflows to reduce false positives.
- Alert on abnormal bulk enumeration by accounts that do not normally perform directory or mailbox discovery, or by sessions with suspicious context.
- Review service accounts and automation separately; high-volume enumeration may be expected for some workflows but should still be attributable and approved.
- Because MITRE supplied no detection text or relationships, validate locally which events are available and how reliably command/API activity is normalized.
Mitigation priorities
- Ensure Office Suite audit logging and retention are enabled for administrative and directory activity relevant to this analytic.
- Limit directory and mailbox enumeration privileges to accounts with a documented business need.
- Review privileged and automation accounts that can perform recipient, mailbox, user, or directory listing activity.
- Use identity and session controls to investigate or constrain suspicious sessions performing unusual enumeration.
- Maintain incident response procedures for rapid review of account ownership, session validity, and downstream activity when abnormal enumeration is detected.
Analyst notes and limits
This is a detection analytic object, not a technique. It describes suspicious bulk enumeration of cloud user email identities in an Office Suite context, but provides no official detection logic and no relationship context. The strongest use is as a validation prompt for cloud identity logging, administrative activity baselining, and SOC triage workflows.
The source object does not specify ATT&CK tactics, related techniques, threat actors, mitigations, or a concrete detection query. Any severity, coverage, or exposure assessment requires local telemetry, account role context, session data, and approved administrative workflow knowledge.
Analytic 1089
Bulk enumeration of cloud user email identities through `Get-Recipient`, `Get-Mailbox`, `Get-User`, or Graph API directory listings by abnormal accounts or suspicious sessions.
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 | c48f42b3a803… |
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 AN1089Open 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.