Almost everyone has an Outlook rule that moves newsletters into a folder. T1137.005, Outlook Rules, is the persistence sub-technique where a rule is made to do something else: run code. It applies to Windows and Office Suite.
How attackers use it
Outlook rules let a user define automated behavior for email. A harmless one moves a message to a folder when it contains certain words from a certain sender. MITRE says malicious rules can be created that trigger code execution when an adversary sends a specifically crafted email.
Once added to the mailbox, the rules load when Outlook starts, and they fire when the crafted message arrives. As with Outlook forms and the home page, the persistence sits in the mailbox, not on the workstation. MITRE names Ruler, and MFCMapi in its analytics, as tools that can create such rules.
How to detect it
MITRE gives two variants.
- Code execution on delivery. On email arrival, Outlook runs the rule and something starts, for example
mshta.exeor PowerShell. Outlook spawns a nonstandard child process, often unsanctioned, without any user interaction. - Disguised rules. The adversary adds a rule with modified or obfuscated
PR_RULE_MSG_NAMEandPR_RULE_MSG_PROVIDERattributes using MFCMapi or Ruler. The rule fires when an email arrives. Mailbox audit logs or the Unified Audit Log show an automated, rule-triggered action with no user interaction.
Two practical tracks follow. On the endpoint, alert on outlook.exe as the parent of mshta.exe, powershell.exe or cmd.exe (Sysmon event ID 1). In the mailbox, review rule creation in your audit logs and compare rules to what the user can explain.
How to reduce the risk
- Apply Microsoft's patches. Blocking macros may not help here, since the Visual Basic engine behind Outlook rules is separate from the macro scripting engine. MITRE points to KB3191938, which blocks Outlook Visual Basic and shows a malicious code warning.
- Block child processes. Use Attack Surface Reduction rules on Windows 10 to stop Office applications from creating child processes.
Check your own environment
For Exchange Online, list a mailbox's rules (read-only):
Get-InboxRule -Mailbox someone@yourcompany.com | Format-List Name, Enabled, Description
Look for rules with names the user does not recognize, rules with odd or blank names, and rules that mention running an application or script. Then confirm mailbox auditing is on so rule creation is logged.
Quick check
Which process relationship is the strongest endpoint signal?
outlook.exe starting a nonstandard child such as mshta.exe or PowerShell with no user action.
Sources
- MITRE ATT&CK, T1137.005 Outlook Rules
