← Terug naar blog
Security

Azure CLI als aanvalsvector: 81 miljoen inlogpogingen leggen een blinde vlek in Conditional Access bloot

Door Zarioh Digital Solutions6 min leestijd
Delen
Azure CLI als aanvalsvector: 81 miljoen inlogpogingen leggen een blinde vlek in Conditional Access bloot

Van 12 tot 26 juni 2026 voerden aanvallers meer dan 81 miljoen inlogpogingen uit via de Azure CLI. Niet via phishing, maar via de OAuth ROPC-stroom die buiten het bereik valt van de meeste Conditional Access-policies. Tenminste 78 accounts bij 64 organisaties raakten gecompromitteerd. Wat is ROPC, waar zit het lek en hoe dicht u het vandaag nog?

In de tweede helft van juni 2026 vond een van de grootschaligste wachtwoordspray-campagnes tot nu toe plaats die specifiek gericht was op Microsoft 365-omgevingen. Aanvallers verstuurden meer dan 81 miljoen inlogpogingen in veertien dagen, gebruikten referenties uit eerdere datalekken en wisten bij minstens 78 gebruikersaccounts verspreid over 64 organisaties een geldig token te bemachtigen. Wat de aanval onderscheidend maakt, is niet het volume, maar de vector: Azure CLI via de OAuth Resource Owner Password Credentials-stroom.

Veel IT-teams hanteren zorgvuldig gebouwde Conditional Access-policies die aanmeldingen via browser en mobiele apps afdekken. De ROPC-stroom valt daar structureel buiten. Dat maakte deze campagne effectiever dan een klassieke phishingaanval en blootgelegd een configuratiegat dat in talloze tenants nog open staat.

Wat is de ROPC-stroom en waarom gebruikt Azure CLI die?

ROPC staat voor Resource Owner Password Credentials en is een OAuth 2.0-flow waarbij de gebruikersnaam en het wachtwoord rechtstreeks naar het token-eindpunt van de identiteitsprovider worden gestuurd. Er is geen browser-redirect, geen loginpagina en geen interactieve stap. De client, in dit geval Azure CLI, wisselt de inloggegevens direct in voor een toegangstoken.

Azure CLI maakt van oudsher gebruik van ROPC voor niet-interactieve scenario's: scriptautomatisering, pijplijnen in CI/CD-systemen en beheerscripts die zonder menselijke tussenkomst draaien. De stroom is ook ondersteund door andere Azure SDK-clients en diverse legacy-toepassingen die zijn gebouwd vóór moderne OAuth-flows breed beschikbaar waren.

Het cruciale verschil met een interactieve aanmelding is dat Entra ID de ROPC-aanmelding registreert als een niet-interactieve aanmeldpoging. Daarmee valt de sessie buiten het bereik van Conditional Access-policies die alleen op interactieve aanmeldingen van toepassing zijn, wat in de meeste standaard-configuraties het geval is.

Waarom vuurt MFA niet bij ROPC?

Multifactorauthenticatie zoals het invullen van een TOTP-code of het goedkeuren van een melding in de Authenticator-app is een interactieve handeling. Bij een ROPC-aanmelding is er geen gebruikersinterface en dus geen mogelijkheid voor de gebruiker om die tweede factor aan te leveren. Entra ID accepteert een geldig gebruikersnaam-wachtwoordpaar via ROPC en geeft een token terug, tenzij u expliciet hebt ingesteld dat ROPC is geblokkeerd of dat elke aanmelding een authenticatiesterkte vereist die ROPC niet kan leveren.

De veelgemaakte fout is dat Conditional Access-policies worden gebouwd met als doel 'MFA afdwingen bij aanmelden vanuit onbekende locaties' of 'MFA vereisen voor bepaalde apps'. Als de policy alleen de interactieve aanmeldingen omvat, en de ROPC-aanmelding voor dezelfde apps of gebruikers niet, dan is er een lek. De aanvallers in de LSHIY-campagne maakten daar systematisch gebruik van door per organisatie te testen of ROPC werkte voordat ze een grotere spraayronde inzetten.

Welke organisaties liepen risico?

Het risicoprofiel is breder dan verwacht. Elke organisatie die ROPC niet expliciet heeft geblokkeerd in Entra ID, loopt risico zolang er accounts zijn met een zwak of gelekt wachtwoord. In de campagne van juni 2026 werden uitsluitend referenties ingezet die circuleerden in lijsten van eerdere datalekken. Organisaties die geen wachtwoordbescherming actief hebben, die geen smartlockout-drempel hebben ingesteld, of die accounts hebben van ex-medewerkers die nog actief zijn in Entra, waren bijzonder kwetsbaar.

Een tweede risicogroep zijn tenants met Conditional Access in report-only modus. In die modus worden policies geëvalueerd maar niet afgedwongen, wat betekent dat de logs tonen dat een aanmelding zou zijn geblokkeerd, maar de aanmelding desondanks slaagt. Tijdens de implementatie van Conditional Access is report-only een handige tussenstand, maar als die modus maanden of jaren blijft staan, biedt de policy geen enkele bescherming.

ROPC blokkeren in Entra ID: de configuratiestappen

De meest directe verdediging is het volledig blokkeren van de ROPC-stroom voor gebruikersaccounts. Dit doet u via een Conditional Access-policy die Authentication flows instelt als conditie en de Resource Owner Password Credentials-stroom expliciet blokkeert. De policy geldt voor alle gebruikers, alle apps, en vereist geen uitzondering tenzij u een gedocumenteerd systeem heeft dat ROPC nodig heeft.

Voor de uitzonderingsgevallen, automatisering en scripts die nu nog ROPC gebruiken, is het advies om deze om te schrijven naar client credentials met een managed identity of een service principal met certificaatverificatie. Dat zijn moderne, veilige alternatieven die geen gebruikerswachtwoord nodig hebben en dus ook niet vatbaar zijn voor credential stuffing.

Parallel aan het blokkeren van ROPC stelt u een Conditional Access-policy in die Authentication Strength afdwingt op alle aanmeldingen. Kies de ingebouwde sterkte Phishing-resistant MFA als vereiste, of maak een aangepaste sterkte die passkeys en Windows Hello for Business omvat. Een aanmeldpoging via ROPC kan per definitie niet aan deze sterkte voldoen en wordt dan automatisch geblokkeerd, ook als u de ROPC-stroom niet separaat hebt uitgesloten.

Wat ziet u in de Entra-logs?

Om te controleren of ROPC actief is in uw tenant opent u het Entra-portaal, gaat u naar Sign-in logs en filtert u op Authentication protocol met de waarde ROPC. Als u resultaten ziet, weet u dat ROPC wordt gebruikt. Bekijk vervolgens of de aanmeldingen afkomstig zijn van legitieme geautomatiseerde processen of van onbekende IP-adressen en locaties. Aanmeldingen van dezelfde gebruiker vanuit meerdere geografisch verspreide IP-adressen binnen een korte tijdsspanne zijn een sterk signaal van een actieve spray.

Organisaties met Microsoft Sentinel kunnen een analytics-regel bouwen die waarschuwt wanneer meer dan vijftig ROPC-pogingen vanuit hetzelfde IP-adres worden gedetecteerd binnen een vijf minuten durend venster. Dat patroon is kenmerkend voor geautomatiseerde spray-tooling en vrijwel nooit het resultaat van legitiem gebruik.

Aanvullende verdedigingslagen

ROPC blokkeren is de directe maatregel, maar een gelaagde aanpak biedt betere bescherming. Microsoft Entra ID Protection, beschikbaar vanaf het P2-licentieniveau, detecteert risicovolle aanmeldingen op basis van gedragspatronen en lekdetectie. Stel sign-in risk policies in die bij medium en hoog risico automatisch MFA afdwingen of de sessie blokkeren. Dit vangt ook aanvalsvectoren op die niet via ROPC lopen.

Microsoft Entra Password Protection blokkeert veelgebruikte en bekende zwakke wachtwoorden zowel in de cloud als in on-premises Active Directory. Gezien de campagne van juni uitsluitend gebruikmaakt van gelekte wachtwoordlijsten, helpt dit de schade te beperken voor accounts die nog geen sterk wachtwoord hanteren.

De meest definitieve maatregel is het elimineren van wachtwoorden voor gebruikersaccounts. Een passkey of Windows Hello for Business-inschrijving maakt een account volledig immuun voor elke vorm van wachtwoordspray, inclusief ROPC, omdat er simpelweg geen wachtwoord meer bestaat om te kraken of te herspelen.

Wat doet u deze week?

Drie concrete acties die u direct kunt inplannen. Eerste actie: open de Entra sign-in logs en filter op ROPC. Stel vast of en door wie deze stroom wordt gebruikt. Dit duurt minder dan vijf minuten en geeft u direct inzicht in het blootgestelde oppervlak.

Tweede actie: controleer uw Conditional Access-policies op coverage van niet-interactieve aanmeldingen. Controleer of de policies op Enabled staan in plaats van Report-only en of alle gebruikers en alle apps worden gedekt. Een policy die uitzonderingen maakt voor service-accounts of legacy-apps is een potentieel lek.

Derde actie: plan de ROPC-blokkade in voor alle gebruikersaccounts. Informeer beheerders die eventueel gebruik maken van Azure CLI in scripts zodat zij hun workflows kunnen omzetten naar managed identities of service principals. De blokkade zelf is in Conditional Access binnen tien minuten geconfigureerd.

Wilt u een onafhankelijke audit van uw Conditional Access-configuratie, hulp bij het ontwerpen van een wachtwoordloze strategie of begeleiding bij de migratie van ROPC-afhankelijke scripts? Neem contact op met Zarioh voor een praktisch gesprek zonder verplichtingen.

Was dit artikel nuttig?

Z

Zarioh Digital Solutions

IT-specialisten uit Utrecht. Wij helpen bedrijven door heel Nederland met Microsoft 365, AI agents, hosting en telefonie — en delen hier wekelijks wat we in de praktijk tegenkomen. Volg ons op LinkedIn

Nieuwsbrief

Laatste tech nieuws

Ontvang nieuwe artikelen direct in je inbox.

Geen spam. Afmelden kan altijd.

Lees ook

← Terug naar alle artikelen
Delen