This guide details what to do when you find a malicious mail rule. There are 4 steps:
Damage limitation: take some quick steps to minimise damage.
Find the root cause: how was this account compromised?
Check if other users are compromised: is this account the only one affected?
Recovery: once we understand how the attack happened, and how widespread it is, we can comprehensively rebuild and clean up.
1. Damage limitation
First, we want to take some quick actions to limit the impact of the compromise.
1. Disable the rule: disable the malicious rule to make it ineffective whilst you investigate. To do this, you have two options:
Use the Push platform: Select the malicious mail rule from the initiative Dashboard page. In the top right, select "Actions", and then "Disable this rule".
Disable in Outlook: View the mail rules in the victim's mailbox. Toggle the rule to the disabled position, as shown in the image below:
2. Find the root cause
Follow the steps below to inspect relevant logs and data to pinpoint how the account was compromised:
Inspect login events
Inspect OAuth apps
Look for phishing emails
Analyse 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 listed 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 for at least a week earlier - although some attacks are completely automated, such that credentials are immediately used, often attackers have a credential harvesting phase before switching to a utilisation phase and therefore there may be a delay between credential compromise and usage.
Look for any mails 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. Don't panic if the target user is present in past breaches - since some very large sites have been compromised in the past, this is actually quite common. However, it may indicate a possible root cause, especially if the breach was relatively recent.
Analyse the victim's machine: it is possible malware on the victim machine added the mail rule. There are a number of common 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: out of date 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's a list of vendors approved by NCSC.
If that is not an option for you, jump to step 4 and complete all steps.
3. Check if other users are compromised
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 organisation 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.
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 authorised 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.
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:
Run a message trace across your Exchange instance to look for all users who received mail from the suspicious address.
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 etc. for users that potentially did not fall for the phish, it is safer to assume that all users were affected as users may be embarrassed to admit they fell for a phishing email or are often even unaware.
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 bin 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.