Mastering Email Forwarding Rules in Microsoft 365
Follow us on LinkedIn | Twitter | GitHub| Medium
Our cloud incident response trainings are now available!
Introduction
In this blog, we present various scenarios in which threat actors can utilise email forwarding rules and the associated evidence in the UAL. Additionally, we have created a comprehensive mind map that summarises the contents of the blog for use in incident detection and response investigations.
Email forwarding rules
In this blog we will discuss a threat actor technique that we will summarise as ‘email forwarding rules’. Often in Business Email Compromise (BEC) cases a threat actor accesses a victim email environment and they configure an email forwarding rule. There are several motivations for the threat actor to do this, first as a persistence mechanism (T1137.005) and second as a method to collect emails (T1114.003).
Mailbox vs Transport rules
There are two types of rules:
- Mailbox rule
- Transport rule
A mailbox or inbox rule is configured on a per mailbox base and can be configured by the Owner/Admin/Delegate of a mailbox.
A transport or mail flow rule is configured on the entire email flow of an organisation. Can only be configured by users with administrative roles/permissions. More details on Transport rules in the official documentation.
Unified Audit Log
The UAL is a crucial log for incident response in Microsoft 365 tenants. It captures both user and admin initiated actions and is enabled by default. While we won’t delve into the specifics of acquiring or processing this data in this blog post, we’ve included links to relevant resources in the Resources section for those who need more information.
Scenarios
Threat actors have several techniques at their disposal when creating an email forwarding rule. They can configure a mailbox rule through the web GUI (https://outlook.office.com/), through an email client like Outlook, or through PowerShell or an API. The following scenarios outline the possible methods for creating a mailbox rule:
- New mailbox rule, a new email rule is created on a mailbox;
- An existing mailbox rule is modified or deleted;
To configure a transport rule the threat actor can use the Exchange admin portal (https://admin.exchange.microsoft.com/#/transportrules) and PowerShell or API. Because transport rules are not defined on the mailbox level you cannot do this via the Outlook web portal or an Outlook client. The following scenarios are possible for the creation of a transport rule:
3. New transport rule, a new transport rule is configured for an organisation;
4. An existing transport rule is modified or deleted;
Security & Compliance
An alternative approach to the detection of mailbox or transport rules is through security alerts that are part of the Microsoft 365 Security & Compliance center. An alert will trigger a log entry in the UAL.
5. A security alert is generated because of a mailbox/transport rule.
UAL details
Each of the scenarios generates one or more log entries which is great, the challenge is that depending on how the mailbox/transport rule is configured a different log entry might appear. To make it as clear as possible we have created an overview of the relevant Operations in the UAL per scenario with example entries.
Scenario 1 — New mailbox rule
Interestingly enough you can configure a new rule on a mailbox either through Rules or Forwarding in the Microsoft 365 Outlook portal.
Both generate a different log entry, let’s run through all the scenarios and the generated evidence.
UAL Example — New rule generated through the Outlook web GUI via the Rulesoption. The ClientIP records the actual source IP address (redacted), the other interesting values are in the Parameters block. The UserId contains the creator of the rule and in this case the mailbox address that was modified.
UAL Example — New rule generated through the Microsoft 365 Outlook Portal via the Forwarding option. The ClientIP records a Microsoft IP address, the Parameters shows where emails are forwarded to. The UserId contains the creator of the rule. Based on the combination of the ObjectIdand the UserId we can see that this was configured by a different user than the owner of the mailbox.
UAL Example — New rule configured through PowerShell. The ClientIP records the actual source IP address (redacted), the other interesting values are in the Parameters block.
UAL example — New rule configured through the Outlook client. The ClientIP and ClientIPAddress fields record the actual source IP address (redacted), the other interesting values are in the OperationProperties block. The RuleOperation field shows this is a new rule (AddMailboxRule).
Scenario 2 — Modified or Deleted mailbox rule
Another option is modification or deletion of existing mailbox rules. Either for a threat actor to blend in by modifying an existing rule or hiding traces by deleting a rule.
UAL example — Modifying an existing mailbox rule through the web portal or PowerShell/API results in the same log entries. The Parameters field contains the changed values. In the below example we can see that the forwarding address is modified to another external email address.
UAL example — Modification of a rule in the Outlook client. This activity results in a UpdateInboxRules entry, by analysing the RuleAction field you can distinguish between a Modification or Deletion of a rule. With the RuleId you can correlate the different activities for a given rule.
Scenario 3 — New transport rule
There’s no way to configure a transport rule from within the Outlook client or within the Outlook web GUI. It can be configured via the Exchange Admin Portal or through PowerShell/API.
UAL example — Creation of a new transport rule through PowerShell. How can we determine that this is from PowerShell, one reason is the actual IP is recorded which is not there when we make changes through the portal. But the real reason is the AppId, if it’s filled you can use this field to look up application responsible for performing this action.
Tip: You can use the value in the AppId field to lookup the application/client that was used for an activity.
Scenario 4 — Modified or Deleted transport rule
UAL example — Modification of a transport rule via AppId (497effe9-df71–4043-a8bb-14cf78c4b63b). Can you figure out how this transport rule modification was carried out? Under the Parameters we can see that the key RedirectMessageTocontains an external email address and is used to forward all emails.
UAL example — Last but not least the deletion of a transport rule. The value in the Identity field is the unique email rule identifier that can be used to correlate with a creation or modification event.
Scenario 5 — Security alert generated
Using the Security & Compliance center’s built-in alerts is a powerful yet often overlooked method for analysing email forwarding rules. When responding to an incident, time is of the essence, and quick answers are crucial. One effective way to identify unusual activity in the UAL is to filter for security alerts.
Both AlertTriggered/AlertEntityGeneratedOperations are generated as part of an email box rule or transport rule security alert. However, it’s better to use the AlertEntityGeneratedbecause it contains a bit more details in the Datafield. Just the event alone is not enough, but you can use the Alerts overview in Microsoft Purview to gather all the details.
UAL example —The below example shows an alert generated, because of an email forwarding rule.
Due to the lack of details in the Datafield it’s required to go to the Alerts overview to get more details and also the underlying UAL entries that caused the alert:
Summary
To better understand email forwarding rules, it is important to recognise that the UAL plays a crucial role in analysing them. Since there are many options available for configuring email forwarding rules, there are also many types of log entries represented by Operations. This blog has explored various scenarios for creating email forwarding rules and the corresponding evidence they produce, with the aim of providing a comprehensive overview for incident responders and security analysts. To summarise the contents of the blog, we have created a mind map that includes the different scenarios and UAL evidence. Download it from our GitHub.
If you made it all the way to the end, thank you for reading we appreciate you. Please consider sharing this blog if this might be useful for someone else.
Further reading
There are lots of good resources available on BEC and email forwarding rules. Below some resources that we’ve worked on or that we appreciate a lot:
- Microsoft-365-Extractor, a toolset we developed too support in acquisition of the UAL.
- BEC Guide by PwC, this guide goes through the complete BEC analysis process.
- Awesome BEC collection, by Phill Moore
About Invictus Incident Response
We are an incident response company specialised in supporting organisations facing a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/247
📧 Questions or suggestions contact us at info@invictus-ir.com
