Using Microsoft 365 Auditing and Alerts to Monitor Email Forwarding

Good Use of Microsoft 365 Auditing Can Halt Business Email Compromise Attempts

A recent Twitter discussion about how an administrator should react to finding an audit record for the New-InboxRule cmdlet was interesting. The owner of the mailbox that created the inbox rule was on vacation and uncontactable, and the rule redirected messages to a Gmail account. This is an action that always deserves to be checked because it could be evidence of an attacker attempting to exfiltrate email. In any case, allowing users to move email out of a tenant without good reason is bad practice.

Of course, if the organization blocks external email forwarding, it won’t matter if a user (or an attacker) configures a rule to redirect messages. Exchange Online will apply the settings in the anti-spam outbound filter and block messages. Senders receive an NDR with code 5.7.520 to tell them that the organization doesn’t allow external forwarding. A copy of the original email remains in the recipient’s mailbox unless the rule includes a delete action.

Stop Forwarding to Suppress a BEC Tactic

Tenants shouldn’t allow external forwarding. In business email compromise (BEC) attacks against compromised accounts, attackers often create a rule to forward messages. This is a form of reconnaissance to allow the attacker to understand the flow of communications between the owner of the compromised account and others. The ideal thing for the attacker is to locate a thread of email about some financial dealing into which they inject a message to convince someone involved in the conversation to make a fraudulent payment.

If some accounts have reasonable business needs to forward emails externally, a custom anti-spam filter policy can grant them an exception to the general block. Applying sensitivity labels with mail flow rules is another way to protect forwarded messages and ensure that if a message goes to an unexpected domain (like a consumer email domain), the recipient can’t read its content. This won’t stop an attacker who has compromised an account because they can use OWA to access the mailbox and read messages, but it will slow or stop exfiltration. In addition, once the organization discovers the breach and changes the account password, the attacker will be unable to authenticate and loses access to the protected content.

Alerts Sound for Forwarding

Apart from examining audit records, administrators of enterprise tenants should learn when users create a forwarding rule through a threat management alert. Because it relies on a simple detection of an audit record noting the creation of a forwarding rule, the action is covered by the default “Creation of forwarding/redirect rule” alert policy. When the alert detection engine sees the audit record, it generates an email to alert tenant administrators about the problem (Figure 1). It’s then up to the administrators if further action is necessary.

An entry for the alert also appears under the Alerts section in both the Microsoft Purview compliance portal and Microsoft 365 Defender admin center. There isn’t a connection between the two portals. Purview deals with the alert as something that an administrator can check and resolve; Defender considers it as a potential security incident that might result in a full-blown investigation. The lack of integration across the two portals means that administrators need to resolve an alert in two places, which is hardly ideal.

The Microsoft Purview compliance portal supports the creation of new alert policies. An alert policy tells the alert detection engine that it should monitor occurrences of an activity and signal an alert when it detects a match against the policy criteria. Tenants with E5 licenses can monitor signals that might indicate a malware or phishing campaign, while the alerts available to other enterprise tenants limit monitoring to activities like file sharing and email forwarding (Figure 2).

Alert policies can’t monitor the full set of audit events captured in an average Microsoft 365 tenant. Even so, they’re a useful tool to detect and highlight issues that require administrator attention.

Block Then Investigate

But getting back to the original point. An administrator finds a suspicious event in the audit log. What should they do then? The Twitter thread includes some worthwhile hints. Most observers agree that the creation of a rule to redirect email to Gmail is suspect and worth investigating.

The immediate action to take, if the event is suspicious enough, is to block the account, change its password, and stop Azure AD from issuing further access tokens for the account by revoking its refresh token. Securing an account is easily done with PowerShell (see the code in this article).

Blocking the account terminates the access an attacker might have to the account and creates time to contact the account owner and verify if a problem exists and further action is necessary. Clamping down on the account might discomfort the account owner, but it’s better to do that than let an attacker continue to hack away unabated.

Finding Audit Data

Investigating is largely a matter of collecting and analyzing audit data to figure out if a problem exists. The tools used depends on what’s available in the tenant. Some swear by Microsoft Sentinel, and others like other SIEMs. Tenants with Office 365 E3 or above licenses can use the audit log, which is what I concentrate on here. Not because the audit log is the best tool, but rather because it’s available, easily manipulated with PowerShell, and forms the basis of the data used by other tools like Microsoft Sentinel or Microsoft Defender for Cloud Apps.

You can work with raw audit data. The information is all there, but the only standard parts of a Microsoft 365 audit record are those that hold essential information like the timestamp, the user, operation, and record type. Individual workloads like Azure AD, Exchange Online, and Teams store interesting information about auditable actions in the AuditData property of audit records. This is a JSON structure that varies across workloads. Some interpretation is often necessary to extract important information. It would be nice if Microsoft development groups were more consistent about what they store in audit records, but given the thousands of different auditable actions captured in the audit log, I doubt this will happen soon, if ever.

Fortunately, using PowerShell to tease information out of audit records is a well-known technique at this point. To demonstrate the principle of how to use audit data for investigations, I wrote a script (available from GitHub) to find and analyze audit records for a selected account for the last seven days. The script:

• Finds the audit records for specific actions that might indicate account compromise or needed for investigation. The actions include UserSignedIn, Set-InboxRule, and SendAs.
• Extracts the AuditData information for each record. This includes the IP address used by the client. The script uses the techniques described in this article to resolve the IP address against a geolocation service to find the country, city, and ISP for the address.
• Uses information from the IP locations registered for conditional access policies to determine if the IP address is internal (belongs to the organization) or external. The IP address information is in a CSV file that you can edit to add or remove addresses if necessary (for instance, if you don’t use conditional access policies, you can simply add the IP addresses used in the tenant to the file).
• Stores the details of the processing in a PowerShell list for further interrogation.

The script is not an off-the-shelf compromise investigation tool. Instead, it demonstrates how to use audit data that’s available in enterprise tenants to track activity for an account over the past week. There are plenty of holes to fill, such as accommodating the expanding use of IPv6 addresses by Azure AD and other applications, adding extra actions to search for, and analyzing the data in various ways. Feel free to improve the script in GitHub.

Analyzing the Audit Data

After processing the audit records, we can perform some rudimentary analysis to see if anything interesting appears. First, where did the IP addresses captured in the audit record originate?

$AuditInfo | Group-Object City -NoElement | Sort-Object Count -Descending | Format-Table Count, Name

Audit records found originating in these cities:

Count Name
----- ----
  359 Dublin
   15 Loughrea
   10 Amsterdam
    2 Stockholm

As I’m based in Dublin, it makes sense that most of the records originate there. The Stockholm records are interesting, but examination of the records reveals that they capture details of SendAs events from the Outlook for iOS mobile client:

Timestamp  : 09/03/2023 13:14:55
User       : Tony.Redmond@office365itpros.com
Operation  : SendAs
Device     :
OS         :
Compliant  :
ClientInfo : Client=OutlookService;Outlook-iOS/2.0;
IP         : 94.140.38.38
City       : Stockholm
Country    : Sweden
ISP        : GlobalConnect AB
Internal   : False
Site       :
Library    :
Document   :
Mailbox    : Tony.Redmond@office365itpros.com
SendAsUser : Tony.Redmond@office365itpros.com
RuleId     :
RuleName   :
RedirectTo :

Here’s the thing: all messages sent from Outlook mobile clients result in SendAs events because the client hands the message over to the Outlook mobile service for onward transmission. In this instance, the mobile device connected to a Wi-Fi network which assigned it a dynamic IP address. It’s easy for an investigator to misread the data because the mobile phone was a long way from Stockholm when Outlook Mobile sent the email. However, in Europe, companies can sign up with multinational Wi-Fi providers to make networks available to customers, meaning that the geolocation information reported from an IP address can lead an investigator down the wrong path. For this reason, it’s important to understand the full context of what an audit record reports, including how the associated app works.

Another way of looking at the data is to see where the account used “external” IP addresses (i.e., addresses not belonging to internal networks). Figure 3 shows two other views. The first is external IP addresses by city; the second lists access by date order and includes the audited action. The second view shows that external access broke down into a SharePoint Online file access using an address owned by Microsoft and registered to their Office 365 datacenter in Amsterdam and some SendAs operations.

The important thing is that once you understand how to retrieve and understand audit data, the information becomes more valuable from an investigative standpoint. You’ll still need to do the work to trawl through the data to discover clues and find out just what happened, but at least you’ll know what the data means.

The Ongoing Challenge of Keeping Tenants Secure

Microsoft is busily closing off the holes exploited by attackers in their attempts to compromise cloud accounts. Removing basic authentication for seven email protocols was a significant step forward, but now attackers deploy techniques like adversary-in-the-middle (AiTM) phishing sites to replace password spray attacks and capture user credentials. Keep your guard up and keep an eye on the audit data. It’s a great source of information about who did what and when within a tenant.