Je MFA staat aan en je bent tóch gehackt: de ROPC-maas in Conditional Access

Je hebt MFA aangezet. Je hebt Conditional Access policies ingesteld. Je vinkt het audit-hokje aan en denkt: identity is geregeld. Tot je op een ochtend je Azure AD sign-in logs opent en ziet dat er 81 miljoen loginpogingen zijn gedaan, en dat 78 accounts zijn gecompromitteerd. Bij organisaties mét MFA.

Dat is geen hypothetisch scenario. Het is wat Huntress deze week rapporteerde in een diepgravende analyse van de LSHIY password spray-campagne. En het legt een gat bloot waar de meeste Nederlandse organisaties geen weet van hebben.

De aanval: 81 miljoen pogingen, één vergeten protocol

Tussen 12 en 26 juni 2026 vuurde een geautomatiseerde aanval 81 miljoen loginpogingen af op Microsoft 365-omgevingen. De aanval kwam vanaf IPv6-adressen in het bereik van LSHIY LLC, een internetinfrastructuurprovider met registraties in Hong Kong, Wuhan, en een gedeeld kantoor in New York. De aanvallers gebruikten oude username/password-combinaties uit eerdere datalekken, credentials die nooit waren geroteerd.

Tot zover niets nieuws. Password spraying is een beproefde techniek: probeer één veelgebruikt wachtwoord tegen duizenden accounts, in plaats van duizenden wachtwoorden tegen één account. De volumes zijn hoog, de success rates laag. Een spel van grote getallen.

Wat deze campagne anders maakt, is hoe de aanvallers door de MFA-verdediging heen kwamen. Ze gebruikten niet de interactieve login-pagina waar je MFA-prompt verschijnt. Ze gebruikten de Azure CLI, specifiek het ROPC-flow.

ROPC: het protocol dat MFA omzeilt

ROPC staat voor Resource Owner Password Credentials. Het is een OAuth 2.0 grant type dat in OAuth 2.1 is gedeprecieerd. De flow is simpel: je stuurt een username en password naar het /token endpoint van een tenant, en je krijgt een token terug. Geen browser. Geen interactieve prompt. Geen MFA.

# Zo simpel is het, geen MFA, geen pop-up, gewoon een token
az login --username admin@bedrijf.nl --password Winter2024!

ROPC bestaat voor legacy-applicaties die geen moderne authenticatie ondersteunen. Denk aan scripts die 's nachts draaien, oude line-of-business apps, of geautomatiseerde deployment pipelines. Het is een noodverband uit een tijd waarin MFA nog geen standaard was.

Maar het noodverband zit er nog steeds. En aanvallers weten dat.

Huntress ontdekte dat de aanvallers eerst credentials valideerden via password spraying, en daarna de gevalideerde credentials herspeelden via het ROPC-flow. Omdat ROPC geen MFA ondersteunt, het stuurt het wachtwoord rechtstreeks naar het token-endpoint zonder interactieve prompt, kregen ze een geldig token terug. Zonder ooit een MFA-uitdaging te zien.

De configuratiefout die iedereen maakt

Dit is waar het pijnlijk wordt. Van de 23 organisaties die op 22 juni werden geraakt, hadden er 15 MFA geïmplementeerd én afgedwongen via Conditional Access Policies. Vijftien organisaties die dachten dat ze beschermd waren. Vijftien organisaties die bij een audit konden aantonen: "kijk, MFA staat aan."

Wat ging er mis? Huntress identificeerde vier configuratiefouten:

1. MFA alleen voor specifieke apps, niet voor "All Cloud Apps." Sommige organisaties hadden MFA afgedwongen voor Microsoft Admin Portals, maar niet voor de Azure CLI. De aanvallers logden in via de CLI, en de CAP greep niet in.

2. MFA alleen voor specifieke gebruikersgroepen. "Admins Only" is een veelgebruikte instelling. Maar de gecompromitteerde accounts waren geen admins, het waren gewone gebruikersaccounts die toevallig in een datalek voorkwamen. De CAP was niet op hen van toepassing.

3. MFA alleen vanaf niet-vertrouwde locaties. Dit is de klassieker: "als iemand vanaf kantoor inlogt, is het veilig." De aanvallers gebruikten IPv6-adressen die door derde-partij geolocatie-tools inconsistent werden gelabeld, sommige tools zagen "Nebraska", andere zagen "China". Een CAP die vertrouwt op geolocatie is zo sterk als de data waarop hij vertrouwt.

4. MFA in report-only mode. Twee organisaties hadden MFA geïmplementeerd maar nooit afgedwongen. De policy stond op "report only", hij logde wat er gebeurde, maar blokkeerde niets. Het security-equivalent van een inbraakalarm dat alleen een e-mail stuurt.

Acht organisaties hadden helemaal geen MFA. Die zijn bijna niet interessant, dat is gewoon nalatigheid. De vijftien organisaties mét MFA die tóch gecompromitteerd werden, dát is het verhaal.

Wat dit betekent voor Nederlandse organisaties

Voor BIO2 is dit een regelrechte nachtmerrie. B.3.2 schrijft identity en access management voor. B.3.3 vereist technische kwetsbaarheden-management. Maar een CAP die ROPC niet dekt, is een technische kwetsbaarheid die niet in je asset-inventory staat. Het is geen CVE. Het is een configuratiefout die pas zichtbaar wordt als iemand hem misbruikt.

Voor NIS2 is het nog erger. Artikel 21 lid 2(i) vereist authenticatie en encryptie. Als je kunt aantonen dat je MFA hebt geïmplementeerd, ben je compliant, tenzij een auditor doorvraagt. "Dekt uw MFA-beleid ook de Azure CLI? En ROPC? En legacy protocollen?" De meeste organisaties kunnen die vraag niet beantwoorden.

Voor de AVG is een gecompromitteerd M365-account een datalek. E-mail, SharePoint, Teams, allemaal potentiële bronnen van persoonsgegevens. Artikel 32 vereist passende technische maatregelen. Een CAP die ROPC niet dekt, is geen passende maatregel.

De fix: drie regels die je vandaag moet instellen

Het goede nieuws: dit is te fixen. Het slechte nieuws: bijna niemand heeft het gefixt.

Regel 1: Blokkeer ROPC. De eenvoudigste mitigatie is ROPC uitschakelen voor alle gebruikers die het niet nodig hebben. In Azure AD: Authentication Methods > Legacy Authentication > Block ROPC. Voor de meeste organisaties is ROPC een relikwie, niemand gebruikt het bewust, het staat gewoon nog aan.

Regel 2: CAP voor All Users, All Cloud Apps, All Client App Types. Niet "Admin Portals." Niet "specifieke gebruikersgroepen." Alles. Unconditioneel. De instelling userStrongAuthClientAuthNRequired dwingt sterke authenticatie af op client-niveau en blokkeert ROPC-flows volledig.

Regel 3: Monitor op ROPC-gebruik. Zelfs als je denkt dat niemand ROPC gebruikt, moet je het monitoren. Azure AD sign-in logs hebben een client_app veld, filter op client_app == "Microsoft Azure CLI" en authentication_protocol == "ropc". Als je hits ziet, weet je dat iemand, of iets, dit protocol gebruikt.

// Azure AD sign-in logs, ROPC detectie
SigninLogs
| where ClientAppUsed == "Microsoft Azure CLI"
| where AuthenticationProtocol == "ropc"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, ResultType

De grotere les: compliance is geen security

De LSHIY-campagne illustreert een ongemakkelijke waarheid: je kunt volledig compliant zijn en tóch gecompromitteerd worden. MFA stond aan. CAPs waren geconfigureerd. Het audit-hokje was aangevinkt. En toch waren 78 accounts van 64 organisaties gecompromitteerd.

Compliance vraagt: "Heb je MFA?" Security vraagt: "Dekt je MFA ook de Azure CLI? En ROPC? En legacy protocollen? En wat gebeurt er als een aanvaller vanaf een IPv6-adres inlogt dat door jouw geolocatie-tool als 'Nebraska' wordt gelabeld?"

Het verschil tussen die twee vragen is het verschil tussen een vinkje en een verdediging.

---

Bron: Huntress, "No (Bad) CAP: Inside an Ongoing LSHIY Password Spray Attack," 30 juni 2026. huntress.com/blog/lshiy-password-spray-attack