AN1052: Analytic 1052
Execution of PowerShell commands that modify mailbox permissions using Exchange cmdlets (e.g., Add-MailboxPermission), often tied to BEC or post-compromise persistence.
Analyst context for executives and security teams
This analytic concerns PowerShell use on Windows to change Exchange mailbox permissions, such as through Add-MailboxPermission. For leaders, the practical issue is not just command execution; unauthorized mailbox permission changes can create durable access to sensitive communications and may be relevant to business email compromise or post-compromise persistence, as noted by MITRE.
Executive priority
Prioritize this as an identity and email-security governance question: who can change mailbox permissions, how quickly would the organization notice, and what evidence would support an investigation or audit? It matters for incident response readiness, compliance evidence around privileged access, and business continuity because mailbox access can expose executive, finance, legal, and operational communications.
Technical view
SOC and IR teams should validate whether Windows PowerShell activity that invokes Exchange mailbox-permission cmdlets is logged and correlated with Exchange permission-change records. Because ATT&CK provides no official detection logic for this analytic, teams should build environment-specific baselines for legitimate Exchange administration and alert on unusual permission changes, unusual administrators, unusual target mailboxes, or command execution patterns inconsistent with approved operations.
Likely telemetry
- Windows PowerShell command, script block, or module logging where enabled
- Process creation telemetry showing PowerShell command-line execution
- Exchange administrative audit logs or equivalent records for mailbox permission changes
- Mailbox permission change events identifying actor, target mailbox, permission granted, and timestamp
- Identity and administrative sign-in records associated with the account making the change
Detection direction
- Confirm that PowerShell logging is enabled and retained on Windows systems used for Exchange administration.
- Confirm that Exchange mailbox permission changes are logged with enough detail to identify the actor, target mailbox, and permission granted.
- Tune detections against known administrative workflows to reduce false positives from legitimate helpdesk or Exchange administration.
- Prioritize alerts involving sensitive mailboxes, newly privileged accounts, unexpected administrators, or permission changes outside approved change windows.
- Account for the blind spot that ATT&CK provides no official detection text or relationship context for this analytic; local baselines and log availability will decide detection quality.
Mitigation priorities
- Limit who can modify mailbox permissions using least-privilege administrative roles.
- Require strong authentication and governance for accounts authorized to administer Exchange mailboxes.
- Review mailbox permissions regularly, especially for executive, finance, legal, and shared mailboxes.
- Maintain change-management evidence for authorized mailbox permission updates.
- Ensure incident response playbooks include review and rollback of suspicious mailbox permission changes.
Analyst notes and limits
The object is a detection analytic for Windows PowerShell execution of Exchange cmdlets that modify mailbox permissions. MITRE explicitly notes association with BEC or post-compromise persistence, but no relationships, tactics, or official detection logic were supplied. Treat this as a coverage-validation prompt rather than a complete detection specification.
This take is based only on the supplied ATT&CK analytic fields and external reference. No active exploitation, actor attribution, confirmed detection coverage, or environment exposure can be inferred. Local Exchange architecture, logging configuration, administrative processes, and identity controls are required to determine real risk and coverage.
Analytic 1052
Execution of PowerShell commands that modify mailbox permissions using Exchange cmdlets (e.g., Add-MailboxPermission), often tied to BEC or post-compromise persistence.
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 | e5d868875ddf… |
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 AN1052Open 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.