Na het blokkeren van risicovolle authenticatiestromen zoals Device Code Flow lijkt de basis op orde. Gebruikers loggen interactief in, MFA is verplicht en Conditional Access staat strak ingericht. Toch zien we in de praktijk dat accounts nog steeds worden overgenomen, zonder dat wachtwoorden of MFA-codes ooit zijn gestolen.
Dat gebeurt via Adversary-in-the-Middle (AiTM) phishing.
Wat AiTM anders maakt dan klassieke phishing
Bij traditionele phishing probeert een aanvaller inloggegevens te verzamelen om die later te misbruiken. MFA doorbreekt dat model: zonder tweede factor komt een aanvaller niet verder. AiTM-phishing werkt fundamenteel anders. De aanvaller plaatst zich tussen de gebruiker en de echte inlogdienst. Technisch gezien gebeurt dit via een reverse proxy die al het verkeer real-time doorstuurt.
Voor de gebruiker:
- ziet de loginpagina er volledig legitiem uit;
- klopt de URL vaak grotendeels;
- werkt MFA zoals verwacht.
Voor de aanvaller:
- zijn gebruikersnaam, wachtwoord en MFA-interactie direct zichtbaar;
- wordt het sessietoken live onderschept;
- ontstaat direct toegang tot de cloudomgeving.
Er is geen hergebruik van credentials. De aanval speelt zich af terwijl de gebruiker zelf inlogt.
Waarom MFA hier faalt
MFA valideert of een gebruiker is wie hij zegt te zijn. AiTM misbruikt precies dat moment. De gebruiker is écht aanwezig en keurt de login goed, alleen gebeurt dat via een ongewenste tussenpartij. Voor Microsoft Entra ziet dit eruit als:
- een normale interactieve login;
- vanaf een geldig IP-adres;
- met succesvolle MFA.
Security-controls worden niet omzeild, maar correct uitgevoerd, alleen in de verkeerde context.
Wat een aanvaller krijgt na een succesvolle AiTM-aanval
Het belangrijkste doel van AiTM is niet het wachtwoord, maar het sessietoken. Dat token fungeert als een digitale sleutel en geeft toegang tot: e-mail en agenda, SharePoint en OneDrive, Teams-chats en bestanden en soms zelfs admin-interfaces, afhankelijk van het account. Zolang het token geldig is, hoeft de aanvaller zich niet opnieuw te authenticeren.
Waarom dit lastig te detecteren is
AiTM-aanvallen zijn moeilijk te herkennen omdat:
- er geen foutieve logins plaatsvinden;
- MFA correct wordt uitgevoerd;
- er geen verdachte authenticatiemethoden worden gebruikt.
Zonder aanvullende signalen lijkt het gedrag legitiem. Dit maakt duidelijk dat alleen vertrouwen op MFA en login-events onvoldoende is.
Wat dit betekent voor je security-aanpak
Deze aanvalstechniek laat zien dat:
- identiteit niet alleen beschermd moet worden bij het inloggen;
- sessies en tokens net zo belangrijk zijn als credentials;
- context (device, browser, binding) cruciaal wordt.
Zodra een aanvaller een geldig token heeft, verschuift het probleem van preventie naar beperking van impact.
Eerste technische maatregelen
AiTM volledig voorkomen is lastig, maar je kunt het risico aanzienlijk verkleinen:
- Forceer moderne authenticatie en blokkeer legacy protocollen
- Gebruik Conditional Access met duidelijke context-eisen
- Beperk toegang tot gevoelige applicaties tot bekende apparaten
- Dwing sterke authenticatiemethoden af waar mogelijk
Toch blijft er één fundamenteel probleem bestaan: tokens zijn vaak niet gebonden aan het apparaat waarop ze zijn uitgegeven. En precies daar zit de volgende verdedigingslaag. Lees hier de blog Wanneer tokens de nieuwe aanvalsvector worden: Token Protection in Conditional Access.
