T1137.005: Outlook Rules
Adversaries may abuse Microsoft Outlook rules to obtain persistence on a compromised system. Outlook rules allow a user to define automated behavior to manage email messages. A benign rule might, for example, automatically move an email to a particular folder in Outlook if it contains specific words from a specific sender. Malicious Outlook rules can be created that can trigger code execution when an adversary sends a specifically crafted email to that user.[1]
Once malicious rules have been added to the user’s mailbox, they will be loaded when Outlook is started. Malicious rules will execute when an adversary sends a specifically crafted email to the user.[1]
Analyst context for executives and security teams
Outlook Rules matters because it turns a normal mailbox automation feature into a persistence mechanism. If a user’s Outlook mailbox has been modified after compromise, the adversary may be able to trigger code execution later by sending a crafted email, with execution occurring when Outlook starts and the malicious rule condition is met. For leaders, the key issue is not only endpoint compromise; it is whether email, identity, and endpoint teams can prove that mailbox rules are governed, monitored, and remediated.
Executive priority
Prioritize this where Microsoft Outlook and Exchange/Office Suite usage is material to business operations. The control question is whether the organization can inventory and investigate suspicious or hidden mailbox rules, correlate them with endpoint behavior, and remove them during incident response. This is relevant to operational resilience and audit evidence because mailbox-level persistence can survive simple endpoint cleanup if responders do not examine user mailbox configuration.
Technical view
This is a Windows and Office Suite persistence sub-technique under Office Application Startup. SOC and IR teams should validate detection strategy DET0095 for malicious Outlook rules and confirm that investigations include both mailbox rule state and endpoint activity around Outlook startup. The related software Ruler demonstrates that abuse of Exchange services for this behavior is documented in ATT&CK, and the external references include Microsoft guidance for detecting/remediating Outlook rules and custom forms attacks plus defensive tooling context such as NotRuler. Because ATT&CK provides no official detection text for this object, local detection engineering should be based on mailbox rule auditing, Exchange/Office 365 administrative logs, and endpoint process telemetry tied to Outlook execution.
Likely telemetry
- Mailbox rule creation, modification, and deletion events
- Exchange or Office 365 administrative and audit logs
- Outlook client startup and process execution telemetry on Windows endpoints
- Endpoint behavior prevention or EDR alerts involving Outlook-spawned activity
- Incident response mailbox configuration exports or rule inventories
Detection direction
- Validate DET0095 coverage for suspicious Outlook rule persistence rather than assuming generic email security monitoring will see it.
- Baseline legitimate mailbox automation patterns so unusual rule actions, hidden rules, or rule changes after suspicious account activity can be reviewed with fewer false positives.
- Correlate mailbox rule changes with Outlook startup and downstream endpoint behavior, since the technique depends on malicious rules being loaded and triggered in Outlook.
- Include Exchange/Office Suite logging in SOC playbooks; endpoint-only detection may miss the persistence location inside the mailbox.
- Use the Ruler/NotRuler relationship as context for testing defensive visibility, without treating tool-specific indicators as complete coverage.
Mitigation priorities
- Apply behavior prevention on endpoints to detect and block suspicious process behavior associated with Outlook-triggered execution.
- Maintain current software updates for Windows and Office Suite components to reduce exposure to known weaknesses and improve defensive control reliability.
- Implement incident response procedures that inspect and remove suspicious Outlook mailbox rules during account or endpoint compromise investigations.
- Ensure administrators can audit mailbox rule changes and preserve evidence for compliance and post-incident review.
- Coordinate email, identity, endpoint, and SOC teams so mailbox persistence is not left behind after password resets or endpoint remediation.
Analyst notes and limits
ATT&CK identifies this as a persistence sub-technique for Windows and Office Suite involving Microsoft Outlook rules. The most important defensive decision is whether mailbox configuration telemetry is actually available to the SOC and IR teams, because the persistence mechanism is not just a file or process on the endpoint. Relationship context supports DET0095 as a detection strategy and M1040/M1051 as mitigation directions.
The official ATT&CK object does not provide detection text, and the supplied relationships do not include detailed analytics or log source requirements. This take does not assert active exploitation, specific adversary attribution, or guaranteed detection. Organizations need local evidence from Exchange/Office 365 auditing, endpoint telemetry, and mailbox rule inventories to determine exposure and coverage.
Outlook Rules
Adversaries may abuse Microsoft Outlook rules to obtain persistence on a compromised system. Outlook rules allow a user to define automated behavior to manage email messages. A benign rule might, for example, automatically move an email to a particular folder in Outlook if it contains specific words from a specific sender. Malicious Outlook rules can be created that can trigger code execution when an adversary sends a specifically crafted email to that user.[1]
Once malicious rules have been added to the user’s mailbox, they will be loaded when Outlook is started. Malicious rules will execute when an adversary sends a specifically crafted email to the user.[1]
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.
Related techniques
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 | T1137 | Office Application Startup | This object subtechnique of Office Application Startup. |
Groups, software, and campaigns
S0358: Ruler
All related ATT&CK context
Mitigation direction
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.2 | Current bundle | ff791a66d532… |
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]
SilentBreak Outlook Rules
Landers, N. (2015, December 4). Malicious Outlook Rules. Retrieved February 4, 2019.
Open source URL -
[2]
Microsoft Detect Outlook Forms
Fox, C., Vangel, D. (2018, April 22). Detect and Remediate Outlook Rules and Custom Forms Injections Attacks in Office 365. Retrieved February 4, 2019.
Open source URL -
[3]
Pfammatter - Hidden Inbox Rules
Damian Pfammatter. (2018, September 17). Hidden Inbox Rules in Microsoft Exchange. Retrieved October 12, 2021.
Open source URL -
[4]
SensePost NotRuler
SensePost. (2017, September 21). NotRuler - The opposite of Ruler, provides blue teams with the ability to detect Ruler usage against Exchange. Retrieved February 4, 2019.
Open source URL -
[5]
mitre-attack T1137.005Open 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.