Basically, when someone launches a password spray attack on one of your accounts, they are basically using automated processes to guess your password and brute force their way into the account. These attacks typically happen via legacy protocols that should be disabled in your Microsoft 365 tenant as i have mentioned before:

Disable basic auth to improve Office 365 security

This can be tricker than you think because many legacy applications require basic authentication to operate. Therein lies the challenge.

I have purposely left legacy authentication enabled on some accounts to track what happens during brute force attempts. Experience is the best teacher as they say. Thanks to Cloud App Security:

A great security add on for Microsoft 365

I have configured it to alert me when there is failed login from outside my corporate locations:

Tracking failed logins using Cloud App Security

I would occasionally get the odd failed alert but nothing sustained. That was until today!

As you can see from my inbox, all of sudden I started to get massive volumes of alerts from Cloud App Security. The spray was on!

I jumped across to Azure AD sign-ins for the account and filtered the location down to be largely from China (i.e. CN is the location filter in the above results).

Due to the intensity of attack I started to get login failures and reported locks outs as shown above. So how does Azure AD handle lockouts? You’ll find that information here:

Azure Active Directory smart lockout

which says:

By default, smart lockout locks the account from sign-in attempts for one minute after 10 failed attempts. The account locks again after each subsequent failed sign-in attempt, for one minute at first and longer in subsequent attempts.

Smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior will not cause the account to lockout.

…

Smart lockout is always on for all Azure AD customers with these default settings that offer the right mix of security and usability. Customization of the smart lockout settings, with values specific to your organization, requires paid Azure AD licenses for your users.

In this case, the tenant didn’t have a premium version of Azure AD so the standard defaults were in effect.

The next application to feel the strain was the OneDrive for Business sync client which started requiring re-authentication.

Then the Azure portal began to struggle under the weight of so many failed login attempts.

Then the Microsoft Teams desktop application also started to have authentication issues.

Next, it was OneNote’s turn to start requiring re-authentication.

The attacks came in waves, typically separated by a few minutes (as happens with spray attacks) and then it was back again.

So what can you do if an account is subject to a spray attack and you are effectively getting denial of service thanks to that? Microsoft has provided every tenant with a number of free Baseline Conditional Access policies. The most appropriate one in this case is Block legacy authentication.

Enabling this policy will basically prevent legacy protocols like IMAP, POP and SMTP BUT it will do this across the WHOLE tenant! That is, for ALL users. That may be an issue if you have other accounts that depend on these older protocols for operation. However, this is certainly the quickest and easiest way to block spray attacks if you need to.

A more refined approach is to use PowerShell and create a new authentication policy as shown above. This creates a policy that disables the legacy protocols.

With the policy in place you can now apply it to just the user in question. Most authentication policies can take up to twenty four hors to take effect, however you can force an immediate refresh using the –STSRefreshTokenValidFrom option as shown above.

After doing all this, it is advisable to check to ensure the user has this authentication policy enabled as shown above.

When you dive into the Azure AD logs you’ll see that the brute force attempts have happened via SMTP, confirming a spray attack against the account.

Another service that may be affected by these attacks is Flow as seen above.

You may need to go into the Flow and re-authenticate as with the other affected apps. The issue may not be come evident until the next time your Flow actually runs.

So what my ten take aways?

1. Spray attacks are easy to automate and initiate. That means they will continue because they have a great ROI for attackers.

2. Implementing MFA on accounts is going to protect against an account breech from these spray attacks.

3. Spray attacks are facilitated via basic authentication which is enabled on all tenants by default for legacy support and has to be manually disabled! Enabling MFA DOES NOT automatically disable basic authentication since it allows support for static app passwords for applications that don’t support MFA out of the box. Disabling legacy authentication can cause issues with older applications that don’t support modern authentication. Disabling legacy authentication across the whole tenant needs to be done with caution. A user by user approach may be a better approach initially.

4. If your applications are complaining about failed authentication, check to see whether your account is not in fact the subject of a spray attack. Azure AD is trying to protect the account by locking itself out for a time period which affects good and bad attempts.

5. Use Cloud App Security and you’ll get a heads up on this sort of thing early on. Knowing what is happening makes it much easier to deal with and there really isn’t a better way than using Cloud App Security.

6. Use conditional access to restrict who can attempt to login to your tenant. Every one gets some free basic baseline policies from Microsoft but it is worth paying for Azure AD P1 to get the ability to be more granular. Don’t forget that Microsoft 365 Business comes with this granular Conditional Access ability out of the box now!

7. Consider having a ‘break glass’ emergency administrator account that you can call on to make admin changes if your only other existing administration account comes under attack and access becomes denied. This account doesn’t need a licence, it just needs permissions. It is hard to make changes to a tenant as an administrator if that account is subject to denial of service by a spray attack!

8. Even if you have MFA enabled, if you leave legacy authentication enabled, then even though attackers can’t correctly guess the password, their continued attempts could effectively result in a denial of service. This is very hard to mitigate, so look to eliminate all your legacy apps and protocols to prevent becoming collateral damage.

9. Review:

Azure AD and ADFS best practices: Defending against password spray attacks

as a good refence for the steps to protect your tenant against spray attacks. Remember, security is a journey and requires eternal vigilance and education.

10. Documentation before, during and after any incident is critical to knowing, understand and mitigating attacks. This all starts with preparation and knowing your situation and what can and needs to be done in a logical manner using tools like checklists. Your information is too important and valuable to leave to chance. Have a plan, your attacker does.

The more hardened your environment, the more likely attackers will simply move on to easier targets. Leaving legacy settings enabled is going to ensure they keep coming back to test your defences and potentially impacting your productivity as a side effect. In this case, once legacy authentication was disabled for the account the attacks ceased.