Microsoft has included phishing detection in Exchange Online Protection for some time now. For the standard phishing emails, like an eBay or PayPal credential theft attempt, there are plenty of signals for EOP to look at. The forged sender addresses, the quality of the writing in the emails, the keywords used, the domains they link to, and so on.
However, it's more difficult to detect spear-phishing and whaling attacks. These are attacks where criminals try to impersonate a trusted sender, targeting individuals within an organization that have access to sensitive data such as employee personal information, credit card numbers, or the ability to transfer money to other bank accounts.
If the attacker can get their email into the targeted mailbox, the recipient can easily be fooled by lookalike domain names, such as using globomantiçs.biz to impersonate globomantics.biz.
Faced with these risks, some customers have implemented their own solutions using Exchange mail flow rules. A common approach is to tag all inbound mail from external senders with some type of identifying mark, such as prepending the subject line with the “[EXTERNAL]”, or inserting text into the start of the email message with a similar warning.
The trouble with that approach is that you either tag all such mail with the warnings, which over time decreases the effectiveness of the warning as users become desensitized to it. Or, you limit the approach to messages that match more specific criteria, which is usually based on attacks you've already seen, meaning you're constantly reacting to new variants.
Defending from these phishing attacks should get a little easier for Office 365 customers with the rollout of anti-phishing policies. This feature allows you to create policies to detect messages that use lookalike email addresses and domain names to trick users. In addition to smartly detecting the lookalikes, ATP will also use what Microsoft refers to as “mailbox intelligence” to determine whether a phish-like email is being received from a new email address that the recipient has had no prior communication with. This allows ATP to insert security warnings into only those messages that are deemed to be a risk, reducing the risk of users becoming desensitized to the warnings.
The new anti-phishing policies are included with Office 365 Advanced Threat Protection (ATP), which is an add-on license for Exchange Online Protection, or is also included in the Enterprise E5 license bundle. When anti-phishing is available in your tenant, it will appear in the Security & Compliance Center.
When you create a new anti-phishing policy, the terminology used can seem a bit confusing at first. Let's walk through an example to clear things up. After choosing a name for your policy, you'll be asked to add users to protect. These are the email addresses that you want to protect from being impersonated. These are not the users who will be receiving phishing emails. So as an example, let's say we want to prevent attackers from spoofing the payroll email for Globomantics to gain access to employee personal data, we would add that address to the policy.
The next step is to add domains to protect. Again, these are domains you want to protect from being impersonated. It's a good idea to leave the option to automatically include the domains you own enabled, so that your own domain names are protected from impersonation. You could also add partner domains, or any domains that could be impersonated in a way that is harmful to your organization.
Next, choose the actions you want to take. You can specify separate actions for impersonated users (specific emails, such as [email protected]) and for impersonated domains. The actions available are:
- Redirect message to other email address
- Move message to the recipient's Junk Email folder
- Quarantine message (this is the user-accessible quarantine, so they can still release and read the message)
- Deliver the message and add other addresses to the Bcc line (this is a reasonable action to take if you just want to quietly test the new policy)
- Don't apply any action (this will still insert the phishing protection tip)
Choosing the appropriate actions will depend on the level of risk for the users or domains you are protecting from being impersonated. If a message is considered phishing, but you deliver it to the user's junk email folder, there is still the risk that they'll find it there, ignore the phishing tip that was inserted, and fall for the scam. However, if you take the most aggressive approach of redirecting the message to another email address (note that there is no “delete message” action available), there is the risk of legitimate, time-sensitive requests being missed.
My view is that quarantining the phishing emails, along with a user education campaign, should be sufficient for most customers. But you can make your own judgement call here, based on your own assessment of the risks.
At the bottom of the actions list is a link to turn on phishing protection tips. There are three tips right now, and they are all on by default. I can't think of any good reason to turn them off, but at least you know the option is there if you need it.
The next option is to configure mailbox intelligence. This is enabled by default, and again I can't think of a good reason to turn this off. Mailbox intelligence uses the mailbox's normal traffic patterns to better enable the impersonation detection to spot unusual messages. For example, if you've never received an email from [email protected]çs.biz, that will be flagged in the phishing protection tip which should then draw your attention to the impersonated sender (assuming the policy allows the user to ever see that phishing email).
Next, you can add trusted senders and domains. This will allow you to override the anti-phishing policy for senders that you know are safe, but perhaps they happen to have a similar domain name to yours (e.g. mathewspizza.com and matthewspizza.com), or some other phish-like characteristic of their emails.
Finally, choose the recipients to apply the policy to. The are the users you want to protect from receiving phishing emails. This option is the same as other ATP policies (Safe Links and Safe Attachments), and allows you to create policies that apply to:
- Specific recipients
- Recipients who are members of a group
- Recipients within a domain
Finish up by reviewing your settings and then creating the policy. If you have multiple policies you can adjust their priority to determine which order they're processed in. Having fewer policies would be easier to manage though.
To show the anti-phishing policy in action, I used the PowerShell Send-MailMessage cmdlet to send an email to my tenant from [email protected]çs.biz. For the sake of demonstration I configured the policy to send the emails to the junk folder where I could get to them easily. The junked email has the phishing protection tip inserted, as you can see in the screenshot below.
As a new feature, we can expect ATP anti-phishing policies to continue to evolve as new threats emerge. If you have Office 365 ATP, I recommend you start testing anti-phishing policies as soon as the feature arrives in your tenant.
Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
I sent the link to this to someone else who uses ATP and SafeLinks marked your site as malicious! On his response back to me, my ATP marked the email as phishing because of the link in the email. Guess nothing is perfect out there.
My ATP doesn’t mark the site malicious so either different regions are behaving differently, or that tenant has added my URL to their Safe Links block list. Either way, yes, nothing is perfect.
His reply back to me was blocked by my safelinks as well, so it may be regional as you said. I’ll follow up with MS.
Either way – great info!
We don’t subscribe to EOP or ATP. But, in the past week and a half have had an enormous increase in false positives sending legitimate emails to junk, often with the message “Phishing attempt detected.” Do you suppose our issues are related to the new features in your post?
If you use Exchange Online then you have EOP. If you haven’t reviewed your EOP policies, that would be a good starting point. If you’re still having higher than acceptable false positives, open a support ticket with Microsoft. They are constantly tuning their detections for what is happening in the threat landscape, and if they’re getting it wrong then they need to know.
Will this help detect bogus DocuSign/DropBox/etc emails? We get such things all the time, and it can be difficult for end users to notice the subtle clues that the link is NOT a valid address for the service (DocuSign/DropBox/etc).
Possibly, if you choose to protect those domains as well.
You might also find it’s useful to construct some mail flow rules that detect those phish emails based on keywords and SPF/DKIM/DMARC results. For example, if the email contains the word Docusign but does pass SPF/DKIM/DMARC, insert a warning into the message that it may be a phishing attempt (or filter/quarantine accordingly).
Edit: you’d need to check that the DKIM signature contained the correct domain as well, because an attacker can still send a DKIM signed message using another domain.
Thanks for this excellent overview and short but concise walkthrough on configuring the policy
how we can test this with send-message?
If you have a mailbox called “Payroll” but it has proxyAddresses attached to the mailbox called HR, Talent, Careers etc or say a “Finance” mailbox with Accounts, Debtors, Creditors etc they don’t appear in the dropdown as addresses to protect, but I am wondering would they not be needed because if a Phisher emails [email protected] it would get resolved to Payroll anyway?
Good question. I’m not sure, but I assume the mailbox and all its aliases would be protected. If you also add the domain to be protected, that should also help.
An email destined for one of the proxyAddresses aliases ends up in the mailbox in question, so you would just set said mailbox to be protected.
Hi.
From a licensing point of view, I guess it is the users you are procecting that requires the ATP license – Is this right ?
I don’t answer licensing questions like this. You should ask your license reseller.
when i tried to send-message from powershell it provides me error message ” mail box not available. we have the rule setup but we are not able to test it, How we can test this feature once enabled
Send-MailMessage works fine for me. Without know more details there’s not much I can say to help you.
This is the error message
Send-mail message : Mailbox unavailable. the server response was 5.7.60 smtp client does not have permission to send as this sender
Looks like the address that you’re trying to send from is one that you do not have SendAs permissions for.
we have configured atp policy antiphising in our domain. it worked one time but after that it does not worked.
we have mentioned to protect our gmail address and delivered address to our domain address. it does not protect any emails and it delivered to our inbox instead of junk email box
I do not understand what you’re saying, sorry.
I’m considering incorporating the anti-phishing feature into our environment. Do you recommend applying different actions for impersonated users versus impersonated domains?
I’ve set my policies and my customers to be the same action as I can’t think of any specific need to handle them differently. Perhaps some scenario will emerge in future that changes my mind.
Do you know what difference adjusting the “Advanced phishing thresholds” makes? MS seems to have no documentation on this feature yet there are four levels available (Standard + three more aggressive ones).
I haven’t found any support docs explaining the different thresholds yet.
Another question: Since 2017 we’ve been using an undocumented feature to increase the Phish sensitivity using an Exchange transport rule to set “MS-Exchange-Organization-PhishThresholdLevel” to a level of 2 (now publicly documented by MS here: https://blogs.technet.microsoft.com/undocumentedfeatures/2018/05/10/atp-safe-attachments-safe-links-and-anti-phishing-policies-or-all-the-policies-you-can-shake-a-stick-at/#LowerPhishingThreshold).
When enabling the new Anti-Phishing functionality, should that transport rule stay, or should it be removed? I can’t tell from email headers if the new functionality is doing anything at all; all I see is the MS-Exchange-Organization-PhishThresholdLevel set to 2 on all messages. We had no negative effects to having the transport rule in place for our more frequently targeted users, and so have since expanded the rule to cover all users, so I would like to keep it if it complements the new defenses, but not if it negates the new defenses.
Tough one, because mail flow rules are assessed before ATP processing. You might consider excluding a group of pilot users from that mail flow rule, and then analyze the messages they’re receiving. But unless they’re getting bombarded with phishing emails, I worry it’s going to be hard to measure the impact.
If “Quarantine message” is the selected action you mention that “this is the user-accessible quarantine, so they can still release and read the message”.
But I have noticed that phishing mails are not included in the Spam Notification report for the users. How would they be aware of blocked phishing mails in their quarantine?
We are using Exchange on-prem not Exchange Online, not sure if there is a difference in behavior.
Yeah. I am in EXO, and I do not get notified for phishing emails that get quarantined, though I can see them in my quarantine. I guess that makes sense, from a safety perspective. What would make even more sense is if the user couldn’t release their own phish emails, because users aren’t always the best person to make a judgement call on suspected phishing emails.
Thanks Paul.
It seems the behavior differs with on-prem Exchanges (non Hybrid).
We are using EOP just for the spam/malware protection and we also don’t get any notifications. But also when I login with a user account in the “Security & Compliance” center and select Quarantine I can select “Spam” and “Bulk” in the drop down but not “Phish”, therefore I also can’t release phishing mails with the user – simple because I can’t even see them. However if I use an Admin account I can see the quarantined phishing mails and I also can release them.
That’s an unexpected behavior because users are not informed about phishing mails, nor are they able to review them or release them. It seems the intention is that an admin reviews all phishing mails manually. A bold decision considering that ATP blocks a lot mails that are not SPF/DKIM authenticated.
Ill do some further tests and try to find additional information, maybe there is a possibility to change the behavior.
I created a Microsoft Case and got the confirmation that my observed behavior is correct: Users do not see phishing mails in the quarantine (only admins do).
Having anti-spoofing enabled this means an admin should regularly review all mails and update the spoof intelligence policy otherwise mails that might be legit but are not authenticated are blocked without anyone noticing.