NOTE: This blog refers to several Microsoft products that require special licensing. Be sure to check your individual licensing to fully comprehend which features are available to you.

Office 365 (O365) has become a recurring favorite and at times the main focus of common threat actors. Once credentials are compromised through tactics like phishing, it feels like O365 is the first – and sometimes only – place that the credentials are played against. That’s because Business E-mail Compromise (BEC) is one of the most successful cyber crimes showing continuous growth.

…BEC can take a variety of forms. But in just about every case, the scammers target employees with access to company finances and trick them into making wire transfers to bank accounts thought to belong to trusted partners—except the money ends up in accounts controlled by the criminals. – FBI

Indicators

There are numerous ways an organization can identify when an O365 mailbox is compromised. From watching sign-in activities through Azure Active Directory Identity Protection to monitoring e-mail traffic for anomalies. One strong way is to watch for malicious forwarding and inbox rules created on your mailboxes. It is very common for threat actors to create inbox rules on mailboxes and it’s important to look for those.

These rule are created to do all sorts of mischievous activities. Some rules may just delete all inbound mail, which can be noticed by the end user quickly. The alternative step commonly taken is to only send e-mails with specific keywords to a special folder or to delete them.

Every now and then a threat actor will attempt to be bold and forward all mail to an external address.

Alerting

So how do you go about being alerted when these rules are made? There are a plethora of ways, but let’s talk about a few easy ones.

PowerShell and Automation

If you have already been made aware (or suspicious) of an account which has been compromised and in some way know that a threat actor has logged into their O365 account, you can inspect their mailbox for rules. With the Exchange Online PowerShell module, you can run immediate commands as part of your incident response procedures. From the PowerShell module, you can connect to Exchange Online and run the following command on any mailbox to see current rules:

Get-InboxRule -mailbox user@domain.com

This command will provide an output of all rules on that mailbox. It will only list Name, Enabled Status, Priority, and RuleIdentity.

In order to see the details about all rules, you can enter the following command on the mailbox (warning: potentially large output):

Get-InboxRule -mailbox user@domain.com | FL

To see details only about a specific rule, you can utilize the RuleIdentity (where the number is provided as seen above) and just see that specific inbox rule. Examples of those outputs are what was seen earlier in this blog.

Get-InboxRule -mailbox user@domain.com -Identity 0123456789 | FL

Knowing the commands above can be useful to have scripts or some form of automation running in your environment looking for keywords or actions being created in user’s inbox rules.

An example use case: If your environment is small, you can have a script that runs Get-InboxRule on all of your end users and parses for any where the Description includes the phrase “delete the message”. When it finds a match, it can then alert your cybersecurity personnel for attention.

Microsoft Cloud App Security

Microsoft Cloud App Security (MCAS) is a powerful tool for monitoring and controlling your Software-as-a-Service (SaaS) environments. One of those SaaS environments is O365 Exchange Online. An out-of-box policy from MCAS is called ‘Suspicious inbox forwarding’. Once enabled, this will utilize the power of Microsoft’s machine learning to identify questionable inbox rules created on any of your mailboxes.

Once it discovers a suspicious inbox rule, it will immediately alert whomever you have configured via e-mail or text message. MCAS now also sends alerts to Microsoft Flow.

Proactive Remediation

The first step in proper remediation is to actually have configurations in place that take care of compromises before they even happen. There is a wonderful Microsoft TechNet article already written on this topic.

To provide a summary and some context on the above linked Microsoft TechNet article:



The first configuration every organization should set is to not allow mailbox forwarding. This will actually remove the forwarding option from Outlook Web Access (OWA) and Exchange Online. This can be achieved through PowerShell commands as described in the article.

The ‘Forwarding’ link on the side menu will not even show up for users once removed.

The second best configuration mentioned in the article is to enable a mail flow rule on your Exchange Online environment blocking external forwarding. When doing so, enable the generation of incident reports and send those reports to cybersecurity personnel.

Enabling both of the above mentioned configurations will immediately stop any bleed from a compromised account. Of course, this will not protect against manual forwards. The hope here is to contain the compromise and alert you of its presence utilizing even more methods than already implemented.

Multi-Factor Authentication and Legacy Protocols

One of the best proactive measures on the market to protect against O365 Mailbox compromise and BEC attempts is enabling Multi-Factor Authentication (MFA). This can be achieved if your organization utilizes Azure Active Directory or through numerous other platforms like Duo, RSA, or Ping.

Most email threats and BEC attacks only resulted in data breaches because multi-factor authentication had not been implemented – Verizon Data Breach Report

One problem with enabling MFA is that legacy authentication protocols do not understand or support it. Legacy authentication protocols are ones like POP3, SMTP, and IMAP. There is a vast amount of research via articles and blogs that discuss disabling legacy authentication protocols. Expect a blog in the near future to help you achieve this from a personal angle and with more depth than provided here.

You can utilize Azure Active Directory Sign-in Event Logs to see where and how legacy protocols are still being used.

Once that is done, you can then slowly block it by using conditional access policies. Conditional access is now available to ALL Microsoft 365 Business Customers! Take STRONG advantage of this offering for numerous use cases!

The above policy shows full blocking as well as some of the granularity capabilities.

Cleanup Remediation

When finding malicious inbox rules created on mailboxes as shown earlier in this post, you can run the following command using the same ‘RuleIdentity’ switch to remove it. Prior to deletion, make sure to document what you find for your incident response process and report.