In this article, we will be reviewing the next set of recommended steps to take to secure an Office 365 tenant. These steps revolve around Office 365’s built-in protection policies, including Anti-Spam, Anti-Phishing, Anti-Spoofing, custom Mailflow transport rules, and a few general organization-wide policies.
In the previous article of the series, we reviewed things you can do quickly secure an Office 365 tenant quickly. These steps are geared toward MSPs who manage multiple Office 365 tenants and require some level of automation to configure Office 365 tenants in bulk.
Further reading Securing Your Office 365 Tenants. Part 1
Table of Contents
Disabling Basic Authentication
According to Microsoft, Basic authentication uses legacy authentication protocols to connect to services such as Exchange. Some of these legacy protocols are IMAP4 and POP3. By leaving this backward compatibility open, you also leave your end users open to brute force or password spray attacks.
When you disable Basic authentication for users in Exchange Online, their email clients and apps must support modern authentication.
Those clients are:
- Outlook 2013 or later (Outlook 2013 requires a registry key change)
- Outlook 2016 for Mac or later
- Outlook for iOS and Android
- Mail for iOS 11.3.1 or later
There are 2 different methods to disable or prevent Basic Authentication.
- Exchange Online Authentication Policy - By running a simple PowerShell command that disables Basic Authentication for the entire Office 365 tenant.
- Azure Conditional Access Policy - By leveraging Conditional Access Policies in Azure (you must have an Azure AD P1 license) to prevent access to Basic Authentication for select users or groups.
Before picking one method and running with it, it is highly recommended to ensure all your end users are not using legacy authentication protocols. If they are and you disable basic authentication, you will very likely get a bunch of calls to your help desk from confused and frustrated users who are unable to access their emails. To avoid that chaotic scenario, you can use the Azure sign-in logs to see which users may still be signing in with older protocols.
How to Get Azure Sign-In Logs
- Sign in to Azure AD Portal
- Navigate to Users
- Under Activity, click Sign-ins
- Make sure the following columns (at a minimum) are selected for the sign-ins report
- User, Application, Status, IP Address, Client App
- Apply and refresh
- Download the report to CSV
- Open the report in Excel and filter out the Client App to show anything containing the words “Other clients” in the “Client App” column
Now, review the result of users that are returned from that filter. You may have to reach out to them to make sure they are using apps that support modern authentication to access their Office 365 services. After that is complete, check back in a few days and refresh the report. If only a few users are returned, you can proceed with the next steps (you may still receive calls from a few users, but the volume should be manageable).
Method 1 - Exchange Online Authentication Policy
This method requires no extra licensing and can easily be automated and run with PowerShell.
The general logic of the commands below is that you first need to create a new authentication policy. By default, when creating a new authentication policy, ALL basic authentication protocols are disabled.
While this approach offers the greatest security, one of its drawbacks is that by accessing PowerShell with Basic Authentication, disabling you will no longer be able to connect to Exchange Online using PowerShell by passing credentials with Get-Credentials. Without that, you may limit and restrict the ability to use PowerShell to administer Office 365 tenants. You can of course still access PowerShell for Exchange Online instead of using the MFA module, but this doesn’t offer a way to pass credentials into the prompt, which effectively cripples the ability to log on to your Office 365 tenants with direct credentials in an automated loop.
Given this limitation, I personally am holding off on recommending this approach, at least until Microsoft provides a way to pass the credentials into the MFA prompt and allow them to pass over to Connect-MSOL or Azure Remote PowerShell module as well.
After creating a new policy, you then reference that policy when setting the default authentication policy for the entire Office 365 tenant.
Here are the commands:
# I recommend running this beforehand to ensure Modern Authentication is enabled. # Although Microsoft reports that Modern Authentication is enabled by # default, I’d err on the side of caution here and run the command to # enable it anyway, as you don’t want to block access for all # users mistakenly. Set-OrganizationConfig -OAuth2ClientProfileEnabled $true # First create a new policy that will block all basic auth protocols # except for PowerShell New-AuthenticationPolicy -Name “Block Basic Auth - Except PowerShell” -AllowBasicAuthPowerShell:$true Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth - Except PowerShell"
Method 2 - Azure Conditional Access Policy
Unlike the previous method, the Conditional Access Policy provides the ability to fine-tune granularity based on certain conditions. The great benefit of this approach is that we can exclude or only apply this policy to select users or groups so that we can avoid locking out applications or users that may still require the use of legacy authentication. The disadvantage of using this strategy over Method 1 is the lack of the ability to automate this process with PowerShell. You will have to apply this policy manually for every tenant using the Office 365 Azure portal.
Before proceeding further, make sure you review the Azure sign-in logs as explained above to identify any legitimate possibilities of users or applications that may still require basic authentication. If there are any, be sure to add those users and apps to a custom “Exclusion” group so that you can easily exclude them from the policy restricting legacy authentication.
Notes:
- Policies can take up to 24 hours to apply
- First test the policy on a small subset of test users to ensure you don’t lock yourself out
- Blocking “Other Client Apps” which is what we want to do here will block access to Exchange Online PowerShell, so be sure to exclude any admin accounts needing PowerShell access (that’s why you should test this out first, as explained above)
Steps:
- Navigate to Azure AD admin center > Azure Active Directory > Conditional access
- Create a new policy; define a simple name (e.g. “Block Basic Auth for Other Client Apps”)
- Choose all users to include, and under exclude add any groups or users that require exclusion
- Under cloud apps, select Office 365 Exchange Online
- Under client apps, check Mobile Apps and desktop clients > check only “Other Clients”
- NOTE: This will block access to Exchange Online PowerShell - be sure to exclude admin accounts needing access to that (which is why I prefer method 1)
- Under Access controls > Grant, choose Block access
- Save and enable this policy when ready
Disable External Forwarding
Disabling external forwarding across the Office 365 tenant will prevent all users from forwarding emails to external accounts. You may want to do this to prevent data leaks or to meet corporate policies. However, for the purposes of this tutorial, we will be doing this to prevent compromised accounts from forwarding all emails to external recipients. It’s common when an account gets hacked that malicious inbox rules are created, usually to forward all emails to an external account to which the hacker has access, combined with another rule to delete emails thereafter.
To block forwarding to all external domains for all users, you can run the following PowerShell Exchange Online command:
Set-RemoteDomain Default -AutoForwardEnabled $false
Enable Safe Links Policy For All Users
Theoretically, Safe Links is a great email security feature. It is supposed to scan all URLs in an email and wrap the URL to a re-written URL that, when clicked, requires the destination page to be scanned by Microsoft’s URL scan service. If it identifies the destination URL as malicious, it will not redirect the user there and will instead show a warning to the user that the link is unsafe. I say “it’s great in theory” because it can overlook some malicious URL. But nonetheless, if you are not using a third-party email protection service (which I highly recommend you do, as Office 365 has a long way to go to be a solid email protection offering), this is better than nothing.
Fortunately, it’s simple to enable safe links with PowerShell using Exchange Online commands.
Note that the policy doesn’t offer a built-in way to apply these rules to all users. Instead, you have to specify a group that contains the users that you would like to apply the policy to.
The best way to do that is to create a dynamic group with the criteria to contain all users with a mailbox; that way, you are sure to have a group that is always updated to contain all mailboxes as they are added or removed automatically.
# Don't forget to change this
$ExclUrls = ('url1','url2')
$GroupName = ‘ChangeMe’
New-SafeLinksPolicy -Name 'Enable Safe Links Policy' `
-EnableForInternalSenders $true `
-DoNotTrackUserClicks $false `
-IsEnabled $true `
-DoNotAllowClickThrough $true `
-ScanUrls $true `
-DoNotRewriteUrls $ExclUrls `
-ExcludedUrls $ExclUrls `
-Enabled $true
New-SafeLinksRule -Name 'Enable Safe Links Rule' `
-Priority 0 `
-SentToMemberOf $GroupName `
-Enabled $true `
-SafeLinksPolicy 'Enable Safe Links Policy'
Anti-Spam Settings With Region Blocking
Next up is setting up anti-spam settings. Again, if you do not use a third-party email protection service like Mimecast, Barracuda or Proofpoint, I highly recommend you do so as they offer much better protection and detection than Office 365. Otherwise, you can use the commands below to create a default anti-spam policy to block emails that are from certain regions, fail certain authentication/authenticity checks or otherwise appear malicious.
Here are some basic settings we can apply using Office 365’s built-in Email protection.
You can run the following PowerShell command with the Exchange Online PowerShell module as well.
# Change the values of these variables $AllowedSenders = ‘SenderDomain1’,’SenderDomain2’ Set-HostedContentFilterPolicy ` -Identity 'Default' ` -AllowedSenderDomains $AllowedSenders ` -BulkSpamAction MoveToJmf ` -BulkThreshold 7 ` -EnableRegionBlockList $true ` -RegionBlockList 'CN','NG','KP','RU','UA','TH','PH','JP','HK','TW' ` -HighConfidenceSpamAction MoveToJmf ` -IncreaseScoreWithBizOrInfoUrls On ` -IncreaseScoreWithNumericIps On ` -InlineSafetyTipsEnabled $true ` -MakeDefault ` -MarkAsSpamBulkMail Off ` -MarkAsSpamFromAddressAuthFail On ` -MarkAsSpamNdrBackscatter On ` -MarkAsSpamSpfRecordHardFail On ` -PhishSpamAction MoveToJmf ` -SpamAction MoveToJmf `
Anti-Phishing Settings
The anti-phishing settings can be created with PowerShell Exchange Online commands. I have set the policy according to what I think would offer the best mix of protection and functionality. Of course, you are free to adjust the parameters of the policy to your liking.
Note that I have set the action for detected messages to “Quarantine.” As such, you should be sure to frequently check the Quarantine and release any false-positive emails if needed. Also note that I have enabled AntiSpoof protection, which may block emails that are legitimately sent from applications that are set to display the Send From address as one of your users. If there are emails that are blocked as a result of the anti-spoof protection, you can always whitelist selected users and origin email servers. To do so, please refer to the article on the command Get-PhishFilterPolicy from Microsoft.
Please see commands below:
# Change the values of these variables
$PolicyName = ‘Custom_AntiPhishing_Policy’
$RuleName = ‘Custom_AntiPhishing_Rule’
$InclGroups = ('Group1','Group2')
$ExclGroups = ('ExclGroup1','ExclGroup1')
$ExclDomains = ('Domain1','Domain2')
$ExclSenders = ('Sender1','Sender1')
New-AntiPhishPolicy `
-Name $PolicyName `
-AuthenticationFailAction Quarantine `
-EnableAntispoofEnforcement $true `
-EnableAuthenticationSafetyTip $true `
-EnableAuthenticationSoftPassSafetyTip $true `
-EnableSuspiciousSafetyTip $true `
-Enabled $true `
-EnableMailboxIntelligence $true `
-EnableMailboxIntelligenceProtection $true `
-EnableOrganizationDomainsProtection $true `
-EnableTargetedDomainsProtection $true `
-EnableTargetedUserProtection$true `
-EnableUnauthenticatedSender $true `
-EnableSimilarDomainsSafetyTips $true `
-EnableSimilarUsersSafetyTips $true `
-EnableUnusualCharactersSafetyTips $true `
-PhishThresholdLevel 3 `
-TargetedDomainProtectionAction Quarantine `
-ExcludedDomains $ExclDomains `
-ExcludedSenders $ExclSenders
New-AntiPhishRule `
-Name $RuleName `
-AntiPhishPolicy "Custom_AntiPhishing_Policy" `
-SentToMemberOf "$InclGroups" `
-ExceptIfSentToMemberOf $ExclGroups
Set-AntiPhishPolicy `
-Identity $PolicyName `
-EnableAntispoofEnforcement $true `
-MakeDefault
Custom Mail-Flow/Transport Rules
As an additional measure of protection, you can create custom Exchange rules to block or redirect emails that meet certain conditions. I’ve come across one particular suggestion that I thought would be great to share. It suggests creating a rule that blocks email that contains the word Bitcoin! I thought that to be a great idea.
See the PowerShell Exchange Online commands below to create such a transport rule. (Note that you can, of course, add other cryptocurrency keywords to use as the basis for a quarantine.)
# Change the values of these variables $RuleName = 'Quarantine Bitcoin' $Keywords = 'Bitcoin','Bit coin','Keyword3' [int]$PriorityLevel = 0 New-TransportRule ` -Name $RuleName -FromScope NotInOrganization -SubjectOrBodyContainsWords $Keywords -Quarantine $true -Priority $PriorityLevel
You can also create other rules that block attachments that match file types based on regex patterns, create a rule to Prepend Subject with the word “EXTERNAL” on all mail sent from outside the organization as a measure to help prevent users from falling prey to spoofing, and more. Leveraging Mail Flow rules is a great and granular way to enhance the protection of your Office 365 environment.
Conclusion
I hope you have found this article informative and helpful for protecting your Office 365 tenants. Please feel free to take a look at other articles I have posted previously on the MSP360 Blog for tips and references for PowerShell scripts I have created to help automate and run Exchange and MSOL commands to administer Office 365 tenants.
- Backup Office 365 Email, SharePoint, OneDrive and Exchange Online
- Item-level recovery
- Data encryption at rest and in transit
