Huntress published research on 19 August 2026 reporting a 155x increase in password spraying attacks over the first half of 2026.

Take that multiple with some care — the firm does not state the baseline it is measured against, and a very large multiple of a very small number is a different story from a very large multiple of a large one. What the rest of the research contains is more useful than the headline figure anyway.

The campaign

Huntress tracks it as LSHIY, and the target is Microsoft's Azure CLI.

In the peak fortnight in mid-June 2026 it generated more than 81 million login attempts and produced 78 account compromises. Infrastructure ran through an IPv6 range on a bring-your-own-IP service, later shifting to the providers FranTech and 3xK Tech.

Note the ratio. 81 million attempts for 78 accounts is a hit rate close to zero, and it did not need to be better than that. Spraying is a volume business, and the cost of an attempt is now effectively nothing.

The mechanism: a grant that was designed without MFA

The interesting part is not the volume. It is the door.

ROPC — Resource Owner Password Credentials — is a deprecated OAuth 2.0 grant type. It sends the username and password straight to the token endpoint, with no interactive prompt. That is the entire design: it exists for legacy applications that cannot open a browser window.

No interactive prompt means no place to put an MFA challenge. So an authentication path built for a world before MFA is still there, still accepted, and still hands out tokens to whoever has the right password.

That is a general pattern worth naming: a security control only covers the authentication paths it can be inserted into. The same shape appears in the passkey attack paths in Entra and in the ADFS signing keys that make the login irrelevant.

Why MFA did not save most of them

Huntress analysed 23 affected organisations. 8 had no MFA at all.

The other 15 are the story. They had MFA, and it did not apply to the attacker's sign-in attempts — because the policies were scoped to certain applications or user groups, because they relied on trusted locations, or because they were still in report-only mode.

Report-only is the one to sit with. It is the intended way to test a Conditional Access policy before enforcing it, and it is also a policy that logs what it would have blocked and blocks nothing. An organisation in that state has a dashboard showing MFA working and an authentication path where it is not.

"Do you have MFA" is the wrong question. "Which sign-ins does your MFA policy actually evaluate, and is it enforcing or reporting" is the question.

What to do

  • Disable ROPC. It is deprecated, most estates have no application that needs it, and it is the specific path used here.
  • Check every Conditional Access policy for report-only. Then check when it was put there. Report-only is a test state, not a destination.
  • Require MFA across all users and all applications, not a named list. Scoped policies fail exactly where the scope ends.
  • Stop treating trusted locations as an exemption. An IP range is not an identity, and a bring-your-own-IP service is what this campaign used.
  • Restrict Azure CLI to administrators. Most users have no reason to authenticate to it.
  • Alert on volume, not just success. 81 million attempts is loud. The failures are the detection, and they arrive long before the compromise does.

What is not established

  • The baseline behind 155x. Huntress does not state what the increase is measured from.
  • Who runs LSHIY. No attribution has been published.
  • What happened after the 78 compromises. The research covers the access, not the outcome.
  • Whether the 23 organisations are representative. They are Huntress customers where the campaign was observed, not a survey.