81 miljoen inlogpogingen op Microsoft 365: aanvallers omzeilen MFA via verouderde Azure CLI-route

Beveiligingsbedrijf Huntress ontdekte een grootschalige wachtwoordaanval die tussen 12 en 26 juni 2026 meer dan 81 miljoen inlogpogingen deed op Microsoft 365-omgevingen. Het verontrustende deel: bij een flink deel van de getroffen bedrijven werd de multifactor-authenticatie (MFA) simpelweg overgeslagen. Niet doordat MFA gekraakt werd, maar doordat de aanvallers een verouderde inlogroute misbruikten die nooit om een tweede factor vraagt. In totaal werden 78 accounts bij 64 organisaties overgenomen. Elk Nederlands bedrijf dat Microsoft 365 of Azure gebruikt, moet die legacy-route nu controleren en dichtzetten.

Hoe de aanval je MFA overslaat

De kern zit in de OAuth-flow genaamd ROPC (Resource Owner Password Credentials). Die neemt een gebruikersnaam en wachtwoord aan op het /token-endpoint van een tenant en geeft daar direct een geldig token voor terug. Het probleem: ROPC ondersteunt geen moderne authenticatie zoals MFA of single sign-on. Zoals Huntress in zijn analyse van de LSHIY-campagne uitlegt, gaat het wachtwoord bij deze route rechtstreeks naar het token-endpoint, zonder dat er ooit een interactieve MFA-prompt verschijnt.

De aanvallers gebruikten Azure CLI, de commandoregeltool van Microsoft, als vehikel voor die ROPC-flow. Ze probeerden daarbij geen willekeurige wachtwoorden, maar combinaties van gebruikersnamen en wachtwoorden uit eerdere datalekken: een klassieke password spray. Gestolen inloggegevens zijn de brandstof van dit soort aanvallen, precies zoals bij Operatie Endgame, waarbij 24 miljoen via infostealers buitgemaakte inloggegevens werden teruggevonden. Zodra een van die combinaties nog geldig was en het account niet tegen de ROPC-route beschermd was, had de aanvaller een token en dus toegang, zonder ooit een MFA-code te hoeven invullen.

De cijfers achter de campagne

De schaal is fors. Over de periode van 12 tot 26 juni telde Huntress ruim 81 miljoen inlogpogingen, met een piek op 22 juni: die dag werden 30 accounts bij 23 bedrijven geraakt. Het verkeer kwam van een IPv6-reeks van LSHIY LLC (AS32167), een hostingpartij met registraties in Hongkong, Wuhan en een gedeelde kantoorruimte in New York. Sommige IP-adressen leken uit China te komen, andere uit de Verenigde Staten, wat detectie op locatie lastig maakte.

Dit is bovendien geen incident dat op zichzelf staat. Volgens Huntress is het aantal password-spray-aanvallen over zijn klantenbestand in een half jaar tijd met een factor 155 toegenomen, tot gemiddeld bijna tweeduizend mislukte aanvallen per maand per beschermde omgeving. SecurityWeek beschrijft de campagne dan ook als een breed, aanhoudend patroon, geen eenmalige uithaal.

Waarom MFA hier niet hielp

Het meest leerzame detail: MFA aan hebben staan bleek niet genoeg. Van de 23 bedrijven die op de piekdag werden geraakt, hadden er 15 wel degelijk een MFA-beleid, maar dat beleid dekte de gaten niet. BleepingComputer zet de veelvoorkomende misconfiguraties op een rij:

• MFA werd afgedwongen voor specifieke apps in plaats van voor 'All Cloud Apps'.
• MFA gold alleen voor bepaalde gebruikersgroepen, bijvoorbeeld alleen beheerders.
• MFA was alleen verplicht vanaf niet-vertrouwde locaties, wat het aanvaller-IP met een Amerikaans locatielabel omzeilde.
• Bij twee organisaties stond het beleid in 'report-only': geimplementeerd, maar nooit afgedwongen.

Het komt er dus op neer dat een MFA-beleid dat niet elke gebruiker, elke cloud-app en elk type client-verbinding dekt, precies deze niet-interactieve routes openlaat. De aanvaller hoeft alleen de zwakste plek te vinden.

Wat dit betekent voor jouw bedrijf

Als je Microsoft 365 of Azure draait, zijn er drie concrete acties. Ten eerste: dwing MFA onvoorwaardelijk af voor alle gebruikers, alle cloud-apps en alle client-typen, niet alleen voor een selectie of alleen vanaf externe locaties. Ten tweede: blokkeer de legacy-authenticatie en de ROPC-flow specifiek, zodat wachtwoorden niet meer rechtstreeks tegen het token-endpoint kunnen worden ingewisseld. In Entra ID kan dat via de instelling die sterke client-authenticatie afdwingt. Ten derde: beperk Azure CLI-toegang voor gebruikers die het niet nodig hebben, want dat was het vehikel van deze campagne.

De onderliggende les is ouder dan deze aanval: een wachtwoord dat ooit ergens gelekt is, blijft je zwakke plek zolang het herbruikt wordt en er een route bestaat die de tweede factor overslaat. Het loont om die basis periodiek zelf na te lopen, van wachtwoordhygiene tot conditionele toegang, aan de hand van een praktische vijflaags-basischeck voor cybersecurity in het MKB. MFA aanzetten is niet het eindpunt, maar het begin. De vraag die je vanavond nog kunt beantwoorden is simpel: dekt jouw MFA-beleid ook de routes waar geen mens naar kijkt?