AN1589: Analytic 1589
Creation of inbox rules via PowerShell (New-InboxRule) or transport rules using Exchange cmdlets. Correlates user behavior, cmdlet usage, and rule properties.
Analyst context for executives and security teams
This analytic is about spotting Exchange inbox or transport rule creation through PowerShell cmdlets such as New-InboxRule. For leaders, the practical issue is not the rule itself; it is whether the organization can see and explain changes that may affect mail flow, message visibility, or user mailbox behavior. Because email rules can materially influence investigations, retention expectations, and user communications, teams should validate that Exchange administrative activity and mailbox-rule changes are logged, retained, and reviewed.
Executive priority
Prioritize this where email is a critical business process and where auditability of mailbox or transport-rule changes matters for incident response, compliance evidence, and operational resilience. Security leaders should ask whether SOC and messaging administrators have a shared process to review unusual rule creation, whether logs are retained long enough for investigations, and whether privileged or user-driven Exchange changes can be traced to an accountable identity.
Technical view
The supplied ATT&CK object defines a Windows-relevant detection analytic for creation of inbox rules via PowerShell New-InboxRule or transport rules using Exchange cmdlets, correlating user behavior, cmdlet usage, and rule properties. SOC and detection engineering teams should validate visibility into Exchange PowerShell/cmdlet execution, rule creation events, the initiating user, target mailbox or transport scope, and rule attributes. Because no official detection logic or relationship context is supplied, local baselining is required to distinguish routine administration from unusual rule creation.
Likely telemetry
- Exchange administrative audit logs or equivalent cmdlet audit records
- PowerShell activity involving Exchange cmdlets, including New-InboxRule where available
- Mailbox inbox rule creation or modification records
- Transport rule creation or modification records
- User identity, authentication, and administrative session context associated with the cmdlet
Detection direction
- Confirm that Exchange cmdlet activity is logged with user, timestamp, source context, cmdlet name, and parameters sufficient to reconstruct rule creation.
- Alert or review creation of inbox and transport rules that are unusual for the user, mailbox, administrator, or business unit.
- Correlate cmdlet usage with user behavior and rule properties, as described by the analytic, rather than relying only on a single command name.
- Tune for expected administrative activity to reduce false positives, especially in environments where messaging teams legitimately create or modify transport rules.
- Identify blind spots where mailbox rules can be created outside monitored PowerShell paths or where rule parameters are not captured in retained logs.
Mitigation priorities
- Ensure Exchange administrative and mailbox-rule auditing is enabled and retained for incident response and compliance needs.
- Restrict Exchange administrative privileges to approved roles and review who can create inbox or transport rules at scale.
- Establish change-management expectations for transport rules and privileged mailbox-rule administration.
- Periodically review existing inbox and transport rules for business justification, ownership, and risky properties.
- Document response procedures for suspicious rule creation, including preservation of relevant Exchange, PowerShell, and identity logs.
Analyst notes and limits
This object is a detection analytic, not a technique description. It provides a concise behavioral focus: Exchange inbox or transport rule creation through PowerShell/Exchange cmdlets, correlated with user behavior and rule properties. No ATT&CK relationships, tactics, aliases, labels, or detailed detection pseudocode were supplied, so the take emphasizes validation of telemetry and operational process rather than specific detection content.
The official detection field is not provided, and no relationship context is supplied. The object lists Windows as the platform but does not specify tactics or linked techniques. Any assessment of exposure, maliciousness, prevalence, or coverage requires local Exchange, identity, PowerShell, and audit-log evidence.
Analytic 1589
Creation of inbox rules via PowerShell (New-InboxRule) or transport rules using Exchange cmdlets. Correlates user behavior, cmdlet usage, and rule properties.
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 | 0f27655e47b9… |
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 AN1589Open 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.