Cloud Security
,
Multi-factor & Risk-based Authentication
,
Security Operations
Threat Actor Uses Deprecated OAuth 2.0 Authentication Flow

Attackers behind a password-spraying campaign targeting Microsoft Office 365 accounts have amassed dozens of victims, in some cases succeeding even when multifactor authentication is enabled.
See Also: Proof of Concept: Automating Security Safely With Agentic AI
Cybersecurity firm Huntress said the automated, brute-force attacks attempt to use the credentials to access the Microsoft Azure command-line interface.
From June 12 through Friday, the company logged 81 million login attempts against its customer base, leading to attackers successfully gaining remote access to at least 78 accounts across 23 organizations. In some cases, this access succeeded despite the victims using Microsoft Entra Conditional Access, the technology giant’s Zero Trust policy engine. Conditional access is designed to protect access to Microsoft 365 environments in part by requiring multifactor authentication.
Multiple organizations have reported on Reddit being on the receiving end of these attacks, saying they trace to a handful of IPv6 addresses assigned to Chinese infrastructure provider LSHIY, with each malicious IP address executing 75 attacks per user, per hour. In some cases, the volume of attacks is leading legitimate users’ accounts to be locked before access policies even come into play. Entra’s Smart Lockout feature, aka Azure AD Smart Lockout – designed to distinguish between bots and legitimate users – doesn’t necessarily help.
“Smart Lockout doesn’t seem to make the attacker move on, likely because this is bot/AI-initiated. We end up having to change the username itself to stop the attacks, but that’s obviously not scalable for thousands of accounts should the scope increase,” one user posted to Reddit.
Huntress said the attacker appears to be cycling through a vast number of stolen credentials. “The threat actor appeared to be using old username/password combinations where the credentials were previously breached but had never been rotated,” it said in a Tuesday report. It isn’t clear whether these were amassed by information-stealing malware or are circulating in collections of leaked online credentials.
Customers, who fell victim to the attack, despite potentially having MFA enabled, were exposed due to their not blocking an open authorization security standard version 2.0 feature that allows for a resource owner password credentials grant. The grant type facilitates generating valid authentication tokens on a user’s behalf if an application or service provides their valid username and password.
“This auth flow takes a username/password at the /token endpoint for a tenant and mints a new user-delegated token once provided with the correct credentials,” then sends “the password straight to the /token endpoint with no interactive MFA prompt,” Huntress said.
Attackers, who possess valid user credentials, can use the ROPC authentication grant workflow built to gain remote access to organizations.
“The attack bypasses MFA and SSO because it uses the deprecated, but still functional, OAuth Resource Owner Password Credentials 2.0 flow. But it works because some people still use creds that were stolen years ago and were never changed. So change your passwords, people!” said Andrew Brandt, a cybercrime analyst at Huntress who co-authored the research, in a post to social platform Mastodon.
The Internet Engineering Task Force standards body deprecated ROPC in OAuth 2.1, due to it posing a security risk (see: Behind the Scenes of a Business Email Compromise Attack).
While version 2.1 has been published in draft form, the IETF has yet to issue a final version, although many organizations have already adopted the security revisions.
To guard against attackers using ROPC, organizations can use Conditional Access to require MFA for Azure CLI logins. But the victim organizations weren’t doing so. Of the 23 customers Huntress counted that fell victim, one-third had no MFA policy in place at all. Others applied it only to specific groups or applications, and two organizations had it in report-only mode, meaning it wasn’t being enforced.
Some organizations restricted MFA based on location, which isn’t a reliable stand-alone control. “Several businesses had MFA set up so that it was only required from non-trusted locations, which the attacker’s U.S.-geo-mislabeled IP address was able to evade,” Huntress said.
To guard against such attacks, researchers advised organizations to ensure they’ve correctly configured Conditional Access policies to apply to all users, cloud apps as well as client types. Also, ensure that the userStrongAuthClientAuthNRequired parameter is active, since this will require MFA as part of the authentication flow, before granting access. Also consider restricting access to the Azure CLI application to admin users only.
In the bigger picture, this is only one campaign, and many more such attacks continue to unfold, not only targeting PCs but also edge devices such as routers, firewalls and virtual private network appliances.
“In the past six months, Huntress has observed the volume of credential spray attacks increase by over 155 times across our customer base. Attacks surged in particular in late May through early June, with a current mean value of about 1,964 failed attacks per month per Huntress-protected tenant,” it said.
These password-spraying attacks appear to be not only highly automated but also opportunistic. “The targeting of these attacks seems to be based entirely on password prevalence on compromised password combo lists, and is not specific to business type or industry,” Huntress said.
