wave-pattern

Insights

Microsoft 365 Inbox and Forwarding Rule Forensics

Author: Kyle Carr August 12, 2020

Microsoft 365 Inbox and Forwarding Rule Forensics

Every day, more and more companies are taking advantage of the benefits offered by cloud-based solutions. However, security for these different cloud services, including identifying risky activity and maintaining security, is often misunderstood, and threat actors have taken notice. Crypsis and information security professionals have witnessed a prolific rise in Microsoft 365 (M365) email compromises over the past year. In 2019, the Federal Bureau of Investigation (FBI) estimated that Business Email Compromise (BEC) attacks cost $3.5 billion in global losses, and again estimated that BEC would rise in the wake of the COVID-19 pandemic. M365 presents an enticing mix of potentially sensitive information and weak default security for threat actors. Because of this, those responsible for organizational security as well as incident responders must be proactive in protecting their M365 environments.

Once threat actors have access to a mailbox, we commonly observe them leveraging the mailbox rule capabilities of either Inbox, Simple Mail Transfer Protocol (SMTP) forwarding, and Transport policy to forward emails to an external email address or to hide or delete emails from the original intended recipients.

In this blog, we will discuss important forensic techniques incident responders can adopt to both identify potentially suspicious mailbox rule activity in any M365 environment and help them remove threat actor rule creations.

Please note: M365 enables most actions that are performed within the tenant to be logged, but it may not be turned on by default. If you are not aware of this, please double check your M365 environment to ensure that auditing is enabled.

How Do Threat Actors Use M365 Inbox and Forwarding Rules?

Inbox rules are used to automatically perform specific actions on emails that arrive in the user’s mailbox.  These rules can be created through a series of actions either through Outlook on the web, the Outlook application, or even through PowerShell. Inbox rules include the optional parameters “forward to” and “redirect,” which forward messages from one mailbox to another. 

When a threat actor gains access to a mailbox, they may use inbox rules to evade detection and carry out their attack. For example, a threat actor may create an inbox rule to mark emails as read and move them to a separate email folder, or delete all messages from “X” company to ensure that the intended recipient doesn’t see any of the conversations between that mailbox and “X” company. 

In some cases, we have seen threat actors sending mass phishing emails and then using inbox rules to delete messages related to the phishing email in either “sent” or “received.” This could prolong the attack and potentially stop the original mailbox user from identifying the phishing campaign.

Threat actors can use the parameters “forward to” and “redirect” to send specific emails to their own email account to gain desired information. They may also create a Simple Mail Transfer Protocol (SMTP) rule to forward all emails from the intended recipient to their own mailbox account. For Microsoft SMTP forwarding rules, there is the parameter “DeliverToMailboxAndForward,” with the option either being “TRUE” or “FALSE.”  If set to “TRUE,” then the email will deliver to both the original recipient and the originally set SMTP email address. If “FALSE,” the email will never be delivered to the original recipient and will only be forwarded to the set SMTP forwarding address.

If an Exchange administrator or global administrator account is compromised, the attacker may create a Transport Policy rule to carry out their attack. These rules act on messages while they’re in transit, rather than after the message is delivered to the mailbox, and contain a large set of conditions, exceptions, and actions to specify what the rule should perform. For example, a threat actor may set up a Transport Policy rule to send all messages that are received within the entire M365 environment to an external email address if any of the emails contain keywords such as “ACH, wire, payment, credit,” or others.

Let’s Talk Forensic Techniques

There are several tools available within M365 that are quite helpful when investigating a potential attack. Incident responders should review all resources available and enable them to understand the full extent of the breach and take appropriate action.

Forwarding Dashboard Report

The M365 Forwarding Dashboard Report contains details of all emails that have been forwarded outside the environment as a result of any forwarding rule within the filtered time frame (within a maximum 90-day timeframe). This includes all Inbox rules that either use the “redirect” or “forward to” parameters, any SMTP forwarding rules, or Transport Policy rules.

To access this report, an administrative user account can access the Security & Compliance Center (https://protection.office.com) > Reports > Dashboard > Forwarding Report. Make sure to click the View details table at the top right to see the specifics about the emails forwarded.

Forwarding Report Dashboard location

Figure 1: Forwarding Report Dashboard location

M365 Forwarding Dashboard Report

Figure 2: M365 Forwarding Dashboard Report

In addition to displaying all rules directing an email to be forwarded outside the environment, the dashboard displays the sender, recipients, the recipients’ domains, the number of emails that have been forwarded during the filtered time frame, and the date and time the rule was initially created.

Note that the Forwarding Dashboard report contains a column labeled “First forward date.” This means that even if a forwarding rule was created over 90 days ago (the typical roll-over date for unified audit logs–more about those later in this blog), you can still determine when that rule was initially created. This helps identify a potential timeline of compromise, which may not have been identified within the unified audit logs.

In most business environments, it is uncommon for an employee to be forwarding emails from their work email account to a personal email account. When reviewing this dashboard, Crypsis is typically trying to identify forwarding rules that are directing emails to an external address. We find that threat actors will create anything from randomly named email addresses to those similar to the original recipient.

Admin Audit Logs

Admin audit logs are extremely helpful in investigations and often the first place we check when reviewing a new M365 environment. This is because in every M365 environment, admin audit logs are enabled by default and will contain all administrative actions that have been performed within the environment over the past 90 days. These logs can be used to identify all “New-InboxRule” (the creation of a new inbox rule within a mailbox) and “Set-InboxRule” (the modification of an inbox rule within a mailbox) operations that have been performed within the M365 environment dating back 90 days, if available. Admin audit logs can be accessed via the Exchange Admin Console (EAC) or pulled using PowerShell commands to connect to your M365 environment.  

Additionally, the admin audit logs can be used to identify the “Set-Mailbox” operation followed by the parameter “ForwardingSMTPAddress,” which would be used by a threat actor to forward all emails from one mailbox to another. The operation “Set-TransportRule” is used to identify the creation of a transport policy and would appear in the admin audit logs with information indicating the associated user as well as their IP address.

Along with the mailbox rule operations, the admin audit logs will also display any permissions added from one mailbox to another (Add-MailboxPermission, Add-RecipientPermission). Admin audit logs will also always display the date/time the action occurred, the caller (person who performed the action), the object modified (mailbox being edited), and the IP address that performed the action. This information allows us to quickly identify if there is any red flag activity being performed within the environment that needs a closer look.

There are two ways to access admin audit logs: via the Exchange Admin Console (EAC) or via a PowerShell session. Both options will produce the same results; however, users that are non-technical or not familiar with PowerShell should use the EAC web interface portal. Both options are discussed in detail below. 

Accessing Admin Audit Logs Using the Exchange Admin Console (EAC)

To access the admin audit logs through the Exchange Admin Console (EAC), an administrative-level user can log into the M365 environment, click the Admin tile, and then click the Admin centers > Exchange. The EAC portal can also be directly accessed using the link https://outlook.office365.com/ecp.

Exchange Admin Center

Figure 3: Exchange Admin Center

Once inside the EAC application, click compliance management > auditing.

Exchange Admin Center Compliance Management

Figure 4: Exchange Admin Center Compliance Management

The user can export the admin audit log report by clicking Run the admin audit log report. This will generate a pop up for the user to select the time frame and an email address the report can be sent to within 24 hours.

Once the email is received, it will contain a file titled “SearchResult.xml,” where an analyst can examine either the native XML format or convert the file to CSV.

Example of Receiving Admin Audit logs from EAC

Figure 5: Example of Receiving Admin Audit logs from EAC

https://docs.microsoft.com/en-us/exchange/security-and-compliance/exchange-auditing-reports/view-administrator-audit-log

Accessing Admin Audit Logs via Powershell (PS)

To access the admin audit logs via a PowerShell session, an administrative user will need to use an M365 Exchange environment via a PS session.

$Session1 = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credentials -Authentication Basic -AllowRedirection

More information about the M365 PowerShell session can be found here.

The command Search-AdminAudit cmdlet can be used to pull the logs and export them to CSV once you gain access to the M365 Exchange environment via PowerShell.

Search-AdminAuditLog -ResultSize 250000 -StartDate MM/DD/YYYY -EndDate MM/DD/YYYY | Export-csv -Path C:\Users\kyle.carr\Desktop\AdminAuditLogs.csv

The user should filter the column named CmdletName to show exactly which mailboxes have recently created a rule (New-InboxRule), modified a rule (Set-InboxRule), created a SMTP forwarding rule (Set-Mailbox), or created a transport policy rule (Set-TransportRule) within the past 90 days. Additionally, this will show the correlating IP address that performed the action and the parameters that were included within the rule.

Example of Identifying Fraudulent Inbox Rules

Figure 6: Example of Identifying Fraudulent Inbox Rules

Unified Audit Logs

Unified audit logs can be thought of as the Security Information and Event Management (SIEM) of the M365 environment. Here, logs from applications within the existing M365 tenant are ingested into the central, or “unified,” logging system. In most M365 environments, the unified audit logs only date back 90 days. However, depending on the M365 licensing type, the unified audit logs could date back up to a year (M365 E5 License). They may not be enabled by default in your environment. Follow the information found here to enable this auditing capability. 

These logs can give us similar information as found in the admin audit logs, but they give more granular detail on the variables contained within the Inbox Rule parameters, which can be critical during an investigation. For example, the admin audit logs will indicate that the InboxRule contains the parameter “MoveToFolder” but does not display the associated value (which folder it is moving emails to). The unified audit logs will display the value associated with the parameter “MoveToFolder RSS Subscriptions” in this case.

Admin Audit log New-InboxRule example data

Figure 7: Admin Audit log New-InboxRule example data

Unified Audit log New-InboxRule example dataAudit Log Search

Figure 8: Unified Audit log New-InboxRule example dataAudit Log Search

Unified audit logs can be accessed through the Outlook Web Interface within the Security & Compliance center. To access the Security & Compliance center, a user with admin privileges can log into the M365 environment at https://protection.office.com. Additionally, the Security & Compliance center can be found by clicking the More Resources button in the Admin center.

Once inside the Security & Compliance center, the unified audit logs can be found in the Search > Audit log search tab.

Unified Audit log location

Figure 9: Unified Audit log location

These logs can be filtered back 90 days, as well as filtered by username. Additionally, the “activities” filter can be used to extract specific operations. If left blank, all operations for that user will be exported. It can be helpful to export all logs as this provides a full timeline of events for a user, which can then be reviewed during an investigation.  

After being filtered, click the Search button to populate the findings. Once the findings are populated, they can be exported by clicking the Export Results > Download all results, where the results will be downloaded to a .CSV document.

Filter this CSV to identify “New-InboxRule” and “Set-InboxRule” operations along with the IP address and user responsible for creating or modifying the rule.

Accessing Unified Audit logs via PowerShell 

To access the admin audit logs via a PowerShell session, an administrative user will need to use an M365 Exchange environment via a PS session.

$Session1 = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credentials -Authentication Basic -AllowRedirection

The command “Search-UnifiedAuditLog cmdlet” can be used to pull the logs and export them to CSV once access has been gained to the M365 Exchange environment via PowerShell.

Search-UnifiedAuditLog -StartDate MM/DD/YYYY -EndDate MM/DD/YYYY -Operation “New-InboxRule,Set-InboxRule” -User “Kyle.Carr@CrypsisGroup.com” -SessionCommand ReturnLargeSet -ResultSize 5000 | Export-csv -Path C:\Users\kyle.carr\Desktop\UnifiedAuditLogs.csv

Note:  The Operation and User flags are not required, though they can be used to pull specific logs depending on what you are looking for. For the creation of rules, the operations would be: New-InboxRule, Set-InboxRule, Set-Mailbox, Set-TransportRule.

More information about M365 PowerShell unified audit log extraction can be found here.

Once the logs have been exported into the CSV format, they can be filtered and reviewed to identify the situation at hand.

Conclusion: 

Attacks on cloud-based email environments will not be slowing down anytime soon. By adopting the forensic techniques discussed above, incident responders can quickly identify threat actor activity in their M365 environment. Using the M365 Forwarding Dashboard report, admin audit logs, and unified audit logs, you will be able to find malicious Inbox, SMTP forwarding, and Transfer policy rules so that you can remediate them.  

Check back in to Crypsis’s blog soon for an additional blog that highlights an M365 attack case example observed by Crypsis. Also, if you are interested in learning about a unique and persistent M365 attack technique, check out our recently published blog, Hidden Rules: Business Email “Crypsis” written by Erik Cabrera.

________________________________
1 Microsoft has formerly rebranded Office 365 to Microsoft 365 (M365)
https://pdf.ic3.gov/2019_IC3Report.pdf
3 https://www.fbi.gov/news/pressrel/press-releases/fbi-anticipates-rise-in-business-email-compromise-schemes-related-to-the-covid-19-pandemic 

Topics: Security Insights