Three ways to disable basic authentication and legacy protocols in Exchange OnlineAlex Fields
One of the most common (and often successful) attacks we see in the wild is a simple brute force / password spray against weak accounts. Especially against shared mailboxes. From that foothold, the most common next step attackers will take is to send out spam/phishing emails from the compromised account, and gain more footholds and greater access for data ex-filtration, ransom, or whatever. There has actually been an uptick in this type of activity lately.
Even with Modern Authentication and indeed Multi-factor Authentication enabled, you are still left open to these types of attacks. Reason being: Basic authentication is enabled by default, and Basic auth does not support MFA to begin with. And that means you can still get in with nothing more than a username and password.
For all other accounts, you might think that using stronger passwords (e.g. eliminate “Password1” or “Spring2019” etc.) may help mitigate these risks… But, when Basic Auth is left in play it means that attackers can brute force accounts all day long. How long before they hit an award-winning user/pass combo? App passwords for instance are all lower case and a predictable length. Far better to just disable basic auth as widely as possible.
Difference between Basic and Modern Authentication
Basic auth prompts look like this:
Whereas Modern auth prompts look more like this:
Switching completely to Modern auth and disabling basic (even without implementing MFA) is a major improvement in security. Modern authentication is not subject to the same types of attacks and exploits that are possible with Basic authentication.
For example, credentials in a modern auth compatible app are not stored on the client device, and whenever something about the connection or state changes, the client is required to re-authenticate. Additionally, we can layer MFA on top of modern auth to make client authentication even stronger.
So take the time to disable Basic auth. If your users all have modern clients like the latest Office 365 bits, Outlook for iOS/Android, etc., then you probably don’t need it. But, do check out your sign-in activity first, so you understand the impact in advance. Go to the Azure AD Admin center > Sign-ins and add the Column for Client App. Then you can filter based on “Other clients.” This can give you an idea of what is out there that still relies on legacy protocols and services.
More than likely you will see some failed attempts being made against your accounts from other parts of the world using these legacy protocols–that’s the bad guys trying to get in. That’s why we’re going to cover three strategies you can employ to button up the hatches a bit. The first two require no other licensing other than Exchange Online. The last would require an Azure AD Premium or Enterprise Mobility + Security subscription.
Difference between protocols/services and authentication
“Protocols” or “services” are different than authentication, and some people get this confused. They think that because they disable POP and IMAP they have disabled basic authentication. Not true. Likewise, disabling Basic Authentication on its own may not disable “enough” protocols.
If you disable basic authentication globally, this would effectively kill POP and IMAP since those protocols do not support modern authentication–they rely exclusively on basic/legacy auth. Other protocols such as EWS, however, support both basic and modern authentication, but often it does not need to be left enabled at all.
Remember, protocols or services such as EWS or EAS are different than authentication--you can disable protocols outright whether they are enabled for basic authentication or not. And it is best practice to turn off any services which you are not using–don’t leave the door unlocked for others to potentially open if you have no intention of walking through them yourself. (This would imply also that you should disable sign-in entirely for any accounts that are either inactive or “shared mailbox” accounts).
Method #1: Disable services per mailbox
The benefits of this method include ease of implementation, and also, it requires no additional licensing. However, it is important to note that rather than disabling basic authentication, we are simply disabling legacy or extraneous services that are no longer needed (especially POP and IMAP which only support basic authentication).
From the Microsoft 365 admin center, select a user account. Go to the “Mail” tab and select the option to Manage email apps.
From here it is very easy to turn off any legacy protocols that you know are not (or should not be) in use, such as POP, IMAP, etc. In the example below I’ve even disabled EWS (used by some third party apps) and Exchange ActiveSync (meaning mobile devices cannot connect).
You can see the same view in PowerShell on any given account using:
Get-CASMailbox -identity <email@example.com> | fl Name,OwaEnabled,MapiEnabled,EwsEnabled,ActiveSyncEnabled,PopEnabled,ImapEnabled
Of course, going one account by one takes forever. To modify mailboxes in bulk via PowerShell you could use the following:
Get-Mailbox | Set-CasMailbox -PopEnabled $false -ImapEnabled $false
This would disable POP, IMAP and SMTP, all at once. While
POP and IMAP are hardly ever needed anymore, it’s not a hard and fast rule. Also note that some apps/services that interface with Exchange Online require EWS or SMTP in order to work. So just be careful to note the potential impacts when disabling services. Again, best practice: if it isn’t being used, get rid of it. POP and IMAP are by far the most commonly exploited that I have seen, and really not needed by most people just using modern apps like Outlook–so start there.
What about newly created accounts? So that you don’t have to repeat this step for every new user account, you can also modify the defaults moving forward org wide, as follows:
Get-CASMailboxPlan | Set-CASMailboxPlan -ImapEnabled $false -PopEnabled $false
That command will make it so that any newly created accounts end up with both POP and IMAP disabled by default, for example.
Method #2: Use an Exchange Online Authentication Policy
This method will effectively eliminate both POP and IMAP, as well as basic authentication for any other services you want to button up (EAS, EWS, SMTP, PowerShell, etc.) The benefits of using an authentication policy are again that it requires no other licensing, and also that you can truly disable basic auth while leaving modern authentication methods available for all types of services. However, there is no GUI interface for authentication policies, and therefore they must be configured via PowerShell.
To create a new Exchange Online authentication policy, simply run this command:
New-AuthenticationPolicy -Name “Block Basic Auth”
Take a look at it using Get-AuthenticationPolicy. By default, a new authentication policy will have all basic auth disabled. You can then apply they policy across the organization globally using this command:
Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”
Generally speaking, most orgs do not have an authentication policy set on their individual mailboxes, so the above would mean that if you have no policy defined yet, then this is your default policy. It is however possible to create exceptions simply by adding another policy and then assigning it to mailboxes individually. Example:
New-AuthenticationPolicy “Allow Basic Auth Exceptions”
In this example, we can allow IMAP and EWS to use Basic auth, but leave it disabled for other services. To apply the policy to a specific user (such as a service account):
$ExceptionUser = firstname.lastname@example.org
Set-User -Identity $ExceptionUser -AuthenticationPolicy “Allow Basic Auth Exceptions”
And, to apply a policy in bulk to all accounts at once:
Get-User -ResultSize unlimited | Set-User -AuthenticationPolicy “Block Basic Auth”
More details on this here.
PLEASE NOTE: If you disable basic auth across the board, you must use the Exchange Online PowerShell module that supports MFA. You cannot connect with the old method where you Get-Credential and then pass that into a new PSSession. You’ve got to use modern auth (you don’t want that old pathway left open anyways).
Method #3: Use a Conditional access policy
This method requires at a minimum Azure AD Premium P1 (which you can also get via an Enterprise Mobility + Security or Microsoft 365 Enterprise plan). The benefit to this method is that you can disable legacy client authentication against other cloud apps like SharePoint Online, and not just Exchange Online. It’s also pretty easy to implement and make exceptions for. The downside is really just the licensing requirement.
Navigate to Azure AD admin center > Azure Active Directory > Conditional access.
Create a new policy and name it something like “Block legacy client apps” Choose All users, and under cloud apps pick Office 365 Exchange Online. You could also add other apps such as SharePoint if you wanted to.
Under the Conditions > Client apps blade, select only Mobile apps and desktop clients > Other clients.
Save these selections and under Access controls > Grant, choose Block access.
Now you can save and Enable the policy. If you find that you must make exceptions then use the Exclude tab under Assignments > Users and groups.
And that concludes today’s blog post. You should be implementing these controls if you haven’t already–the attacks taking advantage of basic auth have been increasing in recent months. Stay safe out there.