Create a Custom Quarantine Notification with Your Own Text

A question in the Office 365 Technical Discussions Facebook group asked about customizing the email received by users when messages sent to them end up in the quarantine. These messages inform users that quarantined messages require their review to decide whether to release or remove the items. When a user releases a message, the action is a signal to Exchange Online Protection that the decision to quarantine the message is a false positive. Depending on how you configure Exchange Online Protection, different amounts of email end up in quarantine. For instance, my experience of blocking user safe sender lists in favor of using tenant-wide blocks is that Exchange Online Protection quarantines more messages.

Tenants can update the global quarantine settings to customize the standard message form used to send information about quarantined messages. The GUI in the Microsoft Defender portal (Figure 1) allows tenants to create customized notifications for up to three languages. On the surface, filling in the different values and saving them seems easy, but despite many attempts, it never worked for me.

I’m not saying that the problem lies with the Defender portal. It is entirely possible that I did something silly and continued doing the same thing with the same effect: the only change to the notification message was the substitution of the Microsoft logo with the logo used in the Microsoft 365 theme for the organization.

Updating Custom Quarantine Notification Settings with PowerShell

Where there’s a will, there’s a way. Reading further inti the documentation, we discover that it’s possible to update the settings with PowerShell. The exact syntax is a little funky because the Set-QuarantinePolicy cmdlet barfs if you don’t update all the settings for a selected language. And if you update the setting for one language, make sure that you update settings for all the languages used in the tenant. Unfortunately, the documentation is not as clear as you’d like it to be when updating just the default language settings through PowerShell, but some experimentation soon arrived at the right formula.

Here’s what I ran to update the default settings:

Get-QuarantinePolicy -QuarantinePolicyType GlobalQuarantinePolicy | Set-QuarantinePolicy -MultiLanguageSetting ('Default') -MultiLanguageCustomDisclaimer ('For more information, contact the wonderful Help Desk.') -ESNCustomSubject ('Quarantined messages are waiting for your review') -MultiLanguageSenderName ('Office 365 administrator') -EndUserSpamNotificationCustomFromAddress customer.services@office365itpros.com

After running Set-QuarantinePolicy, you can check the updated settings by running Get-QuarantinePolicy: People who use Microsoft 365 in U.S. English will see the custom values in quarantine notifications after the service percolates the new values across the mailbox servers that handle traffic for the tenant.

Here’s another example. In this instance, we update the default and two other languages (you select the languages and provide the translated values) with values passed for each language:

Get-QuarantinePolicy -QuarantinePolicyType GlobalQuarantinePolicy | Set-QuarantinePolicy -MultiLanguageSetting ('Default','French','German') -MultiLanguageCustomDisclaimer ('For more information, contact the wonderful Help Desk.','Pour plus d`'informations, contactez le merveilleux Help Desk.', 'Für weitere Informationen wenden Sie sich bitte an den wunderbaren Helpdesk') -ESNCustomSubject ('Quarantined messages are waiting for your review','Les messages mis en quarantaine attendent votre examen', 'Unter Quarantäne gestellte Nachrichten warten auf Ihre Überprüfung') -MultiLanguageSenderName ('Office 365 administrator','Administrateur Office 365', 'Office 365-Administrator') -EndUserSpamNotificationCustomFromAddress customer.services@office365itpros.com

As I am in Ireland, the changes made to these languages didn’t help me one iota. The trick is to configure “English” as a language (or English_Great Britain as shown by the Defender portal). I removed French and German and added English, ending up with this configuration:

Get-QuarantinePolicy -QuarantinePolicyType GlobalQuarantinePolicy  | Format-list enduserspamnotificationcustomfromaddress, esncustomsubject, multilanguagecustomdisclaimer, multilanguagesetting

EndUserSpamNotificationCustomFromAddress : customer.services@office365itpros.com
EsnCustomSubject                         : {Quarantined messages are waiting for your review, You have somequarantined messages to deal with}
MultiLanguageCustomDisclaimer            : {For more information, contact the wonderful Help Desk., Quarantined messages might be not what you think they are...}
MultiLanguageSetting                     : {Default, English}

And Then Everything Clicked for Custom Quarantine Notifications

For whatever reason, fiddling around with PowerShell to update languages seemed to do the trick and the Defender portal started to co-operate (Figure 2). I can’t account for why this should happen, or if it will happen in another tenant.

Through the magic of PowerShell, Irish users now receive custom quarantine notifications (Figure 3). I am chuffed that one of the first notifications to arrive in a custom form concerned email received from Paul Robichaux, a well-known doubtful personality in the Exchange world. Clearly Exchange Online Protection is focused on Paul’s activity.

Baffled and Bemused

I wish I knew why I was initially unsuccessful at persuading the Defender portal to accept my attempts at customizing quarantine notifications. Thankfully, the PowerShell route eased my way to eventual success, but having an unexplained mystery always leaves me baffled and bemused, and that’s not a great place to be. It could just be the difference between English and English.…

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

New Author to Handle Mail Flow Issues Like Impersonation Protection

We are delighted to announce that Michel de Rooij has joined the Office 365 for IT Pros eBook team as the author responsible for the Mail Flow chapter. Michel is a Microsoft MVP for Office Apps and Services, and a senior consultant at Rapid Circle, a Microsoft partner in the Netherlands. He has extensive experience in designing, implementing, and managing Exchange and Office 365 environments for various customers. You can contact Michel through his blog or Twitter.

Michel takes over from Gareth Gudger, who has been a valuable contributor to the Office 365 for IT Pros eBook for several years. We thank Gareth for his dedication and the care he lavished on the Mail Flow chapter, and we wish him all the best in his future endeavors.

Practical PowerShell

Apart from his expertise with Exchange, Michel is a PowerShell wizard. He’s started to share his experience in a new “Professional PowerShell” column published on Practical365.com. Starting with the March 2024 update (monthly update #105), I’m sure that Michel will look for opportunities to use his PowerShell talents to automate some common mail flow operations over the coming months.

Automating Impersonation Protection

For example, I’m a big fan of the impersonation protection settings in anti-phishing policies (available when a tenant has Microsoft 365 Defender for Office 365). Impersonation protection allows tenants to protect up to 350 internal or external email addresses against impersonation attempts. When Microsoft first introduced impersonation protection in late 2020, policies were limited to just 60 addresses, so the bump to 350 is appreciated.

Basically, this happens when spammers send email from addresses that are very close (usually just one character different) to a real address. For instance, Kim.Akers@office365ltpros.com instead of Kim.Akers@office365itpros.com.

Although there is a GUI option to update the list of protected users (Figure 1), to automate the process, I use an Azure Automation runbook that executes a scheduled job every Saturday. The job:

• Signs into Exchange Online using a managed identity.
• Finds the set of mailboxes with a custom attribute set to “VIP.”
• Creates an array of mailbox display names and user principal names in the format used by anti-phish policies.
• Updates the default anti-phish policy with the new list.
• Checks that the updated policy protects the expected number of mailboxes and declares success.

Here’s the basic PowerShell code executed by the scheduled job:

[array]$PhishUsersToProtect = $null
# Find the set of mailboxes to protect
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -Filter {CustomAttribute1 -eq "VIP"} -Properties CustomAttribute1 | Select-Object Displayname, UserPrincipalName
# Create an array in the required format with details of protected users
ForEach ($User in $Mbx) {
  [string]$UserAdd = ("{0};{1}" -f $User.DisplayName, $User.UserPrincipalName)
  $PhishUsersToProtect += $UserAdd
}

# Find the default anti-phish policy
$DefaultPhishPolicy = Get-AntiPhishPolicy | Where-Object IsDefault -match $True

# Update the set of protected users in the policy if there are less than 350 mailboxes
If ($PhishUsersToProtect.count -lt 350) {
    Set-AntiPhishPolicy -Identity $DefaultPhishPolicy.Identity -TargetedUsersToProtect $PhishUsersToProtect -EnableTargetedUserProtection $true
    [Array]$TargetedUsers = Get-AntiPhishPolicy -Identity $DefaultPhishPolicy.Policy | `
        Select-Object -ExpandProperty TargetedUsersToProtect
    Write-Host ("Policy {0} now protects {1} mailboxes" -f $Policy.Identity, $TargetedUsers.count)    
} Else {
  Write-Host ("{0} mailboxes identified for protection but the maximum supported is 350" -f $PhishUsersToProtect.count)
}

Functional Not Professional PowerShell

Of course, my PowerShell code is not polished. It’s functional rather than professional PowerShell. But now that the Office 365 for IT Pros eBook author team has a real pro on staff, I’m sure that the quality and beauty of the code featured in the book (well, at least in the Mail Flow chapter), will improve dramatically.

Learn more about how Exchange Online and the Microsoft 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Now Generally Available for Microsoft Defender for Office 365 Customers

The July 27 announcement of the General Availability of Safe Links for Teams is a welcome development. What it means is that if your tenant has Microsoft Defender for Office 365, you can update your Safe Links policy to include real-time checking of links posted to Teams chats and channel conversations.

Licensing Requirements

Licensing Microsoft Defender for Office 365 can be a little confusing. Two plans are available, both of which build on Exchange Online Protection (EOP):

• Office 365 E3 and below have Exchange Online Protection. These tenants can license Defender for Office 365 plans as standalone options.
• Microsoft 365 Business Premium includes EOP and Defender for Office 365 Plan 1.
• Office 365 E5/A5 and Microsoft 365 E5 includes EOP and Defender for Office 365 Plan 2.

Microsoft sometimes refers to the “security ladder from EOP to Microsoft Defender for Office 365” as a way of describing how the features in the Defender plans build on what you get in Exchange Online Protection (Figure 1).

In this case, you need at least Microsoft Defender for Office 365 Plan 1 to use Safe Links protection for Teams.

Configuring Defender for Teams

The Safe Links policy is managed through the Policies & rules section of the Microsoft 365 security center. To edit the policy, open Threat policies and select Safe Links. The important change is to set Select the action for unknown or potentially malicious URLs within Microsoft Teams to On (Figure 2).

At the same time, you should review the other Safe Links policy settings to make sure that they’re what you want. Three important settings used to detect and protect against malicious links in email also apply to links in Teams messages:

• Apply real-time URL scanning for suspicious links and links that point to files. In other words, before sending a user to a site, check that the link is not dangerous. If it is, display a warning.
• Do not track user clicks. This setting is normally off and isn’t needed unless you want to track user clicks against links.
• Do not allow users to click through to original URL. If a user clicks on a dangerous link, they see a warning page (Figure 3). You don’t want to allow people to click through the warning to open the dangerous page, so make sure that this setting is on.

You can also see in Figure 2 that I’ve opted to use organization branding on the warning page. The branding used here (and shown in Figure 3) is taken from the tenant’s browser theme.

Usually, Teams calls the default browser to open a web link and that’s when Defender steps in to display the warning page. If a malicious link is used in a channel tab (which means that someone has created a web site tab for that link), Teams opens the warning page in the tab and doesn’t call the browser. If Defender passes the link as safe, Teams opens the page as normal.

Nice Extension into Teams

It’s good that Microsoft has extended Safe Links protection into Teams. Although I suspect that most bad links will continue to arrive in user mailboxes (if not detected and placed in quarantine by Exchange Online Protection), it’s entirely possible that some users will share problematic links through Teams chats or channel conversations. If they do, and your tenant has Defender for Office 365 with a properly configured Safe Links policy, those links will be blocked. What’s not to like about that?

Learn about protecting Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

Now Circulating to an Inbox Near You

The value of enabling the first-time safety tip and external tagging of email is evident in a new phishing attempt that’s now circulating. The attack purports to be email delivering a document relating to an invoice payment (Figure 1). The message is tagged as external and the first-time safety tip is obvious. The attacker uses a classic technique of attempting to lure the recipient into clicking a link to download a document. Naturally, this brings the user to a place they don’t want to visit and shouldn’t go.

The email comes from an Office 365 tenant (easystreetdotnet.onmicrosoft.com), which I assume has been either hijacked or set up by the attacker. Because it’s valid email and comes from an Office 365 tenant, the email passes anti-spam and anti-malware checks and therefore reaches user inboxes.

The View completed document link in the message brings users to b24-r98mpq.bitrix24.site (an unlikely site address for legitimate documents).

Report Phishing Messages

I used the Reporting Phishing add-in for Outlook to send a copy of the message to Microsoft for their security analysts to review and action. In the meantime, keep an eye out for similar messages which might arrive in your tenant and consider:

• Installing the external tagging and first-time safety tip features in Exchange Online.
• Deploying the Report Phishing add-in to users.

Anti-Phishing, Defender, and Impersonation

Updated June 15, 2021

Microsoft Defender for Office 365 is the new name for what used to be called Advanced Threat Protection (ATP). While Exchange Online Protection includes anti-phishing policies to stop phishing attempts like this recent example, Defender extends the anti-phishing policy with impersonation settings (Figure 1).

Impersonation is where an inbound email appears to come from a sender or domain that is known but is slightly different, such as email from Micriosoft.com. It’s done to lure the recipient into a false sense of security that the email they receive originated from a trusted sender or domain whereas it’s an attempt to hoodwink them into doing something bad, like revealing confidential information.

The impersonation settings in anti-phishing policies allow tenants to define up to 60 protected email addresses (per policy) which are then subject to checks to pick up attempts at impersonation. The checks only work if the sender has never communicated with the recipient before. If an attempt is detected, policy settings determine what happens next, such as moving the message to Junk Email.

Safety Tips Highlight Potential Problems

Exchange Online Protection uses safety tips to highlight potentially problematic messages to users. For example, Figure 2 shows a safety tip for a message where the sender’s address could not be verified because the message failed both DKIM and DMARC tests upon arrival into Office 365.

Figure 3 shows an example of an impersonation safety tips. Microsoft Defender has identified that the email address of an inbound message is similar to an address used by a regular correspondent, so the fact is highlighted.

Enabling the First Contact Safety Tip with a Mail Transport Rule

The initial method to implement the first contact safety tip was through a mail flow (transport) rule which inserts the X-MS-Exchange-EnableFirstContactSafetyTip x-header into external messages. The presence of the header causes Microsoft Defender to generate a safety tip if the sender has never sent email to the recipient before. The mail flow rule is very straightforward. It applies to all inbound email and applies the x-header to those messages (Figure 4).

Note: An earlier version of this post used True as the value for the x-header. Exchange engineering have advised that the x-header should be set to Enable.

The effect of the mail flow rule is shown in Figure 5. The documentation says “Specific safety tips will be displayed notifying recipients that they often don’t get email from the sender or in cases when the recipient gets an email for the first time from the sender.” This implies that different text is used when a message is received from someone for the first time. However, I have only ever seen safety tips saying that “You don’t often get email from…”

Even though the first contact safety tip is connected to impersonation prevention, it’s not covered by the same licensing requirements. The safety tips appear on messages sent to mailboxes which don’t have Microsoft Defender for Office 365 licenses.

Updating the Anti-Phishing Policy

In June 2021, Microsoft announced (MC262087, June 14, Microsoft 365 roadmap item 82052) that an update to the anti-phishing policy rolling out in late June allows administrators to configure a policy setting to force display of the first contact safety tip. When the update is available you can continue using the mail transport rule and do nothing or update the anti-phishing policy through the Security and Compliance center to select the Show first contact safety tip. This is a welcome step because it makes it easier for inexperienced administrators to enable the safety tip for users.

Warning Users is Goodness

If your tenant has Microsoft Defender for Office 365 it’s a good idea to create and use the mail flow rule recommended by Microsoft. There’s no downside and it could stop someone falling victim to an phishing attempt in an email received from someone who seems to be like a person that the recipient is used to receiving messages from. Warning people of potential problems is pure and simple goodness!

Keep up to date with change inside Exchange Online and the other Office 365 apps by subscribing to the Office 365 for IT Pros ebook. We update the book monthly to make sure that our subscribers have the latest news.

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).

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.

Stop Forwarding Email Outside Exchange Online

There’s no doubt that automatically forwarding messages to an email address outside Office 365 can pose a significant risk for a business. Messages can end up in places where they shouldn’t go, including when an attack infiltrates an account and sets up forwarding on a mailbox by setting a mail forwarding address or with an inbox rule. In addition, removing email from Exchange Online compromises compliance and oversight because messages are no longer available for eDiscovery.

Various techniques exist to combat the problem, including:

• Restricting the ability of users to set forwarding addresses in OWA.
• Applying more general restrictions to block forwarding to specific domains.
• Blocking email forwarding from Power Automate (Flow).

These techniques work and all allow users to manually forward individual messages, but administrators must be aware of the problem caused by automatic forwarding and act to stop it. What’s different now is that Microsoft is making automatic forwarding more of an opt-in feature rather than forcing tenants to block automatic forwarding (roadmap item 63831) and make organizations more secure by default.

In some ways, it’s like the approach taken to disable basic authentication for Exchange connection protocols. Start by showing disapproval of something which contributes to insecure tenants and gradually escalate to close the hole.

Tuning Mail Forwarding in the Default Ant-Spam Outbound Filter Policy

A series of Office 365 notifications posted to the message center, starting with MC218984 (July) and more recently MC221113 (September), advised tenants of a change to the default outbound spam filter policy. The default outbound spam filter policy is present and active in all Exchange Online tenants.

First, Microsoft introduced automatic forwarding settings for anti-spam policies. The settings were inactive but allowed administrators to define how they wanted forwarding to happen. Tenants identified as having mailboxes with autoforwarding enabled also received notification that they had some work to do to decide how to handle these forwards. The next step was to enable the forwarding setting in the default anti-spam outbound policy using On as the Automatic (default) setting, meaning that mail forwarding acted as before.

This week, Microsoft changed the Automatic setting to Off to block mail forwarding. If you didn’t choose a different setting (possibly because you missed the notification), the Automatic setting is active. Some administrators overlooked the previous communications and were surprised when users began to report that forwarding doesn’t work. Life is full of surprises!

Mail Forwarding Settings

The available settings in anti-spam outbound policies to govern mail forwarding (Figure 1) are:

• Automatic: Exchange Online decides if mail forwarding is allowed or not. This is the default setting and normally means that users cannot forward email from Exchange Online mailboxes to external addresses.
• On: Users can forward email.
• Off: Users cannot forward email. Exchange will not change this value.
  

If automatic mail forwarding is blocked, users can still configure a mail forwarding address through OWA options (which is a good reason to remove the option from OWA) or create an inbox rule to redirect messages to an external address, but any attempt to send a message to that user which results in an attempted forward is rejected by the transport service and won’t be delivered. The sender receives an NDR to let them know about the problem (Figure 2).

The key thing for administrators to note is the NDR code: “5.7.520 Access denied. Your organization does not allow external forwarding.” Once you see this, you know a message was blocked by the outbound spam filter policy.

Allowing Automatic Forwarding for Specific Users

The default outbound spam policy is always active and cannot be disabled. If you want to stop mail forwarding in general and allow it for specific people, you should create a custom outbound spam filter policy and add the people and distribution lists to that policy. As you can see in Figure 3, SMTP addresses are used to specify people and distribution lists, not display names.

A Good Change to End a Bad Practice

There’s not much to argue about in this change. Automatically forwarding mail to an external address is not good practice. If someone really needs to forward email to an external address, they should be able to quantify the need in terms of a business justification to be added to a custom outbound spam filter policy. I doubt that many will be able to come up with such a justification, but those who do will be able to continue while the rest of the organization remains just a little bit safer.

Need to know more about the various policies used by Exchange Online to manage mail transport? It’s all described in the Office 365 for IT Pros eBook.

Crude Attempt That Could Trap the Unwary

With an increasing number of people using services like Teams for voice communications, scammers are trying out new ways to lure unsuspecting victims to click phishing links. One example is the message I received on Wednesday (Figure 1) purporting to let me know that a voicemail is waiting.

The message is a pretty crude attempt to convince anyone that it is a real voicemail notification. “Office VoIP” is used instead of a more believable service name (like Teams, Office 365, Microsoft 365) and the text contains spelling and grammar errors. The Play Voice Message button is clunky and the message comes from an account featuring three exclamation marks in its display name and an SMTP address of sam@v.c.smcozp.com.

Domain Built for an Attack

Looking up the domain with WhoIS, we find that it was registered on October 26 with Amazon.com. The message header tells us that the email came from a7-35.smtp-out.eu-west-1.amazonses.com, probably an SMTP server in a Western European datacenter that’s part of Amazon’s simple email service. In short, the domain was set up with the intention of being used for phishing attacks.

Outlook’s message header analyzer also tells us that the message passed Exchange Online Protection’s mail authentication anti-spam checks. The SPF pass is because the message came from a server authorized to send by Amazon. DKIM signature validation worked and DMARC’s result was a best guess pass.

spf=pass (sender IP is 54.240.7.35) smtp.mailfrom=eu-west-1.amazonses.com;; dkim=pass (signature was verified) header.d=v.c.smcozp.com;; dmarc=bestguesspass action=none header.from=v.c.smcozp.com;compauth=pass reason=109

The link to play the purported voicemail looks as if it will access a PDF file. I didn’t bother going any further.

url=https%3A%2F%2Fa.spiceworks.com%2Fcore%2Fclick%2F%3Facct%3Dm81-email%26direct%3Dtrue%26rt%3Dhttp%3A%2F%2Fej-group.com.my%2Ft-11-h11-v11-m11%2FdG9ueS5yZWRtb25kQHJlZG1vbmRhc3NvY2lhdGVzLm9yZw%3D%3D%2523%23c11c11n11b11k11u11o11b11.pdf&data=04%7C01%7Csome.person%40xxx.org%7Ce9645dd15a7f42495f0608d87b27fab9%7Cb662313f14fc43a29a7ad2e27f4f3478%7C0%7C0%7C637394760921548631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=pJw%2BgCh2QxgfeIIgLeU7rkHvGJHQcbuwDDolW7lB6UY%3D&reserved=0

I’ve reported the message to Microsoft so that they can take steps to block future attempts from the same source. Outlook’s Report Message add-in makes this very easy.

User Education

The problem with messages like this is that people often don’t look at the sender name or domain, question why large commercial organizations send poorly constructed messages, or even why they might be receiving such a message. The fear of losing out syndrome is exploited by attackers who rely on curiosity to lead people to click links. All we can do is continue to educate users to be careful and mistrust messages received from unknown sources.

For more information on running effective message hygiene defenses (a jazzy name for anti-spam), read Chapter 7 of the Office 365 for IT Pros eBook.

Exchange Online Protection Puts Problem Messages into Quarantine

In a previous post, we cover the basics of reviewing email quarantined by Exchange Online Protection using the Security and Compliance Center. As discussed there, it’s important to review quarantined email to understand if any messages which shouldn’t be blocked are trapped there waiting for release. No one wants to have an important message expire in the quarantine (after 15 days by default) and not get to its intended recipient.

The problem is the time needed to review quarantined messages for a busy tenant. Scrolling up and down a large list to decide whether to release messages can consume hours, especially if you don’t allow users to release quarantined email.

PowerShell Can Help

Exchange Online includes several cmdlets to work with quarantined messages. It might be easier to run a daily job to grab details of what’s waiting in the quarantine, do some basic analysis, and create a CSV file of the messages that can be reviewed. Any messages that shouldn’t be released can be removed from the file, and the remainder released for delivery.

Scripting Quarantine Analysis

I created a script (downloadable from GitHub) to illustrate the principal. The script fetches details of messages in quarantine using the Get-QuarantineMessage cmdlet and populates a PowerShell list with details of each message. You could use the output of Get-QuarantineMessage directly, but this approach allows for some additional processing of each message, such as extracting its source domain and calculating how long more it will remain in quarantine.

We then use the list to do some basic analysis to find out why messages are being quarantined, who’s receiving these messages, and where the messages come from:

$Report | Group Type | Sort Count -Descending | Format-Table Name, Count
Type of Quarantined messages

Count Name
----- ----
   10 Spam
    5 Phish
    3 HighConfPhish
    1 Malware

Messages quarantined per recipient address

Finally, we export the messages to a CSV file. The intention here is that someone can review the list of messages and decide which to release for onward delivery. All other lines in the CSV file are removed. To release the messages, we can then import message details from the CSV and use the Release-QuarantineMessage cmdlet to release them:

Import-CSV c:\temp\QuarantinedMessages.csv | Release-QuarantineMessage -ReleaseToAll

It’s all very straightforward PowerShell so you can customize it to add whatever idea you think is valuable. For instance, you could email the CSV file to reviewers.

Simple ideas can be the best. And applying PowerShell to solve problems is a simple idea that works well in lots of places within Office 365. Which is why the Office 365 for IT Pros eBook includes so many examples of PowerShell in action.

A Daily Task, Sometimes Overlooked

Checking the set of messages Exchange Online Protection (EOP) places in quarantine is not always a high-priority daily activity for most tenant administrators.. Opening the Security and Compliance Center to browse the set of quarantined messages (Figure 1) might be on the list of good things to do, but maybe also one of the tasks which is done when time and other tasks allow.

The point to remember is that some messages EOP quarantines are valuable. If you don’t rescue these messages within 15 days (the period set in the default spam filter policy), they disappear and will never be delivered, and that might be a bad thing.

User Notifications

One way to remove the burden on administrators is to configure the spam policy to generate end-user notifications. Users will then receive email according to a schedule set in the policy when spam or phish messages arrive for their account (Figure 2). The idea is that the user will know better than anyone whether a message is good or not. Unfortunately, without training and updates about recent spam techniques, this is not always the case, and some organizations disable the option because of the load it creates for the help desk.

Reviewing Quarantined Messages

If you examine the details of quarantined messages, you’ll discover why EOP considers them suspect. Each quarantined message is assigned a reason why EOP stopped its delivery to the destination mailbox(es):

• Bulk: EOP suspects that the message is commercial bulk email.
• Policy: The message matched the conditions of a transport rule (also known as a mail flow rule).
• Phish: EOP suspects the message to be a phishing attempt.
• High Confidence Phish: EOP has extra reasons to suspect the message to be a phishing attempt.
• Malware: EOP suspects the message to contain malware.
• Spam: EOP considers the message to be plain old spam. Regretfully, EOP sometimes thinks email from Gumroad.com is spam, which is why some of our subscribers don’t receive receipts or news about book updates.

Many factors combine and contribute to EOP deciding that a message is problematic. The sender or the sender domain could be a known spammer. The content of the message might contain clues (lots of hyperlinks is often deemed suspicious) or an attachment that might redirect the unwitting to a site. EOP uses tons of machine learning, artificial intelligence, and information gathered from around the internet to make the decision to quarantine. Most of the time EOP’s suspicions are well justified and accurate, and sometimes they fail, which is why it’s important for humans to review quarantined email.

Take the message shown in Figure 3. EOP regards the message to be potential phish. The sending domain is eliophot.com, a French marketing company specializing in the hospitality industry. This fact, allied to previewing the message and noting the return address as that of a valid hotel in the South of France, means that it’s likely this message is OK and has been blocked because of the number of hyperlinks in the text.

If we believe everything’s OK with the message, we can release it using the Release message button and EOP will deliver the message to the recipients. If you want to delete the message, click Remove from quarantine.

A More Complex Case

When I scan quarantined messages, my attention is always drawn to those marked as high confidence phish. As the name implies, these are messages that EOP considers to be very suspicious. And sometimes things conspire to throw EOP off the scent. Take the message shown in Figure 4, which is a notification sent from Amazon when someone signs into one of their services, like the Kindle Direct Publishing (KDP) service we use to create the Kindle version of the Office 365 for IT Pros eBook.

In this case, the message identifier tells us that the email came from Amazon’s Simple Email Service domain, which is what you’d expect. The sender address looks good too, and the preview shows the kind of content of the usual type in notification messages. On the surface, all checks out.

The problems lie in the message header, which contains DKIM (Domain Keys Identified Mail) and SPF (Sender Policy Framework) fails. In other words, EOP has tried to authenticate the source of the message as being valid for the purported sender and failed. You can argue if this should be enough to regard the message as high confidence phish, but remember that EOP considers other factors, such as the “click here” hyperlink in the message body.

The original recipient for this message was my outlook.com address. The message was forwarded from outlook.com to Office 365, and this might have caused the issues with DKIM and SPF. In any case, it’s a good example of why quarantined messages sometimes need careful examination before they can be released for delivery.

PowerShell Support

Exchange Online includes some PowerShell cmdlets to work with quarantined messages. For more information, read this post.

Learn more about EOP and Exchange Online mail flow in Chapter 7 of the Office 365 for IT Pros eBook.

Escalating to Tenant Restrictions

In a previous post, I wrote about how Exchange Online Protection monitors the email traffic sent from mailboxes to detect potential problems like compromised accounts or bulk mailings. These mailboxes are blocked (restricted) to stop outbound messages. Administrators can lift the restrictions on the mailboxes to resume normal service, hopefully after discovering a root cause.

After blocking individual mailboxes, the next escalation occurs when Exchange Online Protection considers that a component of the tenant might be compromised, and a wider restriction is necessary. At this point, the “tenant restricted from sending unprovisioned email” alert fires. This is one of the standard alert policies installed in Office 365 tenants, defined as happening when “when most of the email traffic from your organization has been detected as suspicious and Microsoft has restricted your organization from sending email.” Figure 1 shows the settings of the alert policy as viewed through the Security and Compliance Center.

Alert Notification

When the alert fires – and every hour or so thereafter until the alert is cleared – Exchange emails the tenant administrators a notification (email is OK because it’s an internal message) to inform them about the restriction (Figure 2).

Lack of Clarity and Precision in Notification

It’s important that notifications to tenant administrators are concise and clear. When I received this notification, I was confused about its meaning. The biggest issues are:

• “Unprovisioned” and “unregistered” domains are both mentioned. Microsoft’s online documentation doesn’t define what these domains are. As it turns out, both refer to domains that are not registered as accepted domains for the tenant.
• The first line of the notification therefore means that Exchange Online Protection has detected that most of the traffic from the tenant is related to unaccepted domains. This could be perfectly normal, especially for tenants with a small number of users where most of their communication might be with external correspondents.
• The second line says that the suspicious traffic is usually related to a compromised connector. However, my tenant doesn’t have any connectors (apart from those created by Exchange Online). It’s easy to check the messaging configuration of a tenant and highlight areas to check in email, a step that would have made the notification more valuable.
• The third line says that the tenant has been restricted from sending email with unregistered domains. Going back to the point about accepted domains, surely this means that no email can be sent to any external domain. But that’s not what happened because I was able to send and receive email with domains such as Microsoft.com while the restriction was in force.
• The last line advises the administrators to check for compromised user accounts, new connectors, or open relays. It would be nice if Microsoft included a link to a checklist for administrators to consult, and even better if Microsoft tailored the checklist to take account of the tenant configuration.

The net outcome is that I knew that Exchange Online Protection was worried about some traffic from the tenant and had done something to restrict some functionality. However, the lack of clarity and precision in the text meant that I was unsure of what caused the problem and how it should be resolved.

Resolving the Block

The first step in resolving any problem with email restriction is to make sure that there’s no obvious sign of problems with accounts or connectors. Are any accounts generating more email traffic than normal and if so, why? Is the traffic external or internal? Do the account owners know about the traffic? Have any new connectors been created, and so on.

If modern authentication with MFA is used for all accounts, it’s much less likely that accounts will be compromised (this is why Microsoft is removing basic authentication for several Exchange connection protocols). If this is the case, you should use message traces to check who is generating email traffic and try to understand if a spike in traffic is causing problems. For my tenant, the problem seemed to be caused by sending email to some large distribution lists where most of the members are external mail contacts. Microsoft’s monitoring picked up the traffic as a possible indication of spam (even though the messages were perfectly valid) and imposed the block.

Tenant administrators can’t lift the block. You must contact Microsoft Support and ask them to remove the block. Before you do this, gather evidence to prove that you’ve done the due diligence to check the tenant for problems like open relays, compromised accounts, new connectors, and so on. Doing this will avoid the need for wasted time as the support professional tries to understand the full scope of the problem. I’ve criticized Microsoft Support in the past, but when contacted them about this issue, the problem was resolved quickly and without fuss.

Improving Through Experience

Blocks and restrictions are needed to ensure that no tenant can soak resources in a multi-tenant environment like Office 365. Exchange Online Protection usually does a good job of protecting Exchange mailboxes from spam and malware. Microsoft has deployed a lot of machine learning and artificial intelligence to pick up problems as they emerge. In this instance, the algorithms were a little too sensitive and the notification wasn’t nearly precise enough. Feedback has been given to Microsoft to allow them to tweak things as needed. Here’s hoping this happens soon!

Sorting out why things happen inside Office 365 tenants is our passion. Learn more by subscribing to the Office 365 for IT Pros eBook and get monthly updates about everything important that happens inside Office 365.

Exchange Online Isn’t for Bulk Email

Microsoft makes it quite clear that Exchange Online is not a platform for mass mailing. Limits exist to stop people who want to send bulk mail (spam) or whose mailboxes are taken over by malware. Essentially, even though Microsoft recently increased the maximum recipient limit for a message from 500 to 1,000, it doesn’t mean that you should switch mass mailings to Exchange Online from commercial mailing platforms like Mailchimp.

Most of the time, my mailbox never comes to the attention of Exchange Online Protection and the monitoring tools that look for evidence of misuse. I usually don’t send enough email to ever run into the limits. But occasionally, I need to send messages to reasonably large distribution lists (200 to 600 members). I was curious to discover at what point Exchange Online clamped down.

Sender Limits

The documented limit for accounts holding Office 365 E3 or E5 licenses is 10,000 recipients per day. A distribution list managed by the tenant (not a personal list) counts as a single recipient. Controlling mailboxes by measuring the number of messages they send is a crude control mechanism. Exchange Online Protection applies more intelligent algorithms to pick up unusual activity which might be a sign that something’s going on. The settings used by Microsoft to detect problematic senders are undocumented (as you’d expect), but you can force Exchange Online Protection to take an interest in your sending activity.

For instance, if someone who typically send 10-15 messages daily suddenly sends 200 messages over a short period or suddenly starts to send messages to large distribution lists, it might be that they’ve been told to get a message out about something like a new price list to customers. A one-off event isn’t enough to create suspicion, but other signs might exist to increase confidence that something’s wrong. An example is that because hyperlinks can lead the unwary into bad places, messages containing links are more suspect than those with plain text.

A single spike in traffic from a mailbox probably isn’t serious, but if the observed behavior of the mailbox over time deviates significantly from its expected norm, then the account might be compromised, and action is necessary. To ensure that a potentially-compromised account can’t be used to send spam or malware, Exchange Online Protection restricts (blocks) the mailbox. This means that the user is permitted to send messages to internal recipients but not to external recipients, including mail contacts and guest users registered in the tenant directory.

The Block Descends

I tested the theory by sending some messages containing hyperlinks to distribution lists over the course of a working day. Sure enough, after sending messages to circa 2,500 recipients spread across several distribution lists, Exchange Online Protection decided enough was enough and blocked my mailbox. When it imposes a block, Exchange Online generates NDRs (Figure 1) for every external message the user tries to send. The text of the message is:

“Your message couldn’t be delivered because you weren’t recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it’s no longer allowed to send email. Contact your email admin for assistance. Remote Server returned ‘550 5.1.8 Access denied, bad outbound sender.”

In addition, tenant administrators receive a notification about the blocked user. A HygieneEvent Office 365 audit event is logged to record the blocking and an AlertEntityGenerated event logged for the alert which generates the notification to administrators. “User restricted from sending email” is one of the standard alert policies created by Office 365 to alert administrators about problems in the tenant.

Unblocking Accounts

To investigate and unblock restricted accounts, an administrator goes to the Restricted Users section of the Security and Compliance Center to check the current list of blocked users (Figure 2). In this case, an account (mine) is restricted because Exchange Online Protection observed a high percentage (20.75%) of suspicious messages over the last 24 hours.

total for outbound messages is noted as 36. The two figures don’t quite make sense; 747 divided by 36 is 20.75, which is the percentage of spam reported. Microsoft needs to do some work to clarify the reported data and make it more precise.

Unblocking in PowerShell

As expected, the underlying Get-BlockedSenderAddress cmdlet doesn’t help much either. The message trace identifier reported here doesn’t work with the Get-MessageTrace cmdlet.

Get-BlockedSenderAddress | Format-List SenderAddress, Reason

SenderAddress: TONY.REDMOND@OFFICE365ITPROS.COM
Reason: OutboundSpamLast24Hours=747;OutboundMailLast24Hours=36;OutboundSpamPercent=2075;Last Spam Message MessagetraceId:b2223b2d-469d-440c-b409-08d82a588f0e;AS:1135

If you recognize a blocked account and know that it shouldn’t be blocked, you can release the account using the Microsoft Purview Compliance portal or with PowerShell. Here’s how to do it with the Remove-BlockedSenderAddress cmdlet:

Remove-BlockedSenderAddress -SenderAddress Tony.Redmond@Office365itpros.com -Reason "No problem with this account"

I can’t find an audit event logged when an account is unblocked. An unblocked account can’t send messages immediately as mail servers which handle outbound messages must be updated about the block being released. Updating all servers can take up to an hour.

Blocking is Unusual

Dealing with blocked accounts should be an unusual incident. Mailboxes must exhibit some out-of-course behavior before Exchange Online Protection regards them as potentially compromised or a source of spam. And if a block descends, the question is if the account is compromised or it’s because of some unusual email activity on the part of its owner. And that’s where the administrator earns their pay keeping their tenant safe.

We try to discover where limits are in Office 365 and how the limits are implemented so that you don’t find the limits in production. Or at least, if you do, you know what to do next. All documented in the Office 365 for IT Pros eBook.

Signs of Obvious Phishing in a Message

Another day, another phishing attempt. This one arrived in my inbox with all the signs to create heightened suspicion. Although offering the prospect of money, the message:

• Was from someone I didn’t know and a domain (omneshealthcare.co.uk) I didn’t recognize. Using a browser to access the domain reveals that the company is real with an insecure web (doesn’t use https), which is always a bad sign because it means that the domain is open to being compromised.
• Included a spelling error in the attachment name (“reciept”).
• Attachment proclaimed itself as a PDF but wasn’t. The PDF icon is smudged, and the attachment is a link to a file on a zoho.eu server (Figure 1).

In addition, examination of the results reported by the Message Header Analyzer add-in for Outlook revealed a DKIM failure (body hash did not verify). All in all, not a very authentic message.

Simple but Effective Attack

The attack is simple. Have users click the PDF attachment to find out how much money they’ve been paid to reveal. Display a file (Figure 2) with a big Click Here to Access File button (note the comforting assertion that Office 365 has secured the file).

When the user clicks the button, they go to a web site to gather their credentials (Figure 3). Note the name of the site. I’m sure usigaramoldova.ro is a well-known sign-in point to access Microsoft cloud services.

After the user has entered their credentials, the attacker stores the credentials away for later use. It’s a surprisingly effective method to convince people to reveal their username and password.

Reporting Spam to Microsoft

Despite using Office 365 Advanced Threat Protection, this phishing attempt got through to my mailbox. Focused Inbox even considered the message important enough to keep it in Focused instead of Other. All of which proves that some malware will penetrate defenses. My experience with Office 365 is that only a very small amount of spam gets this far and usually it’s because a message doesn’t exhibit known characteristics to mark it as a problem. It’s easy for a human to examine a message and pick up suspicious signs like bad spelling, formatting, and an unknown sender. It’s harder for machine learning to detect subtle signs like this (if every message was rejected because of a spelling mistake in an attachment name, how many would get through?). This underlines the need to coach users about how to recognize the signs of problematic messages that might be phishing attacks.

The best course of action if messages reach inboxes is to report them to Microsoft to allow investigators to examine the messages and understand how they passed message hygiene checks. Microsoft can then make whatever changes are necessary to their malware detection technology and we all benefit.

Learn more about mounting effective anti-malware defenses in Chapter 17 of the Office 365 for IT Pros eBook. So many policies, so many settings, all important!

Run Report to Check Anti-Spam and Anti-Malware Settings in an Office 365 Tenant

ORCA is the “Office 365 Advanced Threat Protection Recommended Configuration Analyzer.” It’s a PowerShell module written by Cam Murray, a Microsoft Senior Premier Field Engineer based in Sydney, with lots of help from Daniel Mozes and other people in Microsoft.

The idea behind ORCA is that you can run a simple PowerShell cmdlet (Get-ORCAReport) to generate an assessment of the anti-malware, anti-spam, and other message hygiene settings used by Exchange Online Protection (EOP) in an Office 365 tenant. Most value is gained if you have licenses for Advanced Threat Protection (ATP) because more settings exist to be checked against best practice. Or at least, best practice as it exists in the minds of the ORCA team.

Module in PowerShell Gallery

I found out about ORCA at the Microsoft Ignite 2019 conference. At first, the cmdlet wouldn’t run because I had the new REST-based Exchange Online management module loaded. Developing ORCA is not Cam’s daytime job, but some conversations moved things forward to make ORCA happy to run. You can download the latest module from the PowerShell gallery.

December 23: The latest version of ORCA is 1.3.2, accessible from the link above.

Running ORCA

Running ORCA is simple. Install the module, start a PowerShell session logged in with an administrator account and run the Get-ORCAReport cmdlet. Because Exchange Online uses Remote PowerShell rather than a module, the cmdlet checks for the presence of the Connect-EXOPSSession command, which means that you need to have either the REST module installed or connect to Exchange Online with MFA. All Office 365 administrator accounts should use MFA, but you don’t need to use MFA to use ORCA.

When it starts, the cmdlet makes some checks, connects to Exchange Online, and then starts to fetch details of the various anti-malware policies configured in the tenant (Figure 1).

There’s no magic here in retrieving policy settings as they are all easily accessed with PowerShell cmdlets or by going to the Threat Management section of the Security and Compliance Center and then selecting Policy.

The ORCA Report

The magic is in the report generated by ORCA because it’s here that comparisons and checks are made against the settings in a tenant and the values recommended by the Advanced Threat Protection developers and other experts inside Microsoft. You can agree or disagree with their conclusions, but it’s good to have a baseline to argue from.

After ORCA finishes, it opens the HTML report in a tab in your default browse (Figure 2). The report is divided up into an overall summary plus different sections of mail hygiene such as Spam Action and Domain Whitelisting where recommendations are offered.

After perusing the recommendations, it’s up to you decide if any of them make sense in your environment and modify the relevant policy through the Security and Compliance Center. Figure 3 shows the settings for the anti-malware policy in my tenant.

Nice Addition to the Toolkit

ORCA is a nice addition to the Office 365 administration toolkit. It can be hard to keep up to date with all the changes made by Microsoft to enhance and expand the various policies used to defend Exchange Online against malware and spam, and being able to run a check every so often just to make sure that everything is as it should be makes a heap of sense.

Chapter 17 of the Office 365 for IT Pros eBook explains the anti-malware and anti-spam policies used by EOP and ATP in great detail. Subscribe now to make sure you understand what all the settings mean.

ZAP and Quarantine

ZAP, or zero-hour auto-purge, is an Exchange Online Protection (EOP) feature that’s had some issues recently. To help, Microsoft is releasing improvements to support more granular control and better alignment with other hygiene controls. In a nutshell, apart from the current “malware ZAP” action to remove any and all attachments deemed unsafe, ZAP will now act upon messages identified as Spam or Phish and can quarantine the messages, if that option is enabled. And we are getting the option to disable phish or spam processing for ZAP, if needed.

Microsoft announced support for moving ZAP-ed messages to Quarantine as part of the Phish and spam Zero-hour Auto Purge move to Quarantine update in Microsoft 365 roadmap item 55432 (Figure 1):

Enabling ZAP for Spam and Phish

While the roadmap item doesn’t explicitly mention this, a quick glimpse at the documentation shows that we are also getting additional controls for toggling the spam and/or phish detection modes. Both new modes will be enabled by default and can be controlled via new parameters introduced for the Set-HostedContentFilterPolicy cmdlet: SpamZapEnabled and PhishZapEnabled.

The value for both these new parameters is currently inherited from the value of the ZapEnabled parameter, and this will remain the case until February 2020, when the ZapEnabled parameter will be deprecated. By default, both the SpamZapEnabled and the PhishZapEnabled parameters will be $true (enabled), if not explicitly changed. Coming soon, we will be able to toggle those two parameters to $false, thus disabling the processing of spam and phish messages by ZAP.

How ZAP Will Process Email

Going forward, ZAP will behave as follows. For any messages detected as malware, the current “remove attachment” action will remain in effect, while for messages identified as phish or spam, the corresponding action configured in the Content filter policy will be executed. If the action is set to Quarantine message, Delete message or Redirect message to email address, ZAP will move it to Quarantine. If the action is set to Move message to Junk email folder, the current behavior will apply, and messages will be moved to the Junk email folder. If the action is set to Add X-Header or Prepend subject line with text, or there is no action defined in the policy, then ZAP will not act upon the message. The same is true if the corresponding spam/phish processing has been toggled off by the controls listed above.

These improvements will also introduce another change in ZAP processing, based on the read status of the message. Malware messages will continue to be acted upon regardless of the read status. For messages identified as phish, the action will also be performed regardless of the read status. However, for messages marked as spam, the action will only be performed on messages marked as unread.

For more information about techniques to repel spam and malware, read the chapter about mail flow in the Office 365 for IT Pros eBook.

EOP, ATP, and Mail Hygiene Services

Exchange Online Protection (EOP) comes in for criticism because of the amount of spam that gets past its barriers. Companies selling email hygiene services are keen to point out just how horrible EOP is at stopping spam and often issue reports to highlight the issue (or terrify Office 365 administrators). The simple fact is that EOP does a reasonable job of blocking spam, but because of the changing nature of the threat and the way that attackers continually evolve their techniques, EOP will always be vulnerable against a new attack, even with intelligence flowing into Microsoft through user reports about new examples of spam.

Having multiple defenses in place helps because if spam sneaks by the first line, it might be stopped by the second. Because it builds on the foundation of EOP, Microsoft says that Advanced Threat Protection (ATP), which is part of Office 365 E5, is what you should use. ATP is also available as an add-on for other Office 365 plans.

Update: Advanced Threat Protection is now called Microsoft Defender for Office 365

Third-party mail hygiene services beg to differ and say that their solutions offer better protection. Either way, you’re better protected when EOP is not the only line of defense.

ATP Safety Features for Exchange

All of which brings me to ATP Safe Attachments and ATP Safe Links, both features designed to stop malicious content arriving in user mailboxes.

I like the concept behind ATP Safe Attachments very much. It seems reasonable to me that an inbound attachment that might contain a problem should be intercepted, put somewhere safe, and tested before it reaches me. ATP Safe Attachments also stops infections caused by malware being uploaded to SharePoint Online and OneDrive for Business sites, including the SharePoint Online sites used by Teams (which is enough for Microsoft to claim ATP support for Teams).

My tenant is configured to use Dynamic Delivery, which means that I receive messages without attachments while those attachments are being scanned. The only issue I have is the unfortunate side-effect where Outlook Mobile insists on notifying me twice for these messages: once for the message and the second time after Dynamic Delivery has processed the attachment and declared it safe.

Safe Attachments doesn’t generally take long to process attachments. The usual delay is in the order of one or two minutes, which I think is acceptable. Yet I have heard anecdotal evidence of much longer delays of up to an hour before an attachment is delivered. Michael Osterman of Osterman Research said that he’d been told of this experience by Office 365 customers when he spoke at the recent TEC conference. I’ve never experienced long delays and am interested in hearing if others have.

Another complaint I’ve heard is that Safe Attachments stops people being able to email documents to each other when needed quickly in meetings. There’s an easy answer to this: share the document from OneDrive instead of sending it as an email attachment.

Safe Links

ATP Safe Links protects users from links in messages pointing to malicious sites. While links are checked, users are prevented going to the sites. Again, this can delay mail recipients from being able to get to information but given the amount of bad sites that exist on the internet, this is reasonable, even if users are sometimes frustrated when they can’t reach a site because of a blocked link.

A new feature in the ATP Safe Links policy allows tenant administrators to delay message delivery until all links in a message are scanned (Figure 1). If you haven’t yet chosen this option, it’s a good one to consider. Email delivery is delayed slightly but recipients can click all good links in messages when they do arrive. I think this is less frustrating all round for recipients.

Need more information about how EOP and ATP work? Look no further than Chapter 17 of the Office 365 for IT Pros eBook, which goes into these topics in enormous detail.

Office 365 Admins and Users can Report Spam and Phishing

From time to time, reports come out to criticize the performance of Exchange Online Protection (EOP), mainly its inability to detect spam and phishing messages. Invariably, the report is authored by a vendor anxious to sell their mail hygiene service with promises that a much higher proportion of bad email will be caught if Office 365 tenants would sign up. It’s true that routing email through multiple cleansing services can have a benefit; what’s not so clear is if third parties do any better than Microsoft’s own Advanced Threat Protection (ATP), which serves the same purpose.

In any case, all the services that aim to block spam and malware depend on intelligence to understand the latest tactics taken by attackers to trick defenses and allow their email to get to user mailboxes. If you want to see EOP do a better job of blocking malware, you can help Microsoft by reporting messages that get through.

Two methods are available:

• The Report Message add-in for Outlook allows users to report messages as junk, phishing, or a false positive (not junk). Figure 1 shows how to use the Report Message add-in with the new OWA. The add-in works for Outlook desktop (Windows and Mac) as well and should be a basic part of the Outlook configuration for Office 365 clients.
• The Submissions section under Threat Management in the Security and Compliance Center allows admins to report messages. This is a relatively new feature described in this Microsoft post.

In both cases, reported messages are sent to Microsoft for analysis so that they can tweak EOP to do a better job.

Administrator Submissions for EOP Processing

Before administrators can submit a report to Microsoft through the Security and Compliance Center, they need some details about a bad message that only a user can give. Every message has a network message identifier that should be unique. An easy way to find the message identifier is to run the Outlook’s Message Header Analyzer add-in (also available as a GitHub project) and look for the X-MS-Exchange-Organization-Network-Message-Id property (Figure 2).

Another method is to use OWA’s Show Message Details option (Figure 3). The equivalent in Outlook desktop is to look at the message properties through the File menu.

In either case, I prefer to use the Message Header Analyzer because it’s easier to locate the message identifier. Once you have the message identifier, you can submit a new report. Go to the Threat Management section of the Security and Compliance Center, select Submissions, and then New submission. Fill in the information about the problem message (Figure 4) using the network identifier to find the message. You need to select one of the message recipients too. If you have a copy of the message (EML format), you can upload it too. Indicate if you think the message should have been blocked or passed, select what kind of problem you see in the message (spam, phishing, or malware), and submit the message for processing.

The Submissions dashboard (Figure 5) shows you a breakdown of user (via the Report message add-in) and admin submissions.

For admin submissions, the reported messages show when EOP has finished analyzing their content. Select a completed message to see what the verdict is. In the case of the message verdict shown in Figure 6, the user had complained that obvious spam had reached their Inbox. The clue to why this was so was in the policy type “Sender domain in safe list.” The user’s junk email settings accepted all email from outlook.com senders, so even though EOP had marked it as spam, the user’s preference had overridden the analysis. The learning from this is to educate users not to mark consumer email domains like outlook.com and gmail.com as safe because spammers often create throwaway accounts in these domains to use to send mail. It’s perfectly acceptable to mark individual known accounts from these domains as safe senders.

Of course, automated detection systems can only go so far. Some spam and malware will get through and it’s then up to user intelligence to recognize and suppress bad email. And hopefully, when they do see spam arriving in their inbox, they’ll know how to report the messages themselves or how to give admins the necessary information to make the report on their behalf.

There’s lots more to learn about Exchange Online Protection and Advanced Threat Management in the Office 365 for IT Pros eBook. Be informed and be secure!