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 firstname.lastname@example.org) 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 payroll@globomantiç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 payroll@globomantiç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.