How to proactively prevent password-spray attacks on legacy email accounts

Microsoft recently released a security news update that addresses chilling reports that attackers have been able to pivot from a test tenant to the C suite to obtain access to emails being sent and received. In addition, it came to light that HPE’s corporate mailboxes had been accessed using a similar exploit.

Both appear to be related to a password spray attack against legacy email accounts that did not have multifactor authentication enabled. Let’s break down Microsoft’s post and how we can proactively prevent such attacks in our own organization.

Microsoft indicated that: “Midnight Blizzard [a Russian state-sponsored actor also known as NOBELIUM] utilized password spray attacks that successfully compromised a legacy, non-production test tenant account that did not have multifactor authentication (MFA) enabled. In a password-spray attack, the adversary attempts to sign into a large volume of accounts using a small subset of the most popular or most likely passwords.”

Make sure multifactor authentication is enabled

One lesson to be learned from this is to ensure that multifactor authentication (MFA) is enabled on everything and review processes used for test accounts that have access to your main production Microsoft 365 tenant. These days, MFA should be mandatory for any cloud service — don’t rely on just a password to protect any cloud asset.

If your user base objects to MFA implementations, there are ways to make it more palatable. With the use of conditional access, you can configure it such that MFA is not mandated from a trusted location. But don’t get too complacent; if attackers gain access to a trusted location, conditional access/whitelisting an IP address to ensure your executives are not annoyed with an MFA prompt may not be the way to go. Depending on the risk tolerance of your user base, you may decide that this policy is not wise.

Microsoft indicated that the attacks came from IP addresses that didn’t appear harmful. “The threat actor further reduced the likelihood of discovery by launching these attacks from a distributed residential proxy infrastructure,” according to the update. “These evasion techniques helped ensure the actor obfuscated their activity and could persist the attack over time until successful.”

Thus, normal defenses would have not flagged them as having come from risky locations. You may wish to consider installing static IP addresses in home settings for those individuals in your organization most likely to be targeted by attackers. The use of a static IP address means that you can identify and protect these accesses better than mere residential home IP addresses that may change over time.

Pay attention to the location from which users log on

Often with an ISP it’s hard to determine the exact location from which a user is logging in. If they access from a cellphone, often that geographic IP address is in a major city many miles away from your location. In that case, you may wish to set up additional infrastructure to relay their access through a tunnel that is better protected and able to be examined. Don’t assume the bad guys will use a malicious IP address to announce they have arrived at your door.

According to Microsoft, “Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment. The actor created additional malicious OAuth applications.”

The attackers then created a new user account to grant consent in the Microsoft corporate environment to the actor-controlled malicious OAuth applications. “The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.”

This is where my concern pivots from Microsoft’s inability to proactively protect its processes to the larger issue of our collective vulnerability in cloud implementations. Authentication has moved away from the traditional username and password to application-based authentication that is more persistent. In addition, we often don’t understand what we are setting up in a cloud environment and accidentally leave permissions in such a state as to make it easier for the attackers to gain a foothold.

Configuring permissions to keep control of access parameters

Any user can create an app registration and then consent to graph permissions as well as share any corporate data. You need to set up your tenant to require an application administrator or cloud-application administrator to grant a user the right to add such a third-party OAuth-based app to the tenant rather than allowing users to be self-service.

This is especially the case in an organization that manages sensitive information of any kind — all apps that are added to the Microsoft 365 tenant should be manually approved by an authorization process.  In the Microsoft 365 Admin Center select Settings, then Org Settings, scroll down to User Consent to Apps.

Uncheck the box that allows users to provide consent when apps request access to your organization’s data on their behalf. You want to vet applications before they get deployed to your users. The approach for the cloud is no different.

Next go to Entra.microsoft.com in Application Settings and look for App Registrations. Ensure you have identified and recognized the applications listed. Don’t panic if you see a P2PServer listed, it’s a placeholder of the first AD joined machine. But vet and investigate any other application.

Susan Bradley

Next, go into User Settings and disable those that allow users to register their own applications:

“Named Users can register applications” should be: No.

“Restrict non-admin users from creating tenants” should be: Yes.

“Users can create security groups” should be: No.

“Restrict access to the Microsoft Entra admin center” should be: Yes.

You do want users to submit admin consent requests when setting up such an application. Test the approval process to ensure that the administrator you intend gets the prompt and vets the approval accordingly.

Be sure that any administrative user does not sign in from a personal device. Ensure you always use a dedicated secured device for administrative work and no other device.

Cloud applications can grant potentially dangerous rights to users

We have encouraged and used cloud applications to make our lives easier but they have also introduced potentially dangerous rights. Another such role that may be abused in the AppRoleAssignment.ReadWrite.All MS Graph app role that bypasses the consent process. This was by design and was meant for its implementation. As a result, this app role is dangerous if you don’t understand the implications.

Too often our developers and implementers have read a blog post or used a recommendation without truly understanding the risks. Often, we don’t go back and audit how our cloud implementations are working, nor do we keep a constant review of the changing defaults and introduction of new security defaults and features.

In light of this situation, you’ll want to go back and review if you have specifically assigned the AppRoleAssigment.ReadWrite.All that inadvertently gave higher privileges than you intended. A better way to implement application permissions is to avoid using this role and instead use Consent Policy.

The bottom line is: don’t just deploy new cloud technologies without looking for cloud-hardening guidance as well. Review the recommendations by CIS benchmarks, and other vendors that provide Azure hardening advice. Don’t just take the defaults provided by the vendor, clouds need hardening too — they are not secure by default.