We have recently seen several indicators that show that many of our customers are being targeted by password spray attacks that leverage basic authentication.
The only reason we’re turning off basic auth in Exchange Online is to protect your users and data. The evidence I see every day clearly indicates that password spray attacks are becoming more frequent.
If basic auth hasn’t yet been turned off for your tenant, or if you’ve asked for more time, you should read this.
What is a Password Spray attack?
A password spray attack is a type of brute force attack in which the attacker tries a large number of usernames with a list of common passwords against a target system to see if any will work. It’s often hard to detect as the username keeps changing; accounts don’t get locked because the account being attacked keeps changing. Attackers also distribute their efforts over their targets and keep changing their source IP.
It's a numbers game essentially, and computers are quite good at numbers. And as attacks go, it works.
The most popular protocols we see attacked like this are SMTP and IMAP. POP is third on the list, but SMTP and IMAP are way out there in a league of their own.
What can you do about this?
Set up Exchange Online Authentication Policies to ensure only the accounts that you know should be using basic auth with specific protocols, can use basic auth with these protocols. Start with SMTP and IMAP and do it today!
How do you set up Authentication Policies?
Our documentation is rather good at answering this question, and there are many other docs out there written by MVPs and other community contributors. Rather than explain the actual step by step, I wanted to explain the strategy.
We’ll use IMAP as the example, and then repeat for each protocol, noting that some apps (such as Outlook) use more than one protocol. So, you might need some “combination” policies as users can only have one policy assigned:
- Use Azure AD Sign in reports to determine who is legitimately using basic auth with IMAP in your tenant.
- Create an Authentication Policy in your tenant that allows Basic Auth with IMAP. For example:
New-AuthenticationPolicy -Name "AllowIMAP" -AllowBasicAuthImap
- Create a Default Authentication Policy that blocks all basic auth use:
New-AuthenticationPolicy -Name "BlockAllBasicAuth"
- Assign the allow policy to the user accounts you identified:
Set-User -Identity Bob -AuthenticationPolicy “AllowIMAP”
- Then, set the Default Authentication to the policy that blocks everything:
Set-OrganizationConfig -DefaultAuthenticationPolicy "BlockAllBasicAuth"
And that is it.
Any attempt to use basic auth with IMAP, using any account other than those with the explicit Allow policy will fail.
Password spray attacks would be limited to those specific accounts – and you can watch them more closely, safe in the knowledge all your other accounts can’t be attacked in this manner.
Because we are not disabling SMTP Auth, and SMTP is one of the most frequently attacked protocols, you should make it a priority to set up an Authentication Policy for SMTP and limit your attack surface.
Bonus: Can we use Set-CASMailbox instead of Authentication Policies?
We see many customers using Set-CASMailbox to block protocols thinking that this will block basic auth too. But it won’t, and let’s explain why.
To start, CASMailbox settings blocks the use of a protocol entirely – basic auth as well as OAuth. So if you wanted to use OAuth with IMAP for example, CASMailbox would prevent it.
But more importantly CASMailbox settings block at the very final stage of the client’s journey to get to mailbox data. The user has to authenticate, and pass through Azure Conditional Access in order to even be evaluated for their per-protocol, CASMailbox setting. If at that stage they are blocked, they can’t access the data; but the response to the client tells a different story – a story that those who password spray like to read.
Take IMAP for example. If you block IMAP/Basic with an Authentication Policy (or we block it permanently) the client app gets this:
The IMAP server responded with an error status "2 NO LOGIN failed.".
However, if you block access with Set-CASMailbox, the client app gets this:
The IMAP server responded with an error status "3 BAD User is authenticated but not connected.".
That’s very revealing. The second message essentially is saying ‘you got the password right, but you can’t access the data’. And that, is a successful password harvested.
We’re not saying Set-CASMailbox doesn’t work or shouldn’t be used ever. We’re saying it shouldn’t be used thinking it will block authentication. It won’t. It blocks the protocol at the mailbox, nothing more.
Useful resources
Here are some useful resources to help you along the way.
Summary
Please set up Authentication Policies immediately if you are going to continue to use basic auth, and to control who can use SMTP Auth. Don’t be the next target!
Greg Taylor
