Password spraying mot Microsoft 365 upp 155 gånger och det var inte lösenordet som var hålet

1. Siffrorna

Enligt Huntress analys av trafiken under första halvåret 2026 handlar det inte om ett par isolerade incidenter utan om en systematisk kampanj i stor skala:

Källa: Huntress, "Tradecraft Tuesday"-serien, publicerad 2026.

Låt den sista siffran sjunka in. Av de 23 företag Huntress gick igenom i detalj saknade 8 stycken MFA helt, ett känt och väntat riskläge. Men 15 av dem hade MFA. Det som fällde dem var inte avsaknaden av ett skydd, utan att skyddet hade hål någon inte såg.

2. Så går attacken till

Password spraying i sig är inte en ny teknik. I stället för att testa många lösenord mot ett konto (vilket triggar utlåsning), testar angriparen ett fåtal vanliga eller läckta lösenord mot väldigt många konton, ofta med god tid mellan varje försök. Det brukar kallas "low and slow" och är byggt just för att glida under de trösklar som normalt stänger av ett konto efter för många felförsök.

Det som gör den här vågen ovanlig är verktyget angriparna riktade in sig på: Azure CLI, kommandoradsverktyget många IT-avdelningar och utvecklare använder för att administrera Microsoft 365 och Azure. Inloggning via Azure CLI kan ske via ett äldre autentiseringsflöde, ROPC (Resource Owner Password Credentials), där användarnamn och lösenord skickas direkt till Microsofts token-endpoint. Ingen webbläsare öppnas, ingen inloggningsruta visas för en människa och därför finns det heller ingen plats att visa en MFA-prompt.

3. Så kan luckan se ut hos ett företag som tror sig vara skyddat

4. Varför den här vågen är svår att se i tid

Utöver att gå runt MFA gör angriparna två saker till som gör upptäckt svårare. För det första sker sprayningen långsamt och distribuerat över väldigt många konton, så att inget enskilt konto samlar tillräckligt många felinloggningar för att trigga ett vanligt utlåsningslarm. För det andra roterar de infrastruktur, i det här fallet stora block av IPv6-adresser, vilket gör klassisk IP-baserad blockering betydligt mindre användbar. En adress som blockeras idag används sällan igen imorgon.

Resultatet är en attack som inte ser ut som en attack förrän man specifikt letar efter mönstret: många konton, få försök vardera, utspritt över tid och adressutrymme, riktat mot ett inloggningsflöde de flesta säkerhetsteam inte tänker på som en ingång alls.

5. Så täpper ni till luckorna

Huntress rekommendationer är konkreta och går, med undantag för sista punkten, att göra utan att investera i något nytt:

6. Vanliga frågor

Räcker MFA för att stoppa password spraying mot Microsoft 365?

Inte alltid. Av de granskade företagen med kapade konton hade två tredjedelar någon form av MFA på plats, men med luckor: policyn gällde inte alla appar, användargrupper eller klienttyper, eller så gick den att kringgå via ROPC. MFA är fortfarande ett av de viktigaste skydden, men bara om det faktiskt omfattar alla vägar in.

Vad är ROPC och varför är det ett problem?

ROPC är ett äldre OAuth-flöde där ett program skickar användarnamn och lösenord direkt till Microsofts token-endpoint, utan att en människa ser en inloggningsruta. Eftersom det inte finns någon interaktiv inloggning kan MFA inte visas som en prompt. Microsoft rekommenderar att blockera det helt om det inte används av en känd integration.

Hur vet vi om vår Conditional Access-policy faktiskt har luckor?

Gå igenom varje MFA-policy och kontrollera tre saker: om den ligger i Report-only-läge, om den har aktiva undantag för appar, grupper eller platser och om äldre protokoll som ROPC är blockerade separat. En policy kan se heltäckande ut i sammanfattningen och ändå ha ett eller flera av de här hålen.

7. Var kommer PIANOLA in i det här?

Det här är precis den typ av lucka PIANOLA är byggt för att hitta. Vi kopplar mot er Microsoft 365-miljö via Microsoft Graph och går igenom era faktiska Conditional Access-policys, inte bara att de finns, utan hur de faktiskt är konfigurerade: ligger någon policy i Report-only-läge, finns aktiva undantag, är äldre autentiseringsprotokoll som ROPC blockerade.

Vi översätter det till klartext i stället för en lång teknisk logg. I stället för "MFA är konfigurerat" får ni veta om det faktiskt gäller alla, eller om det finns en glömd väg förbi.

Det jag hade tagit med mig

"Vi har MFA" är inte längre ett tillräckligt svar på frågan om ni är skyddade. Frågan som spelar roll är om MFA:t har några vägar förbi sig, medvetna eller bortglömda. Den här vågen visar att skillnaden mellan de 8 företagen utan MFA och de 15 med luckor i sin MFA, i praktiken, inte var särskilt stor. Båda grupperna fick konton kapade.

Tre saker är värda att prioritera direkt: blockera ROPC om ni inte vet att ni behöver det, städa bort gamla undantag i era Conditional Access-policys och kontrollera att inget MFA-krav fortfarande ligger kvar i granskningsläge.