What to do if you find a malicious mail rule in Microsoft 365

This guide details what to do when you find a malicious mail rule. There are 4 steps:

1. Limit the damage: Take some quick steps to minimize damage.

2. Understand the root cause: How was this account compromised?

3. Check if other users are compromised: Is this account the only one affected?

4. Recovery: Once we understand how the attack happened, and how widespread it is, we can comprehensively rebuild and clean up.

First, we want to take some quick actions to limit the impact of the compromise.

1. Disable the rule: Disable the malicious rule while you investigate. To do this, you have two options:

• Use the Push platform: Select the malicious mail rule on the mail rules page in the Push admin console. In the top right, select Actions and then Delete this rule.

• Disable in Outlook: View the mail rules in the victim's mailbox. Toggle the rule to disable it.

2. Reset the user's password: Although we don’t yet know if the user's password is compromised, it is a quick and safe precaution.

Follow these steps to inspect relevant logs and data to pinpoint how the account was compromised:

• Inspect login events

• Inspect OAuth apps

• Look for phishing emails

• Analyze the victim's machine

Login events: Go to the Sign Ins section of the Azure AD blade and filter for the victim and relevant time period.

Can you see a suspicious login? Specifically look at the location, time, and device type (add the Device browser column using the Columns button). Take into account the victim's typical location, working hours, and devices and look for events that fall outside these norms.

Look at login attempts for the user prior to rule creation: Are there numerous failed logins, culminating in a successful login? This suggests a password brute force.

Alternatively, look more broadly at failed logins across your entire tenant: Are there numerous failed logins across accounts, culminating in a successful login for this victim? This suggests a password spray.

OAuth apps: Go to the Users blade in Azure Active Directory and select the victim user. Select Applications from the menu on the left. Inspect the installed applications for anything unexpected, particularly with a date around the time of rule creation. 

If you see an application that looks suspicious, click its name and copy its Application ID. Next, go to the Enterprise Applications blade in Azure Active Directory and enter the previously copied application ID into the search bar. This should filter the list to just the suspicious application. Click its name and select Permissions from the menu on the left.

Inspect the permissions and their descriptions to determine if the app is requesting suspicious permissions. For example, if the app created malicious mail rules, you might see the MailboxSettings.ReadWrite permission.

If you find a suspicious app, this suggests consent phishing was used to compromise the victim.

Email logs: If you haven’t found a suspicious login or app, the user may have received a phishing email that coerced them to disclose their credentials. 

Inspect the mails in the victim's mailbox leading up to the time of rule creation, looking back at least a week. Although some attacks are completely automated, meaning credentials get used immediately after capturing them, often attackers have a credential harvesting phase before switching to a utilization phase. That means there could be a delay between credential compromise and usage. 

Look for any email with links or buttons, particularly ones referencing Microsoft 365, document sharing, or generally encouraging a login. Inspect the sender email address and the destination URLs of suspicious mails (don't click the links or visit the URLs, simply copy them to a notepad for manual inspection). Do they line up with what you’d expect if it was legitimate?

Compromised credentials: The victim's password may have been compromised elsewhere, rather than guessed. Since users commonly reuse passwords, a password compromise elsewhere can give an attacker direct access to many other accounts. haveibeenpwned.com is a site that tracks password breaches and will tell you which breaches your username has been part of. (You can actually use the Push platform to do this, as it will flag leaked passwords using the data set from HIBP.) Don't panic if the target user is present in past breaches. Several very large sites have been compromised in the past, so this is actually quite common. However, it may indicate a possible root cause, especially if the breach was relatively recent.

Analyze the victim's machine: It's possible that malware on the victim machine added the mail rule. There are several ways this could have happened:

• Phishing mail with malicious attachment: Follow the “Phishing” steps above to investigate this path.

• Malicious file download: The victim may have downloaded a file that was malicious. Inspect the victim’s downloads folder for anything suspicious around the time of compromise (remember not to execute or interact with the suspected file). Alternatively, if you have reliable network connection logs, you may be able to search for user web activity around the time of compromise to determine if this is the cause.

• Out-of-date software: Software like browsers or PDF readers are commonly exploited. Inspect the software installed on the victim machine to see if it is significantly out of date. Without significantly more detailed data, such as that provided by an EDR agent, it will be difficult to prove this was the path taken to compromise, but you may be able to look at browsing history to further build your confidence. Did the victim browse any less trustworthy sites or download any suspicious files, such as PDFs, in the time leading up to the compromise?

Still not sure?

If you still haven't determined the cause of the account compromise, but you are confident a compromise has taken place, you should consider calling an incident response company. Here is a list of vendors approved by NCSC.

If that is not an option for you, jump to step 4 and complete all steps.

Once you’ve found the root cause, you need to determine if other users were affected by the incident. Although it is likely the attacker followed similar steps for each victim (e.g. creation of mail rules), this might not be the case. Choose the section relevant to your root cause for steps of how to investigate this.

Password guessing or spraying

If you have determined password guessing or spraying as the most likely cause, we need to try to understand how it happened, and if others in your organization may have been affected. To do this, we will take another look at sign-in logs.

Go back to the Sign Ins section of the Azure AD blade and look for failed attempts leading up to the one you previously identified as suspicious. Look at other failed logins around that time. Look at other attempts from the attacker IP. Is the attacker focusing on just the victim, or a range of users? Can you see if the attacker was successful for other accounts? If so, add those to your victim list.

Consent phishing

If you determined consent phishing is most likely we need to determine if other users installed the malicious app.

Once again, select the malicious app page on the Enterprise Applications blade. Select Users and groups from the menu on the left. This shows you all users who have authorized this app. Add any additional users listed here to your victims list.

Additionally, if you found the phishing mail responsible for the malicious install, follow the steps under Phishing in this section to see if other users received similar mails.

Phishing

If you've found the phishing mail that compromised the victim, you need to see if anyone else received the mail, and whether they also fell for the phish:

1. Run a message trace across your Exchange instance to look for all users who received mail from the suspicious address.

2. If you have reliable network logging for your users, search for any users who visited the domain of the link in the suspicious mail.

The safe and quick option here is to add all recipients to your victims list. Although you may want to avoid the disruption of password resets for users that potentially did not fall for the phish, it is safer to assume that all users were affected because users may be embarrassed to say they fell for a phishing email or are often unaware.

Endpoint malware

If you determined the user downloaded or opened a malicious file, inspect network logs, if available, for other users downloading a similar file. 

Alternatively, inspect AV logs for other endpoints that have seen the same malicious file. Add any results to your victims list.

Now we have a clear picture of the root cause and wider impact, we can focus on recovery.

For each victim:

• Delete the mail rule: View the mail rules in the victim's mailbox. Click the trash icon to remove the rule.

• Reset their password: Follow these instructions to reset the victim's password

• Remove the malicious OAuth app (if applicable): Go to the Enterprise Applications blade in Azure Active Directory and select the malicious app. Select Properties from the menu on the left. Select Delete to delete the application.

• Rebuild the victim’s machine (if applicable): if you suspect the victim was compromised via malware, it is almost always quicker, easier and safer to just rebuild the machine.