Waarom MFA alleen niet genoeg is voor Microsoft 365

Multi-factor authenticatie (MFA) is een van de belangrijkste beveiligingsmaatregelen voor Microsoft 365. Microsoft zelf noemt het de maatregel die 99,9% van de aanvallen op accounts voorkomt. En dat klopt. MFA is essentieel.

Maar MFA is geen garantie dat een account veilig is. In 2026 zien we steeds vaker aanvallen waarbij MFA netjes wordt doorlopen en de aanvaller toch toegang krijgt. Niet door MFA te kraken, maar door het te omzeilen. Als je organisatie vertrouwt op MFA als enige beschermingslaag voor Microsoft 365, is dat een probleem.

Hoe omzeilen aanvallers MFA?

Er zijn drie technieken die in 2026 actief worden ingezet tegen Microsoft 365 omgevingen. Ze hebben een ding gemeen: de gebruiker merkt niets of werkt onbewust mee aan de aanval.

Adversary-in-the-Middle (AiTM)

De aanvaller zet een website op die eruitziet als de Microsoft inlogpagina. Het slachtoffer logt in met wachtwoord en MFA op wat lijkt op een echte pagina. Maar de aanvaller zit ertussen en vangt het session cookie op dat Microsoft teruggeeft na succesvolle authenticatie.

Met dat cookie heeft de aanvaller volledige toegang tot het account. Zonder het wachtwoord te kennen. Zonder de MFA-code te hebben. De aanvaller kopieert simpelweg de sessie die de gebruiker zelf heeft geopend.

Dit is geen theorie. In maart 2026 werd Tycoon 2FA neergehaald, een platform dat deze techniek als dienst aanbood. Voordat het werd gestopt, had het aanvallers toegang gegeven tot bijna 100.000 organisaties, waaronder scholen, ziekenhuizen en overheidsinstellingen. Het platform is weg, maar de techniek is vrij beschikbaar en opvolgers zullen snel verschijnen.

Device Code Phishing

Bij deze techniek stuurt de aanvaller het slachtoffer een code die hij moet invullen op microsoft.com/devicelogin. Dit is een echte Microsoft pagina. De gebruiker logt in met wachtwoord en MFA, en alles lijkt normaal. Maar het token dat Microsoft aanmaakt, gaat naar de aanvaller.

Het verschil met AiTM: er is geen nep-website nodig. De gebruiker logt in op een legitieme Microsoft pagina. Daardoor is deze aanval vrijwel onmogelijk te herkennen voor de gebruiker. Gratis toolkits zoals Graphish maken het voor aanvallers eenvoudig om deze techniek op schaal in te zetten.

OAuth Consent Phishing

De aanvaller maakt een kwaadaardige applicatie aan en stuurt het slachtoffer een link om deze app te autoriseren. Het slachtoffer ziet een vertrouwd ogende Microsoft consent-scherm dat vraagt om toegang tot e-mail, bestanden of agenda. Een klik op “Accepteren” en de app heeft toegang, zonder dat er een wachtwoord of MFA-code wordt gestolen.

Het verraderlijke: de aanvaller heeft geen credentials nodig. De app krijgt een eigen toegangstoken dat actief blijft totdat de toestemming wordt ingetrokken. Dit kan weken of maanden duren zonder dat iemand het merkt. Ondertussen leest de app mee in de mailbox, downloadt bestanden uit OneDrive of stuurt e-mails namens het slachtoffer. MFA speelt geen enkele rol, want de gebruiker heeft de app zelf geautoriseerd.

Wat deze techniek extra gevaarlijk maakt voor MKB-organisaties: de kwaadaardige app blijft toegang houden, zelfs als de gebruiker daarna zijn wachtwoord wijzigt of MFA opnieuw instelt. Alleen het expliciet intrekken van de app-toestemming in Entra ID stopt de toegang.

Hoe herken je dat MFA omzeild is?

Het lastige aan deze technieken is dat ze geen alarm triggeren bij de gebruiker. De aanvaller breekt niets in. Hij loopt door de voordeur die de gebruiker voor hem heeft geopend. Toch zijn er signalen die erop wijzen dat een account gecompromitteerd is, ondanks actieve MFA.

Verdachte sign-in patronen. Een account dat binnen korte tijd inlogt vanuit Nederland en een uur later vanuit Nigeria is een duidelijk signaal. Maar het hoeft niet zo extreem te zijn. Inlogpogingen vanuit een datacenter IP-adres, een onbekend besturingssysteem of een ongebruikelijke browser zijn ook verdacht. Het probleem is dat de meeste organisaties deze logs niet structureel monitoren.

Onbekende app-registraties. Na een OAuth consent phishing aanval verschijnt er een nieuwe applicatie in de lijst met geautoriseerde apps. Deze apps hebben vaak generieke namen en brede permissies. Als je niet regelmatig controleert welke apps toegang hebben tot je tenant, kan zo’n app maandenlang ongemerkt meelezen.

Mailbox-regels die je niet hebt aangemaakt. Een veelgebruikte tactiek na een succesvolle aanval is het instellen van e-mail forwarding rules. De aanvaller stuurt kopieën van inkomende e-mails naar een extern adres, of verplaatst beveiligingsmeldingen automatisch naar de prullenbak. Dit stelt de aanvaller in staat om mee te lezen zonder dat de gebruiker iets merkt.

Sessies vanuit onverwachte locaties. In Entra ID kun je de actieve sessies van een gebruiker bekijken. Als je daar sessies ziet vanuit landen waar je organisatie niet opereert, of vanuit VPN-diensten en hosting providers, is dat een rode vlag. Zeker als de gebruiker zelf aangeeft die sessies niet te herkennen.

Wat kun je doen naast MFA?

MFA is de eerste laag. Maar je hebt meer lagen nodig. Elke maatregel hieronder dicht een specifiek gat dat MFA openlaat.

Conditional Access policies

Conditional Access is de belangrijkste aanvulling op MFA. Hiermee stel je regels in die bepalen onder welke omstandigheden een gebruiker mag inloggen. Je kunt sign-ins blokkeren vanuit onbekende locaties, onbeheerde apparaten of verdachte netwerken. Dit beperkt wat een aanvaller kan doen, zelfs als hij een geldig token heeft.

Een voorbeeld: als je een policy instelt die alleen inloggen toestaat vanaf beheerde apparaten, dan kan een aanvaller met een gestolen session cookie niets beginnen op zijn eigen laptop. Het token is geldig, maar het apparaat voldoet niet aan de voorwaarden. Voor MKB-organisaties die Entra ID P1 of P2 gebruiken, is dit een van de meest effectieve maatregelen die je kunt nemen.

Blokkeer device code flow

De meeste MKB-organisaties gebruiken geen apparaten die device code flow nodig hebben. Smart TV’s en vergaderschermen die via deze methode authenticeren zijn de uitzondering, niet de regel. Als je organisatie geen specifieke use case heeft voor device code flow, blokkeer het dan volledig via een Conditional Access policy.

Dit is een enkele instelling die een complete aanvalsvector elimineert. De policy is van toepassing op alle gebruikers, heeft als voorwaarde de authenticatie flow “Device code flow” en als actie “Block access”. Zet de policy op Enforce, niet op Report Only. Dit is een van de eenvoudigste en meest effectieve maatregelen die je kunt nemen. Lees meer over deze aanvalstechniek in onze blogpost over device code phishing.

Gebruik phishing-resistant MFA

Niet alle MFA-methoden zijn gelijk. Push-notificaties op je telefoon zijn beter dan niets, maar ze zijn kwetsbaar voor AiTM-aanvallen. De gebruiker keurt een notificatie goed, en het session cookie gaat naar de aanvaller.

FIDO2 security keys en passkeys werken fundamenteel anders. Bij FIDO2 is de authenticatie gebonden aan het specifieke apparaat en de specifieke website. Een nep-website triggert de key niet, en een doorgestuurd token is waardeloos. Microsoft is in 2026 begonnen met het automatisch inschakelen van passkey-profielen in Entra ID, wat de uitrol voor organisaties eenvoudiger maakt. Voor accounts met verhoogd risico, zoals Global Admins en financiële medewerkers, is phishing-resistant MFA geen luxe maar een noodzaak.

Beperk app-toestemmingen

Standaard kunnen gebruikers in Entra ID zelf toestemming geven aan applicaties die toegang vragen tot hun account. Dit is precies wat OAuth consent phishing misbruikt. De oplossing is eenvoudig: configureer in Entra ID dat alleen beheerders toestemming kunnen geven aan nieuwe apps.

Dit betekent dat wanneer een medewerker op een kwaadaardige consent-link klikt, de toestemming niet wordt verleend. In plaats daarvan wordt een verzoek ingediend bij een beheerder, die kan beoordelen of de app legitiem is. Deze instelling voorkomt niet alleen phishing, maar geeft je ook overzicht over welke apps toegang hebben tot je organisatiedata.

Monitor sign-in activiteit

De bovenstaande maatregelen verkleinen het aanvalsoppervlak. Maar geen enkele beveiliging is waterdicht. Daarom is monitoring essentieel. Inlogpogingen vanuit meerdere landen, onbekende IP-adressen, verouderde authenticatiemethoden en token replay zijn signalen die wijzen op een gecompromitteerd account.

Handmatig controleren kan, maar kost uren per account. De sign-in logs in Entra ID bevatten alle informatie, maar de hoeveelheid data maakt het onpraktisch om dit structureel bij te houden zonder tooling. Zeker voor organisaties met tientallen of honderden gebruikers is geautomatiseerde monitoring de enige haalbare aanpak.

Controleer je eigen Microsoft 365 omgeving

MFA is de eerste laag, maar hoe weet je of die laag voldoende is? En of een account niet al gecompromitteerd is via een van bovenstaande technieken? Handmatig de sign-in logs doorspitten voor elke gebruiker is niet realistisch. En de meeste organisaties komen er pas achter dat een account gecompromitteerd is wanneer de schade al is aangericht: phishing-mails verstuurd vanuit een directieaccount, vertrouwelijke bestanden gedownload, of facturen met gewijzigde bankrekeningnummers.

De Risky User Analyzer van Tenant Wizards controleert automatisch op verdachte sign-in patronen, verouderde authenticatiemethoden, device code flow en meer. Tien checks analyseren het risicoprofiel van een gebruiker en leveren binnen vijf minuten een rapport met een risicoscore en concrete aanbevelingen. Je ziet direct of een account verdachte activiteit vertoont, ook als MFA actief is.

Wil je direct je hele organisatie controleren? Met de Risky User Tenant Analyzer scan je alle gebruikers in je Microsoft 365 omgeving in één keer en zie je direct wie risico loopt.

Scan een individueel account | Scan je hele Microsoft 365 omgeving