Outlook Mailbox Forwarding Rule hidden (powershell, automatic replies)
Am I going crazy?! How to track down where/How an email is being forwarded?
byu/ShaneDoesIT inOffice365
We have an old user's account which is forwarding all emails to another staff member. I'm at the stage where I can simply delete the mailbox as it's no longer used however my curiosity can't let it go.
Places I've checked;
- Transport Rules
- Forwarding on the mailbox (Get-Mailbox <mailbox> | fl forward), checking Exchange online/365 portals. A. Also Get-Mailbox -Identity <mailbox> | select UserPrincipalName,ForwardingSmtpAddress,DeliverToMailboxAndForward
- Inbox rules (get-inboxrule -mailbox <mailbox> (also delegated in and checked rules manually)
- Performed Audit search on mailbox. No results.
I did an Extended message trace and combed through it and can't see anything overly useful except for Recipient Status: "UserMailbox.Forwardable.Resolver.CreateRecipientItems.40"
Searching for this, I can find some other similar posts online with no resolution;
1 - https://www.reddit.com/r/exchangeserver/comments/jfzd1u/strange_behavior/
2 - https://social.technet.microsoft.com/Forums/en-US/32614e7c-5c30-4f1e-9ecd-716ccb148d7b/email-being-redirected?forum=Exch2016GD
I'm stumped. Does anyone have anywhere else to check?
EDIT: Checking the email headers, there's some more clues;
- X-MS-Exchange-Inbox-Rules-Loop = Mailbox of user sending email
- X-MS-Exchange-Organization-MessageDirectionality = Originating
- Auto-Submitted = auto-generated
- X-MS-Exchange-Generated-Message-Source = Mailbox Rules Agent
EDIT#2 I've found it!
It was set via an Automatic Reply Rule....
- I would've assumed this forwarding rule should still show up in the above checks?!
- I created an external contact and added it to the rule and it still doesn't show as having a forwarding rule via Powershell?!
Find Exchange Online Mailbox Hidden Inbox Rules using PowerShell
How to find Exchange Online mailbox hidden Outlook inbox rules using PowerShell and show the contents of rules to check for suspicious actions.
Because suspicious inbox rules would raise the alarm that the mailbox has been compromised, attackers may create hidden inbox rules that are more difficult to detect. Hidden inbox rules do not show in the Outlook client or Outlook on the web.
Get Outlook hidden inbox rules using PowerShell Get-InboxRule
In this example, we can only see one rule
But when we run the PowerShell again with the -IncludeHidden option, we can see more rules
View details of hidden inbox rules - all properties
In this example, we can show the properties of the inbox rules to get more information about the content of the rules.
Show only certain inbox rule properties
In this example, we are selecting only the rule properties that show us what actions the rule contains. This way, we can check for any rules that could be forwarding to a suspicious external email address
Remove hidden Outlook inbox rules using PowerShell Remove-InboxRule
Copy the rule identity. You'll need this to delete the inbox rule
Remove Outlook inbox rules using PowerShell Remove-InboxRule
Remove one inbox rule using -Identity
Remove all inbox rules including hidden rules for a mailbox
Delete Outlook rules using /cleanrules
This command starts Outlook and deletes all client and server inbox rules
Outlook.exe /cleanrules
/cleanrules will delete all client-side and server-side rules from all mailboxes in your Outlook profile
You should only run /cleanrules when your Outlook profile contains just the target mailbox
References:
Exchange PowerShell - Get-InboxRule
https://docs.microsoft.com/en-us/powershell/module/exchange/get-inboxruleExchange PowerShell - Remove-InboxRule
https://docs.microsoft.com/en-us/powershell/module/exchange/remove-inboxruleCommand-line switches for Microsoft Office products
https://support.microsoft.com/en-us/office/command-line-switches-for-microsoft-office-products-079164cd-4ef5-4178-b235-441737deb3a6https://mgreen27.github.io/posts/2019/06/09/O365HiddenRules.html
In this post Im going to talk about Office365 hidden inbox rules. Im going to give some background, show rule modification, and talk about detection methodology.
Background
Attacks against Office 365 have generated a fair amount of industry acknowledgement in recent times as more and more organisations have moved towards cloud based services. Misconfiguration combined with less than optimal threat awareness means even the most simple attacks can provide access to this crucial service.
Inbox rules are typically part of evil methodology and can be abused across the attack lifecycle:
- Defence Evasion
- Reconnaissance
- Persistence
- Data collection / Exfiltration
Typically inbox rules are simple to detect statically via GUI access or in bulk from the Exchange Management Shell (EMS).
O365 EMS: Typical Powershell detection.Hidden Rules
Minimally documented, Damian Pfammatter at Compass Security explained the methodology in his September 2018 blog post. In summary, inbox rules can be hidden by leveraging an API called Messaging Application Programming Interface (MAPI), which provides low level access to exchange data stores.
Below I am accessing the inbox rule manually via the MFCMAPI tool from a machine with an Outlook profile configured to our in scope mailbox. IPM.Rule.Version2.Message objects indicate an inbox rule.
EvilMove inbox rule: prior to changeModification is simply adding an unsupported value to the PR_RULE_MSG_PROVIDER field (or blanking out).
EvilMove inbox rule hidden: fake provider details.Once modified, the inbox rule is hidden and completely operational:
InboxRule hidden: no view in WebUI, InboxRule works as expected.
InboxRule hidden: EMS results.Detection
At scale detection of hidden inbox rules comes down to two main areas.
1. MAPI based - point in time.
Microsoft have released a script for use over Exchange Web Services (EWS) - Get-AllTenantRulesAndForms that enables tenant wide collection of Exchange Rules and Forms querying the low level data stores. This script enables visibility of Hidden Rules but leaves out an essential PR_RULE_MSG_PROVIDER field for detection. A modified version from Glen Scales collecting the PR_RULE_MSG_PROVIDER field is available here - Get-AllTenantRulesAndForms (screenshot below).
- Frequency analysis on RuleMsgProvider field is recommended as a starting point for detection.
- Alert and investigate any inbox rules with blank or unusual RuleMsgProvider fields.
- Alert and investigate IsPotentiallyMalicious = True - i.e rule action is an executable object.
- Limitations are high privilege requirements - Global Admin role AND EWS ApplicationImpersonation.
Exchange Web Services (EWS): Empty RuleName and RuleMsgProvider fields.The action, condition and command fields (if populated) are base64 encoded raw byte arrays. I have yet to find documentation on the format for decoding or reverse engineer the data but there are some identifiable strings that can provide insights into the rule.
Decoded Action: Rule to forward email to external SMTP account.For investigations, it is also possible to attempt to reanimate the strings and unhide the rules using MFCMAPI. In my testing I have been able to have the rule reappear adding in a known PR_RULE_MSG_PROVIDER field value.
- A fake, mistyped or blank PR_RULE_MSG_PROVIDER the rule would remain hidden.
- Protocol documentation can be found here.
- Remediation instructions can be found in the Further Reading section below.
2. Unified Audit Log - telemetry.
The Unified Audit Log (UAL) is a centralised log storing audit events for all Azure services. It can be accessed via O365 WebUI: Security & Compliance > Search > AuditLog Search or EMS Administration: Search-UnifiedAuditLog commandlet.
- This method is best suited to active monitoring via a SIEM or monitoring solution.
- Alert and investigate any unusual New-InboxRule (creation) or Set-InboxRule (modification) events.
- Benefits include reduced privilege requirements - e.g a user with View-Only Audit Logs or Audit Logs roles enabled.
- Logging must be enabled and retention is a consideration for historical searches.
Telemetry based detection - Search-UnifiedAuditLog: New-InboxRule eventOther Forwarding specific
O365 has other indirect detection capabilities that assist spotting hidden rules. One of those is built in alerting on forwarding of mail to external addresses. This alert is also generated as a SecurityComplianceAlert in the UAL. Keep in mind on compromise of a privileged account an attacker could simply suppress these alerts to stay under the radar.
Redirect Threat Management alert - Email also sent.It is also possible to monitor traffic patterns of forwarded or redirected traffic. Below I have shown a summary inside the Security and Compliance Mailflow Dashboard.
Final Thoughts
In this post I have covered detection points for hidden inbox rules:
- Point in time query via Exchange Web Services (EWS).
- Rule creation and modification inside the Unified Audit Log.
- Other alerts in O365 ecosystem
Although this post has an example of an inbox rule with external forwarding, hidden rules can be leveraged for other evil use cases including: persistence, reconnaissance and data collection. Best practice would include creation of a low privilege account for active monitoring of telemetry and periodic assessments leveraging a higher privilege account via Exchange Web Services.
I hope others found this post useful, feel free to reach out if you have any feedback, questions, or improvements.