Microsoft says it is seeing indicators that Exchange Online customers are being targeted by password spray attacks leveraging basic authentication as the company begins to phase out basic auth in Exchange.
The company has for three years been urging customers to move away from basic auth, and Microsoft has disabled it in “millions of tenants to proactively protect them.” Since the start of this month, the company has begun to randomly select tenants and disable basic authentication access for MAPI, RPC, Offline Address Book (OAB), Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), and Remote PowerShell.
However, the company will not be disabling or changing any settings for SMTP AUTH.
This comes as password spraying becomes more frequent as cybercriminals still utilize a basic attack that uses a large number of usernames and a common list of passwords to see if any will work. These attacks are hard to detect since the username being used keeps changing and accounts don’t get locked.
According to Microsoft’s Exchange Team, customers that haven’t yet had basic auth turned off or have asked for more time should set up Exchange Online Authentication Policies to ensure that only the accounts that should be using basic auth with specific protocols can use basic auth with these protocols. The company advises to start wit SMTP and IMAP.
Customers who aren’t ready for the change can use the self-service diagnostic to re-enable basic auth for any protocols they need, once per protocol. Those selected protocols will stay enabled for basic auth until the end of December 2022. After that, they will be disabled permanently.
Microsoft also notes that many customers are using Set-CASMailbox to block protocols thinking that this will block basic auth too, but those settings blocks the use of a protocol entirely, including OAuth. In addition, CASMailbox settings block at the final stage of the client’s journey to get to mailbox data, forcing the user to authenticate and pass through Azure Conditional Access in order to even be evaluated for their per-protocol, CASMailbox setting.
Here’s more from the Exchange Team’s blog:
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.
If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!
Leave a Reply