Tussen 12 en 26 juni 2026 vuurde een aanvaller ruim 81 miljoen inlogpogingen af op Microsoft 365-accounts wereldwijd, zonder dat de meeste getroffen bedrijven het meteen doorhadden. Niet via phishingmails of een lek in Microsoft zelf, maar via een verouderde inlogmethode die Conditional Access-beleid en MFA gewoon aan zich voorbij liet gaan. Onderzoekers van beveiligingsbedrijf Huntress brachten de campagne aan het licht en noemden hem LSHIY, naar de infrastructuurprovider achter de aanval.
Het bijzondere aan deze aanval is niet de omvang, maar de methode. Veel MKB-bedrijven denken dat MFA een waterdichte maatregel is. Deze campagne laat zien dat een verkeerd geconfigureerd of onvolledig MFA-beleid net zo lek kan zijn als geen MFA. In dit artikel lees je wat er precies gebeurde, waarom dit relevant is voor iedere organisatie die met Microsoft 365 werkt, en welke stappen je nu concreet kunt zetten.
Wat gebeurde er?
Onderzoekers ontdekten dat een aanvaller, opererend vanaf een IPv6-adresreeks van de Hongkongse provider LSHIY LLC (AS32167), gedurende twee weken op grote schaal wachtwoorden uitprobeerde tegen Microsoft 365-accounts. De aanvaller gebruikte daarbij gebruikersnaam-wachtwoordcombinaties die eerder waren buitgemaakt bij andere datalekken, een techniek die bekendstaat als credential stuffing gecombineerd met password spraying.
Het slimme, en het zorgwekkende, zat in de manier waarop werd ingelogd. In plaats van het normale, interactieve inlogscherm te gebruiken, benaderde de aanvaller Microsoft-accounts via een verouderde OAuth-inlogmethode genaamd ROPC (Resource Owner Password Credentials), toegankelijk via de Azure CLI. Bij ROPC stuurt een applicatie de gebruikersnaam en het wachtwoord in één keer rechtstreeks naar het token-endpoint van Microsoft. Er verschijnt geen inlogscherm, en dus ook geen los MFA-verzoek.
Het resultaat: van de 81 miljoen pogingen werden er 78 accounts bij 64 organisaties daadwerkelijk gecompromitteerd. Op het hoogtepunt van de campagne, op 22 juni, werden op één dag 30 accounts bij 23 bedrijven succesvol overgenomen. Onderzoek naar deze specifieke bedrijven leverde een onthullend beeld op: vijftien van hen hadden wel degelijk MFA ingesteld. Bij acht organisaties ontbrak elk MFA-beleid volledig.
Waarom deze aanval anders werkt dan gewone phishing
De meeste MKB-bedrijven trainen medewerkers op het herkennen van phishingmails: een verdachte afzender, een vreemde link, een gevoel van urgentie. Die training is waardevol, maar raakt deze aanval helemaal niet. Er is geen mail, geen link, en geen moment waarop een medewerker een keuze maakt. De aanvaller praat namelijk niet met een mens, maar rechtstreeks met de Microsoft-infrastructuur via een programmeerbare interface die bedoeld is voor IT-beheerders en ontwikkelaars.
Dat is meteen de kern van het probleem. Beveiligingsbewustzijn en gebruikerstraining, hoe belangrijk ook, beschermen niet tegen een aanval die zich volledig buiten het zicht van de eindgebruiker afspeelt. De enige verdediging tegen dit type aanval zit in de technische configuratie van de omgeving zelf: welke inlogmethoden zijn toegestaan, en onder welke voorwaarden.
Nog een verschil met klassieke aanvallen: schaal. Waar een phishingcampagne doorgaans een beperkt aantal mensen bereikt en afhankelijk is van menselijke fouten, kan een geautomatiseerd script moeiteloos duizenden inlogpogingen per uur genereren. Bij deze campagne ging het om gemiddeld ruim 4 miljoen pogingen per dag, verspreid over talloze doelwitten tegelijk. Detectie op basis van “een paar mislukte inlogpogingen” schiet dan tekort: het patroon moet worden herkend op basis van het protocol en de herkomst, niet alleen het aantal pogingen per account.
Waarom is dit belangrijk?
Deze campagne raakt aan een aanname die bij veel MKB-bedrijven diep verankerd zit: “we hebben MFA ingeschakeld, dus we zitten goed.” Dat klopt niet meer zonder meer. Het probleem lag bij de vijftien bedrijven met MFA niet in de afwezigheid van de maatregel, maar in de dekking ervan. Onderzoek van Huntress en The Hacker News liet drie terugkerende hiaten zien:
- MFA-beleid was gekoppeld aan specifieke apps, maar Azure CLI viel daarbuiten.
- Beleid gold alleen voor beheeraccounts, niet voor reguliere gebruikers.
- Een uitzondering voor “vertrouwde locaties” liet verkeer door dat ten onrechte als vertrouwd werd herkend.
- Bij twee organisaties stond het beleid nog in report-only modus, wat betekent dat het wel wordt gelogd maar niet daadwerkelijk wordt afgedwongen.
Dit sluit direct aan bij een thema dat we eerder bespraken in onze uitleg over Zero Trust voor het MKB: het gaat niet om het aanvinken van een maatregel, maar om het consequent toepassen ervan op elk toegangspad, inclusief paden die IT-beheerders zelf gebruiken, zoals Azure CLI en scripting-tools. Precies die technische paden worden vaak vergeten bij het inrichten van beveiligingsbeleid, omdat ze niet zichtbaar zijn voor een gewone gebruiker.
Wat zijn de risico’s?
Een gecompromitteerd Microsoft 365-account is zelden het eindpunt van een aanval, het is meestal het startpunt. Zodra een aanvaller toegang heeft tot een mailbox, kan die:
- Interne phishing opzetten. Mails vanaf een echt, vertrouwd account overtuigen collega’s veel sneller dan een externe phishingmail.
- Mailregels instellen die inkomende facturen of betalingsverzoeken automatisch doorsturen of verbergen, een klassieke tactiek bij CEO-fraude en factuurfraude.
- Vertrouwelijke data doorzoeken in SharePoint en OneDrive waar het account toegang toe heeft, inclusief klantgegevens die onder de AVG vallen.
- Zich lateraal verplaatsen naar andere systemen als hetzelfde account, zoals vaak gebeurt, ook toegang heeft tot een CRM, boekhoudpakket of andere gekoppelde applicatie.
Voor bedrijven die onder de Cyberbeveiligingswet of NIS2 vallen, komt daar een extra risico bovenop: een ongeautoriseerde toegang tot bedrijfsgegevens kan onder de meldplicht vallen. Wie niet kan aantonen dat passende technische maatregelen zijn genomen, zoals correct geconfigureerde MFA, riskeert niet alleen datadiefstal maar ook een compliance-probleem.
Wat moet een MKB-bedrijf nu doen?
De goede boodschap: de maatregelen tegen deze specifieke aanvalstechniek zijn relatief eenvoudig door te voeren binnen een bestaande Microsoft 365-omgeving. Vijf concrete acties:
- Blokkeer legacy authentication volledig. Richt een Conditional Access-beleid in dat alle verouderde authenticatieprotocollen, waaronder ROPC, blokkeert voor alle gebruikers en alle cloud-apps. Dit is de meest directe tegenmaatregel tegen deze specifieke campagne.
- Controleer of MFA écht overal geldt. Ga na of MFA-beleid is gekoppeld aan alle apps, alle gebruikers, en niet alleen aan beheerders. Zet policies die nog in report-only modus staan actief op “afdwingen”.
- Herzie uitzonderingen voor vertrouwde locaties. Een IP-reeks die ooit als vertrouwd is gemarkeerd, blijft dat niet automatisch. Controleer periodiek of deze uitzonderingen nog kloppen.
- Beperk wie Azure CLI en vergelijkbare tools mag gebruiken. Niet elke gebruiker heeft dit nodig. Beperk toegang tot beheerders die er daadwerkelijk mee werken, en behandel die accounts met extra streng beleid.
- Controleer je aanmeldingslogs met terugwerkende kracht. Zoek in Entra ID naar aanmeldingen met client-app-type “Azure CLI” of “andere clients” vanuit onbekende IP-reeksen, zeker in de periode rond half juni 2026.
Deze stappen sluiten direct aan bij het stappenplan uit ons artikel over Zero Trust binnen Microsoft 365: verifieer expliciet, geef alleen toegang die nodig is, en ga ervan uit dat een aanvaller ooit een manier vindt om binnen te komen. Wie deze aanpak al had ingericht via Microsoft Cloud-diensten, loopt hier aanzienlijk minder risico.
Wat als je organisatie al is geraakt?
Mocht blijken dat een account in de betreffende periode is gecompromitteerd, dan is het niet voldoende om alleen het wachtwoord te wijzigen. Een aanvaller die eenmaal toegang had, kan sporen hebben achtergelaten die verder reiken dan het account zelf. Loop in dat geval in elk geval de volgende punten na:
- Controleer mailboxregels. Zoek naar automatische doorstuurregels of regels die mails ongezien naar een map verplaatsen, een veelgebruikte tactiek om sporen te wissen na factuurfraude.
- Herzie actieve sessies en tokens. Een gewijzigd wachtwoord stopt een aanvaller niet als die al een geldig sessietoken heeft. Trek alle actieve sessies in en forceer opnieuw inloggen.
- Controleer gekoppelde apps en API-toegang. Ga na of er nieuwe app-registraties of OAuth-toestemmingen zijn toegevoegd die de gebruiker zelf niet herkent.
- Informeer je meldplicht-verantwoordelijke. Bij twijfel of persoonsgegevens zijn geraakt, weegt dit mee in de meldplicht onder de AVG en, voor essentiële en belangrijke entiteiten, de Cyberbeveiligingswet.
Deze nazorg is minstens zo belangrijk als de preventieve maatregelen, en wordt in de praktijk vaak overgeslagen zodra het wachtwoord eenmaal is gereset. Dat gevoel van “opgelost” is precies waar een volhardende aanvaller op rekent.
Hoe kan MonkeySoft hierbij helpen?
MonkeySoft helpt MKB-bedrijven met het doorlichten en aanscherpen van Conditional Access-beleid binnen Microsoft 365 en Azure. We brengen in kaart welke inlogpaden binnen jouw organisatie nog open staan, inclusief technische toegangspaden zoals Azure CLI, PowerShell en API-koppelingen die vaak buiten het zicht van reguliere beveiligingscontroles blijven.
Daarnaast controleren we historische aanmeldingslogs op sporen van deze en vergelijkbare campagnes, en zorgen we dat MFA-beleid daadwerkelijk overal wordt afgedwongen in plaats van alleen op papier te bestaan. Voor bedrijven die hun koppelingen met andere systemen willen laten meewegen in dit beleid, kijken we ook naar de toegangsrechten van gekoppelde applicaties, want een kwetsbare integratie ondermijnt anders alsnog de rest van je beveiliging.
Neem contact op met MonkeySoft voor een vrijblijvende Conditional Access-check van jouw Microsoft 365-omgeving.
Veelgestelde vragen
Wat is ROPC en waarom is het gevaarlijk?
ROPC (Resource Owner Password Credentials) is een verouderde OAuth-inlogmethode waarbij een gebruikersnaam en wachtwoord rechtstreeks naar het token-endpoint van Microsoft worden gestuurd, zonder interactief inlogscherm. Omdat er geen inlogscherm verschijnt, wordt er ook geen MFA-verzoek getoond, waardoor Conditional Access-beleid dat op interactieve aanmeldingen is gericht deze pogingen niet altijd tegenhoudt.
Betekent MFA hebben dat je veilig bent tegen deze aanval?
Niet automatisch. Uit onderzoek van Huntress bleek dat een deel van de getroffen bedrijven wel MFA had ingesteld, maar dan alleen voor specifieke apps, alleen voor beheerders, of met een uitzondering voor vertrouwde locaties. ROPC-verkeer via Azure CLI viel daardoor buiten het beleid.
Hoe weet ik of mijn organisatie is geraakt?
Controleer de Entra ID-aanmeldingslogs op inlogpogingen met client-app-type “Azure CLI” of “legacy authentication” vanaf onbekende IP-adressen, met name uit het adresbereik van AS32167. Herhaalde mislukte pogingen gevolgd door een geslaagde aanmelding vanaf een ongebruikelijke locatie zijn een duidelijk signaal.
Hoe blokkeer je ROPC in Microsoft 365?
Via Conditional Access kun je legacy authentication, waaronder ROPC, volledig blokkeren voor alle gebruikers en alle cloud-apps. Daarnaast kan de instelling die verplicht sterke authenticatie afdwingt per gebruiker worden ingeschakeld, en kan toegang tot Azure CLI worden beperkt tot beheerders die het daadwerkelijk nodig hebben.
Is dit ook relevant voor kleinere MKB-bedrijven?
Ja. De campagne trof organisaties van allerlei omvang, en acht van de getroffen bedrijven hadden helemaal geen MFA-beleid. Kleinere bedrijven zijn vaak juist een makkelijker doelwit omdat IT-beheer minder tijd heeft om Conditional Access-beleid volledig dicht te timmeren.
Bronnen: Huntress, LSHIY Password Spray Attack | The Hacker News