Microsoft Defender for Office 365 Blog

12 MIN READ

Email Protection Basics in Microsoft 365: Spoof and Impersonation

Microsoft

Sep 20, 2022

Click here to view additional posts in this series. Would you like us to cover more topics? Let us know in the comments.

Microsoft Support is excited to continue this blog series to demystify how Microsoft 365 email protection works. Earlier, we covered how phishing has the potential to cause damage to an organization. Now, we’ll go over the two threat vectors most commonly seen in phishing attacks—spoofing and impersonation, and how Microsoft 365 protects your users against them. We will look at what spoofing and impersonation techniques are, the difference between them, and how your Microsoft 365 Defender policies apply protection against spoofing and impersonation in your organization to keep you secure from business email compromise.

You can customize all spoofing and impersonation controls in the anti-phishing policies in the Microsoft 365 Defender portal. To learn more, see Anti-phishing policies in Microsoft 365.

To jump right into all threat policies mentioned in this article, bookmark this direct link - https://security.microsoft.com/threatpolicy.

Spoofing protection

Knowing who the message is from is key to verifying if it is authentic. To simply explain sender verification, let’s start by knowing that there are two different types of “From” addresses – header From and envelope (SMTP). Our overview of email message standards explains this in detail, but one key takeaway is that email clients such as Outlook display only the header From address, not the envelope (smtp.mailfrom) one.

Exact domain spoofing

Exact domain spoofing refers to messages sent from a header From domain that does not belong to the sender. This domain can either be one of your Microsoft 365 domains, or a domain of another legitimate organization. Such messages where the attacker forges the domain to look exactly like the domain of the victim’s organization or like their business partner’s may trick the recipient into actions that lead to credential theft or variations of Business Email Compromise (BEC)* attacks, because they appear legitimate, but in fact originate from a malicious source.

Email authentication checks

Spoofing detection is part of email authentication checks on inbound messages within Exchange Online Protection and Microsoft Defender for Office 365. Email authentication protocols, such as Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC) work together to determine the legitimacy of the sender and their infrastructure and signatures.

When authentication fails, and the system detects the message as spoof, you will find CAT:SPOOF in the X-Forefront-Antispam-Report header, and the message will be marked as spam (SFV:SPM). The results of email authentication checks can be found in the Authentication-Results header of a received email.

To learn more about email authentication, see email authentication in EOP.

Example:

Authentication-Results:
spf=none (sender IP is 192.168.0.0) smtp.mailfrom=contoso.com; contoso.com; dkim=none (message not signed) header.d=none;contoso.com; dmarc=fail action=quarantine header.from=fabrikam.com;compauth=fail reason=000

X-Forefront-Antispam-Report
CIP:x.x.x.x;CTRY:DE;LANG:en;SCL:5;SRV:;IPV:NLI;SFV:SPM;H:contoso.com;PTR:InfoDomainNonexistent;CAT:SPOOF

The sender’s smtp.mailfrom domain (envelope) is contoso.com.
The sender’s header.from domain (header, or the domain displayed to the recipient in Outlook) is fabrikam.com.
A DMARC check compares the header.from and the smtp.mailfrom domain for a match. Here, it fails (dmarc=fail) since these two domains are different and there were no other signals to confirm that this message is from a legitimate sender domain – since neither the SPF nor DKIM records are published in DNS (spf=none, dkim=none).
Authentication failed, hence composite authentication result is marked as (compauth=fail). As such, this message is detected as spoofing.

Spoof intelligence

Spoof intelligence is our industry-first technology that uses advanced algorithms to learn a domain’s email sending patterns. This helps tremendously for senders that do not implement or enforce DMARC.

Spoof intelligence is enabled by default and is available for Exchange Online Protection and Microsoft Defender for Office 365. We highly recommend that you keep it enabled to filter email from senders who are spoofing domains.

Figure 1: Turn on spoof intelligence in the anti-phishing policy

Whenever spoofing is detected, action is taken based on the configuration in the anti-phishing policy and the message is either moved to Junk folder or is sent to Quarantine.

Figure 2: Spoof action selection in the anti-phishing policy

To learn more about anti-spoofing protection in Microsoft 365, see anti-spoofing protection in EOP.

Safe spoofing overrides

There are some situations where spoofing is legitimate. For example, an application you trust sends mail from (or as) one of your validated domains to your users, but the sending IP is never added to your domain’s SPF record in DNS, and the sending application does not sign messages with a DKIM signature. You can allow this type of spoofing, while regular spam checks continue to take place.

Note: This type of override is beneficial when the recipients are entirely in your organization. For better deliverability of messages outside of your organization, make sure to add the sending application information into the SPF record for your domain and/or sign these messages with DKIM. In general, it is highly recommended to publish SPF, DKIM and DMARC records for any domains you own and send email from.

To learn more, see set up SPF to help prevent spoofing, use DKIM for email in your custom domain, and use DMARC to validate email.

Tenant Allow/Block List spoofing controls

To control domains that you always want to allow to spoof (or block from spoofing), use the Spoofing tab in the Tenant Allow/Block List. Here, you can add a new domain pair. Domain pairs consist of a sender and where they are sending from. For more details, see domain pair syntax. This spoofing list never expires automatically unless you (as the tenant administrator) delete an entry explicitly.

Figure 3: Add new entries in the Spoofing tab in the Tenant Allow/Block List

Use Admin Submissions to report false positives and choose to allow similar spoofing activity

In part two of this blog series, we covered the importance of minimizing overrides and using Submissions in Microsoft 365 Defender in case of disagreements with Microsoft verdicts. It is now possible to add spoofing and impersonation overrides directly from Submissions. Note that spoofing and impersonation allows that you add this way do not expire, unless explicitly deleted by you (as the security administrator).

To enhance your ability to allow domains that are allowed to spoof (for false positive management), go to the Admin Submissions page and while reporting a false positive, select the toggle to allow emails with similar attributes. This step will directly add the domain pair to Spoofing tab in the Tenant Allow/Block List if the email was originally marked as spoof. Submissions also help the system learn better over time.

To learn more, see Admin Submissions.

Figure 4: Submit a false positive Spoof message using Admin Submissions

User impersonation protection

Note: Impersonation settings are available to organizations with Microsoft Defender for Office 365 Plan 1 or Plan 2, or Microsoft 365 Enterprise E5 licenses. For more information, see anti-phishing policies.

User impersonation refers to inbound messages which are sent from an external address, where the sender address or display name resembles a contact already in your organization. The main difference between impersonation and spoofing is that threat actors often register their own sending domain, instead of spoofing the target domain. This way, they pass e-mail authentication checks. Often, the impersonator attempts to trick the recipient into actions, such as wiring money, or opening malicious links and attachments. And like with spoofing, they count on the recipient’s previous relationship with the sender to gain their trust for a more authentic attack.

As phishing becomes more sophisticated, it is harder for your users to detect some impersonation variants just by inspecting the From address. For example, when an attacker uses international variants instead of English letters, you may recognize trαcy@contoso.com as an impersonated email address, but you are unlikely to spot the Cyrillic Small A (Unicode 0430) in trаcy@contoso.com with the naked eye. Impersonation protection detects all these and many other variations.

Examples:

User impersonation (email address): Instead of the legitimate michelle@contoso.com, the impersonator uses email address is rnichell@contoso.com.

User impersonation (display name): Instead of the legitimate Joe CEO <joe.ceo@contoso.com>, the impersonator sends as Joe CEO <fake@fabrikam.com>.

Mailbox intelligence-based impersonation protection

Mailbox intelligence-based impersonation protection uses artificial intelligence (AI) that determines a user’s email patterns with their frequent contacts. It detects impersonation based on each user’s individual sender map or graph. Also referred to as Graph impersonation, it flags anomalies of senders for which recipients have a previously established communications relationship. This means that if a message is received from a sender that appears similar to a frequent contact of the recipient (in either display name or email address) but is not the same sender, the message will be flagged for impersonation, and you will find CAT:GIMP in the message headers.

Figure 5: Mailbox intelligence-based impersonation protection in the anti-phishing policy

Example:

Mary, mary@fabrikam.com regularly exchanges emails with “John Contoso” <john@contoso.com>. John’s address and domain contoso.com are not set as targeted users or domains to protect in fabrikam.com’s anti-phishing policy. One day, Mary receives an email from “John Contoso” <john@cont0so.com> with a suspicious invoice attachment. The message is flagged with CAT:GIMP because the system detects this message came from someone similar to a sender that Mary frequently communicates with, but it is not the same person. Based on the setting configured in the anti-phishing policy, the respective action such as deleting the message before delivery or sending to quarantine or otherwise chosen, will be applied.

Figure 6: Mailbox intelligence based impersonated user action menu in the anti-phishing policy

To learn more about mailbox intelligence, see Impersonation settings in anti-phishing policies in Microsoft Defender for Office 365.

Specify users to protect from targeted impersonation attacks

User impersonation protection can protect up to 350 internal users in your organizations, as well as external users such as board members. This detection tremendously helps to protect users that are often targeted by impersonation attacks. When editing the setting in the anti-phishing policy, the users you would like to protect can be added under the Enable users to protect section:

Figure 7: Turn on Enable users to protect in the anti-phishing policy

All policy recipients of the messages will benefit from this protection, but only inbound messages that impersonate one of the users on this list will be marked as “User Impersonation”. We recommend adding high priority executives (such as CEO, CFO) to this list and other priority accounts such as key human resources or finance stakeholders, as well as external board members, more frequently targeted in such attacks.

Example:

Jane is the CEO of Fabrikam.com and is well known in the organization. To ensure that she is always protected from impersonation, “Jane Jones <jane@fabrikam.com” is added to the “Users to protect” list in fabrikam.com’s anti-phishing policy. After this, an attacker attempts to send an email to the head of IT department of Fabrikam to asking to reset Jane’s password. The email comes from “Jane Jone CEO <jane@fake.com>". Since the usernames are similar, the message is detected as user impersonation of Jane Jones.

In such cases, when Microsoft detects an email with a sender that is impersonating a user, you will find CAT:UIMP in the X-Forefront-Antispam-Report header. When that happens, Microsoft Defender for Office 365 will take action as configured in the appropriate anti-phishing policy. Note: in this case, the good news is that the system will flag user impersonation regardless of Mailbox intelligence learning the patterns, because the targeted user (Jane Contoso in this case) is specified as a user to protect within the anti-phishing policy. The action chosen in the policy will be applied.

Figure 8: Impersonated user action menu in the anti-phishing policy

Domain impersonation protection

Domain Impersonation will be flagged when the sending domain looks like a legitimate domain. The domain can either be one that you own and is validated (accepted) in your organization or belongs to a partner organization. For example, you have added and validated the domain contoso.com in your tenant, and you receive an inbound message from ćóntoso.com, or çontoso.com.

Domain Impersonation is also configured in the protection settings of an anti-phishing policy.

Figure 9: Turn on Enable domains to protect in the anti-phishing policy

When an inbound message is tagged as Domain Impersonation, you will see CAT:DIMP in the X-Forefront-Antispam-Report header. When this happens, Defender for Office 365 will take the action that is configured under domain impersonation settings in the anti-phishing policy.

Safe impersonation overrides

What happens if someone sends mail from their personal account to their work account, which is covered by impersonation policies? As an example, Joe is the CEO of Contoso and sends a message from his personal account joe@fabrikam.com, to his work account, joe@contoso.com. Both accounts use the same display name of “Joe CEO”. In this situation, the messages that Joe sends to himself from his personal account are likely to be marked as impersonation (CAT:UIMP) if the CEO is on the list of users to protect, or CAT:GIMP if they aren’t and if the system has determined no prior established communication patterns with that sender.

Since this sender address is only likely to send to the CEO’s own work account, and not to other company employees, add it as a trusted sender in the anti-phishing policy. This will override only the user impersonation check, while other components of the protection stack will scan the message.

If you often get CAT:DIMP verdicts for domains you trust, add them as trusted domains in the anti-phishing policy. Again, this will ensure that only the domain impersonation check is bypassed for these listed domains, and every other check in the protection stack proceeds as usual.

To learn more, see trusted users and domains in the anti-phishing policy.

Preset Security policies in Microsoft Defender for Office 365

In part two of this blog series, we went over Standard and Strict security policies – two simplified security configurations in Microsoft Defender for Office 365 and Exchange Online Protection. Impersonation and spoofing protections are included and enabled by default within these policies, which is beneficial for smaller organizations with simpler security requirements. Additionally, you will still want to specify selected custom domains and sender email addresses to protect against impersonation attacks often targeted towards them.

Learn more about preset security policies and their order of precedence.

Important: Part one of this blog series covers how Microsoft 365 Defender policies can be customized and scoped (limited) to include or exclude message recipients (users, groups and domains). If you use multiple anti-phishing policies, only a single policy can apply to a recipient with all its chosen actions and overrides. Ideally, you would not configure any overlapping policies, but if you do, only the top priority policy will apply for a recipient if they’re added to two or more policies. Priority “0” is the highest.

Figure 10: Review the priority of anti-phishing policies

Monitor spoofing and impersonation in your organization

Spoof intelligence insight

For senders who had previously sent spoofed email into your organization, start your triage with this insight in the Tenant/Allow Block List, or using direct link https://security.microsoft.com/spoofintelligence. You can view the list of spoofed users and decide whether to allow a sender to spoof or block them from spoofing.

Figure 11: Review the list of spoofed domains in the spoof intelligence insight

Figure 12: Select an action from the spoof intelligence insight

Note: When you configure an allow or block entry for a domain pair in the Tenant Allow/Block list, messages from that domain pair no longer appear in the spoof intelligence insight.

Impersonation intelligence insight

Similarly, you can use this insight to monitor potentially impacted email by user and domain impersonation and fine-tune your anti-phishing policies and overrides based on your review.

Open the impersonation intelligence insight directly: https://security.microsoft.com/impersonationinsight

Figure 13: Impersonation intelligence insight in Microsoft 365 Defender

Tip: Review both insights periodically to understand the scope of spoofing and impersonation that occur in your organization, and to take the appropriate actions timely. This will help you to prevent spoofing and impersonation in your organization, as well as to improve delivery of messages in case of false positive or false negative adjustments you need to make based on your tenant’s email activity.

Help your users with visual cues and insights for self-detection

Your defense-in-depth strategy wouldn’t be complete if you do not consider how users in your organization interact with email. In part two of this blog series, we’ve covered how to identify and train vulnerable users with attack simulation training, and recommended reporting false positives and false negatives to Microsoft. If your employees are your last line of defense against email-based threats, displaying visual cues with relevant message and sender insights are essential to the overall security posture of your organization.

Safety tips and indicators

Safety tips related settings are available within anti-phishing policies and are highly recommended. They help users self-detect and understand if there is something unusual about the sender.

Figure 14: First contact safety tip in Outlook on the Web

Figure 15: Turn on safety tips in the anti-phishing policy

Note: User and domain impersonation safety tips are only available to users of Microsoft Defender of Office 365.

Enable external sender callouts in Outlook

Many organizations have configured a mail flow (transport) rule to add a banner to an email to tell the recipient that the email has been sent by an external sender. This was a visual indication of caution for your employees before they interacted with senders outside of your organization. You can now configure this rule natively in Outlook. Learn more about native external sender callouts on email in Outlook, and enable external sender identification with the PowerShell cmdlet, Set-ExternalInOutlook.

Figure 16: External sender callouts in the new Outlook

We hope this article helped you understand how spoofing and impersonation protections work in Microsoft 365, which policies and settings control them, what safe overrides to use if you trust senders or disagree with original Microsoft verdicts, and how to help your users differentiate between good senders from impersonators with visual cues.

Note: For additional information about Business Email Compromise (BEC), read the three-part blog series, Business Email: Uncompromised. It details how spoofing and impersonation techniques are used in single-stage and multi-stage BEC attacks, and how Microsoft Defender for Office 365 in partnership with the Microsoft Digital Crimes Unit disrupt them to protect your organization.

Important resources