EOP Escalates the Fight Against High-Confidence Phish

Moves Away From Allow Sender and Allow Domain Lists

Office 365 notification MC226683 “Secure by Default – Honoring EOP/ATP detonation verdicts” published on November 13 is another step along the way to achieving secure by default Exchange Online configurations. Other efforts in this space include the project to remove basic authentication connection protocols from Exchange Online (postponed to mid-2021) and clamping down on automatic mail forwarding.

In this case, Microsoft wants to take allow sender and allow domain lists out of the equation used to determine if phishing messages are allowed through to user inboxes. As they note: “adding senders and domains to an allow list is not best practice and should be considered as a legacy way of filtering.”

Allowed sender lists and allowed domain lists are part of the Exchange Online Protection anti-spam policies (now under the Microsoft Defender for Office 365 brand). These lists are supposed to identify senders and domains the tenant knows are safe to accept email from. This was certainly a good approach in the less complicated and safer world of the early spam period. It’s not the case now where threat from malware constantly evolves. When you define a sender or a domain as safe, you run the risk that an attacker can successfully deliver a message to inboxes which should be filtered but isn’t because it appears to come from a known safe origin.

Suppressing High-Confidence Phish

What’s changing is that Exchange Online Protection will no longer take allowed senders and allowed domains into account when it filters out high-confidence phish (messages that EOP is very sure are phishing attempts). The detonation referred to in the notification title is where suspicious messages are tested in a virtual environment to understand if they are safe. Inside the environment, the message can be opened (detonated) to see what happens. If the message proves to be malware of some kind, it won’t be delivered.

In the past, a detonated high-confidence phish message considered malicious might be delivered if it appeared to come from an allowed sender or domain. This is obviously dangerous because the recipient might assume that the message is safe and interact with its content, including following links to sites where their data might be compromised.

Time to Check Allow Lists

This will no longer happen after Microsoft rolls out the change in Exchange Online Protection at the start of December. The change should be effective worldwide by the end of January 2021. “Normal” spam including lower-confidence phish will continue to be allowed through if it comes from allowed senders and allowed domains, which is an excellent wake-up call for administrators to review the default anti-spam policy used by Exchange Online Protection to check if any allowed senders or domains are defined (Figure 1) and then remove any entries not deemed essential (Figure 2).

 Reviewing the Allow Lists section of the Exchange Online Protection default anti-spam policy
Figure 1: Reviewing the Allow Lists section of the Exchange Online Protection default anti-spam policy
Reviewing the allowed domains list in the anti-spam policy
Figure 2: Reviewing the allowed domains list in the anti-spam policy

Defocusing on tenant allow lists doesn’t affect user-generated safe sender lists maintained with clients like Outlook and OWA. These lists are applied after server checks and don’t influence how EOP deals with high confidence phish.

Use a Mail Flow Rule Instead

Microsoft’s advice is to replace the allowed senders and allowed domains list with a mail flow rule to skip anti-spam filtering for messages originating from absolutely safe sources. The mail flow (transport) rule can be made much more specific about where messages come from, so it is inherently safer than the “accept everything from this domain or sender” approach in allow lists.

Be careful when configuring the mail flow rule to make sure that email is processed the way you think it should be. Microsoft’s prototype rule is certainly effective, but you need to test to ensure that it works as expected in conjunction with other rules your organization already has in production.

If you see false positives (messages which are absolutely not phishing attempts being marked as such), you can submit copies of these items to Microsoft so that the characteristics of the messages can be understood. This will help Microsoft improve the algorithms used to detect phishing and stop the false positives happening.

For more information about how Exchange Online Protection anti-malware protection works, read Chapter 7 of the Office 365 for IT Pros eBook. We update the book monthly to make sure that important changes like this are captured and incorporated into the text.

6 Replies to “EOP Escalates the Fight Against High-Confidence Phish”

  1. Tony – this article is somewhat useless unless you can show a concrete example on how to combat this issue. if you have clients who suddenly have dozens of emails stuck in quarantine without warning. most of which are categorized as “High Confidence Phish” and as you know, you cant add their own domain to the safe sender list either. the only immediate solution is to direct those to their junk folder. So the question is why all the false positives ? if a user is running a mac and doesnt use outlook or OWA; they cant really use the safe sender list. I dont want to have to keep going into their quarantine to release messages. please post a follow-up solution. creating mailflow rule for each and every domain is not really a solution. I feel like there is something wrong with the CAT HPHISH algorithm I see in the headers.

    1. I don’t understand the concern. It’s a change to deal with high-confidence phish – and you do not want those messages being delivered. If a problem shows up and email is being quarantined when it shouldn’t, it’s time to check that domain a) to understand if its DMARC, SPF, etc. settings are in order and b) what could be in the messages to make EOP think they are high-confidence phish. I see very little high confidence phish which I would like to release to end users. An easy way to keep an eye on the problem is to write a script (like the one in https://office365itpros.com/2020/08/12/analyze-quarantined-messages-powershell/) to check quarantine and advise admins if a build up of messages is there. And if these are false positives, you report them to Microsoft https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/submit-spam-non-spam-and-phishing-scam-messages-to-microsoft-for-analysis?view=o365-worldwide to allow them to analyze what’s going on and stop these messages being regarded as phishing.

  2. Hi Tony,

    In my organization, I see this happening:

    I have a Bypass spam filter mail flow rule for a recipient address.(because an auto-forward is setup from this recipient address to another. I want to ensure all emails are forwarded and none go to the Junk folder.)
    The email reaching the inbox of this mailbox correctly show SCL as -1

    Despite the spam bypass filter mail flow rule there are some emails being Quarantined by EOP especially the ones that are marked as “High confidence spam” and “Malware”.

    Here the SCL value also changes.

    I think the reason is because of Microsoft’s Zero-hour auto purge (ZAP) for high confidence phishing setup (Secure by default in Office 365).

    So even a bypass mail flow rule / allowed senders rule will not stop EOP from isolating Malware or High confidence spam.

    It is stated under the 2nd important box on the page you linked from the article – https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/create-safe-sender-lists-in-office-365?view=o365-worldwide

  3. Hi Tony,

    Is there a new way of approaching High Confidence Phishing false positives? The old method no longer seems to work now that Microsoft bypasses safe senders and transport rules to block emails. It also appears that the end user can no longer release these types of messages. Any thoughts would be appreciated.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.