Detecting and Protecting Entra ID from Password Spray Attacks

In ‘the olden days,’ identities were protected by a large, locked-down firewall installed in your on-premises network. This decreased the opportunity for attackers to execute brute force attacks against the on-premises environment. With the move to the cloud, many organizations synchronize identities to Azure Active Directory. This makes an attacker’s job easier as they have a single point where they can attempt to compromise accounts. As the security team, it’s our job to protect the organization from these attacks. In this article, I walk through the protection and detection mechanisms available to repel password spray attacks.

What is a Password Spray?

The term ‘password spray‘ describes an attempt by an attacker to test multiple passwords against accounts over a short period. This can be a dictionary attack where a list of known passwords is used, or it can be an attack based on leaked account credentials.

Attackers launch password sprays attacks constantly. The chances are that every organization is the target for at least one of these attacks daily. While working in our cloud SOC, we regularly observe password spray attempts across multiple organizations. Open-source tools to launch password spray attacks are readily available on GitHub, a factor that undoubtedly contributes to the number of attacks.

Don’t Ignore Authentication Failures

Multifactor Authentication is one answer to password sprays, and while Microsoft is very keen on this approach, it is not the end-all solution. Even if a password spray attack fails because the multifactor challenge defeated the attempt, the attempt is still something you should deal with.

When a password spray fails because of MFA, the attacker knows the correct password for the user. This is a bad situation for two reasons:

• Not all systems are equal, and chances are that an organization has systems that aren’t protected by MFA (such as a VPN/Citrix solution). To avoid a breach of those systems, the user’s password should be reset as soon as possible.
• With a successful password, an attacker has one foot in the door of your organization and can move forward rapidly. Avoiding leaked passwords means your organization is better protected.

Using Smart Lockout

Smart Lockout can protect an organization from password sprays. Smart Lockout is enabled by default in every tenant and can be configured to meet an organization’s needs. Smart Lockout monitors failed sign-ins and locks accounts when the number of failed sign-ins exceeds the threshold. The beauty is that Smart Lockout is more intelligent than the traditional Active Directory feature, as it will only lock out the account for the data center the sign-ins are originating from. Image if our user resides in Belgium and our attacker is trying to log in from the United States. Smart Lockout will only block the user sign-ins from the United States and the user can keep logging in from Belgium.

The Curse of Legacy Protocols

While many organizations block legacy authentication through Conditional Access, an important protection step against password sprays is the deployment of Exchange Online Authentication Policies. While Microsoft will block legacy authentication for seven email connectivity protocols in January 2023, I still recommend that you use authentication policies. Most brute force attacks happen through legacy authentication, and Conditional Access will not stop a password spray. Authentication Policies stop pre-authentication requests, meaning a password spray using legacy authentication for a blocked policy will fail without the attacker receiving any indication that a password is good or bad.

Using Azure AD Identity Protection

Microsoft can actively monitor Azure Active Directory for password sprays using Azure AD Identity Protection. Identity Protection is part of the Azure Active Directory Premium 2 Plan and will identify current password spray attacks on an environment.

Microsoft has invested heavily in detection mechanisms and has strong data analytics to detect if a password spray attack is ongoing. If a password spray is detected, an Identity Protection alert is raised. This is an important note; there are no additional prevention mechanisms; Identity Protection delivers additional monitoring instead of remedial processing.

With the identity protection alert, the SOC can investigate what’s happening and decide if additional actions are needed. Microsoft provides a complete overview of what a password spray investigation looks like on Microsoft Learn.

Using Microsoft Sentinel for Detection

Microsoft Sentinel delivers the most flexibility for attack detection. While Identity Protection will alert you about a potential password spray, there is no way to tweak the underlying algorithms. With Identity Protection, there is no way to know when and why it signals a detection.

By using Microsoft Sentinel, we can create custom analytics rules using granular thresholds to decide when an alert should be generated. Before creating analytic rules, we first need to send sign-in logs to Microsoft Sentinel. When using Azure Active Directory, this can be done using the native data connector for Microsoft Sentinel. Of course, Sentinel is not limited to Azure Active Directory, and these types of detections can also be created for other sources such as Okta and OneLogin.

After connecting your Identity Provider to Microsoft Sentinel, it is time to create a suitable query. Building a query always starts with identifying the correct tables. For Azure Active Directory, sign-in logs are stored in the SigninLogs table.

After selecting the correct table, we need to find out which filters to use to retrieve the desired information. Each sign-in has a resultType column, which is a status code detailing if the sign-in was successful and, if applicable, the failure reason. Building the correct filters is complex and can take some time, certainly when you are new to Microsoft Sentinel.

When you are new, I recommend leaning on the community to move forward. For this use case, a query is available on the Microsoft Sentinel GitHub page.

This query executes the following:

• Identify the result types when a failure occurs because of a wrong password
• Retrieve all failed logins attempts per user
• Checks if the number of failed attempts exceeds a failed login

While this query looks complex, it is important to divide it into different steps and interpret it. Using the smaller chunks in a query makes it much easier to understand.

Keeping Attackers Out

The number of password sprays has increased since organizations moved to Azure AD. It’s likely that the number of these attackers will continue to increase. Although many attacks can be blocked by turning off legacy authentication, attackers have adapted and are using new attack paths. Every organization should try to use as many preventive measures as possible, but monitoring is key. When monitoring for password sprays, you should identify what actions attackers take and how these could be blocked in the future.