Adversary-in-the-Middle-aanvallen stelen geen wachtwoorden meer — ze stelen sessietokens en omzeilen zo MFA volledig. Token Protection in Entra Conditional Access bindt tokens cryptografisch aan het apparaat van de gebruiker, waardoor een gestolen token op een ander apparaat niets meer waard is.
Meerfactorauthenticatie (MFA) geldt al jaren als de minimumstandaard voor veilig inloggen, en terecht. Maar aanvallers hebben dit geweten en hun tactiek aangepast. De aanvalsmethode die nu domineert heet AiTM: Adversary-in-the-Middle. Daarbij is het doel niet langer het wachtwoord — het doel is het sessietoken dat ontstaat nadat u al succesvol hebt ingelogd, inclusief MFA.
Met een gestolen token kan een aanvaller volledig inloggen als de gebruiker, zonder ooit een wachtwoord of verificatiecode te kennen. Standaard MFA biedt daar geen bescherming tegen. Token Protection in Microsoft Entra Conditional Access sluit precies dit gat — en het activeren ervan kost één beleidsregel.
Bij een klassieke phishing-aanval probeert de aanvaller het wachtwoord van de gebruiker te bemachtigen. Bij AiTM werkt het anders. De gebruiker wordt naar een nepwebsite gestuurd die als transparante proxy optreedt voor de echte Microsoft-inlogpagina. De gebruiker ziet een legitiem uitziend inlogscherm, doorloopt het volledige aanmeldproces inclusief de MFA-stap, en denkt nergens aan.
Ondertussen geeft de aanvaller de inloggegevens én de MFA-reactie in real time door aan de echte Microsoft-dienst. Microsoft ziet een geldige aanmelding, genereert een sessietoken, en stuurt dat terug — via de proxy ook direct naar de aanvaller. Met dat token logt de aanvaller in op Exchange Online, SharePoint of Teams zonder dat de gebruiker er ooit iets van merkt. MFA is volledig omzeild, want de aanvaller heeft geen wachtwoord of code nodig: alleen het token.
AiTM-kits zijn inmiddels kant-en-klaar beschikbaar en worden actief ingezet in phishingcampagnes gericht op Microsoft 365-omgevingen. Ze zijn niet meer voorbehouden aan geavanceerde statelijke actoren — ook middelmatige aanvallers gebruiken ze als standaardinstrument.
Token Protection is een sessiebeheersingsfunctie in Entra Conditional Access die OAuth-tokens cryptografisch bindt aan het apparaat waarop ze zijn aangemaakt. Concreet: wanneer een gebruiker inlogt op een Entra-gekoppeld Windows-apparaat, wordt het Primary Refresh Token (PRT) dat daarna wordt aangemaakt, vastgeklonken aan de TPM-chip van dat apparaat.
Als een aanvaller dat token steelt en probeert te gebruiken op een ander apparaat, weigert Entra ID de toegang. Het token is cryptografisch gebonden aan de originele hardware — een apparaat dat die binding niet kan bewijzen, krijgt simpelweg geen toegang. De aanval slaagt technisch gezien nog wel, maar levert de aanvaller niets bruikbaars op.
Token Protection is daarmee aanvullend op phishingbestendige MFA zoals passkeys of FIDO2. Passkeys voorkomen dat de aanvaller überhaupt een geldig token bemachtigt via de phishing-proxy. Token Protection maakt een al gestolen token onbruikbaar buiten het originele apparaat. Samen dekken ze AiTM-aanvallen van twee kanten af.
De licentievereiste is minimaal: Microsoft Entra ID P1, dat inbegrepen zit in Microsoft 365 Business Premium, E3 en E5. Organisaties op Microsoft 365 Business Basic of Business Standard hebben Entra ID P1 niet standaard — een upgrade of een aparte Entra ID P1-licentie is dan nodig.
Apparaten moeten Windows zijn en gekoppeld aan Entra ID. Dat kan op twee manieren: volledig Entra-joined (cloudgekoppeld, zonder Active Directory) of Hybrid Entra-joined (gecombineerd met een on-premises Active Directory). Entra-geregistreerde apparaten, zoals persoonlijke apparaten die alleen een werkaccount hebben, vallen buiten de ondersteuning voor Token Protection.
De apparaten moeten bovendien beschikken over een TPM 2.0-chip, de standaard voor vrijwel elk zakelijk apparaat dat de afgelopen vier jaar is aangeschaft. Oudere hardware zonder TPM kan niet deelnemen aan Token Protection en moet als uitzondering worden behandeld in het beleid.
Token Protection werkt voor de kernservices van Microsoft 365: Exchange Online, SharePoint Online en Microsoft Teams. Dit zijn de primaire aanvalsdoelen bij AiTM-campagnes gericht op zakelijke omgevingen, waardoor de dekking in de praktijk groot is.
De bescherming is in eerste instantie het sterkst voor native desktop-applicaties en mobiele clients van Microsoft, zoals de Teams-desktopapp, Outlook-desktop en OneDrive-client. Ondersteuning voor browsergebaseerde toegang tot deze diensten is uitgebreid en groeit, maar is afhankelijk van de browser en de gebruikte apparaatconfiguratie. Controleer bij uitrol welke combinaties in uw omgeving daadwerkelijk worden gedekt.
Het activeren van Token Protection verloopt via een nieuw of bestaand Conditional Access-beleid in het Microsoft Entra-portaal. De instelling bevindt zich onder de sectie Sessiebeheer, die u in elke CA-policy aantreft naast de bekendere opties als Sign-in frequency en Persistent browser session.
Het aanbevolen uitrolproces bestaat uit drie fasen. In de eerste fase maakt u een Conditional Access-policy aan in rapportagestand, ook wel Report-only mode. U selecteert als doelgroep een pilotgroep van gebruikers op compatibele apparaten, stelt de betrokken applicaties in op Exchange Online, SharePoint Online en Teams, en schakelt Token Protection in onder Sessiecontroles. In rapportagestand is er geen impact voor eindgebruikers — u ziet alleen in de aanmeldlogboeken hoeveel aanmeldingen met het beleid in lijn zijn.
In de tweede fase analyseert u de rapportagegegevens in het Entra-portaal. Aanmeldingen van apparaten die niet aan de vereisten voldoen, apparaten zonder TPM, niet-Entra-joined of BYOD-apparaten, verschijnen als 'not compliant'. Zorg dat u voor deze uitzonderingen een aparte flow inricht, zodat die gebruikers niet worden buitengesloten bij activering.
In de derde fase schakelt u het beleid over naar Enabled voor de pilotgroep, evalueert gedurende één tot twee weken op problemen, en breidt vervolgens uit naar de volledige organisatie. Een typische uitrol van twee tot drie weken is haalbaar voor de meeste organisaties.
Token Protection is een krachtige maatregel, maar geen volledige oplossing op zichzelf. Er zijn drie belangrijke begrenzingen. Ten eerste beschermt het niet tegen aanvallen waarbij de aanvaller directe code-uitvoering op het originele apparaat heeft verkregen. Als malware op het apparaat van de gebruiker draait, kan de aanvaller vanuit dat apparaat handelen met de gebonden token — de cryptografische binding helpt dan niet.
Ten tweede dekt Token Protection niet alle toegangspaden. Legacy-authenticatieprotocollen, applicaties die geen moderne OAuth-flows gebruiken, en sommige browserscenario's vallen buiten de huidige reikwijdte. Een volledig beeld van welke aanmeldpaden in uw omgeving worden gedekt, krijgt u alleen via de rapportagestand.
Ten derde is Token Protection geen vervanging voor phishingbestendige MFA. De juiste volgorde is: eerst phishingbestendige MFA activeren (passkeys, WHfB of FIDO2-sleutels), dan Token Protection toevoegen als aanvullende laag voor de scenario's waarbij token-diefstal ondanks sterke authenticatie nog mogelijk is.
Organisaties die hun identiteitsbeveiliging serieus nemen, bouwen aan een gelaagde aanpak. Conditional Access-beleid vormt het fundament: u bepaalt wie toegang krijgt, waartoe, onder welke omstandigheden. Token Protection is één van de sessiecontroles die u in dat fundament kunt opnemen, naast Sign-in frequency, compliant device-eis en continuous access evaluation.
De combinatie die momenteel het meest robuust is tegen AiTM-aanvallen bestaat uit drie lagen: phishingbestendige MFA als aanmeldmethode, Token Protection als sessiecontrole, en Continuous Access Evaluation waarmee Entra ID sessies in real time kan beëindigen als een apparaat of gebruiker niet meer voldoet aan het beleid. Elke laag dicht een specifiek aanvalspad.
Wilt u weten of uw Conditional Access-configuratie afdoende beschermt tegen AiTM-aanvallen, of hulp bij het activeren van Token Protection in uw Entra ID-omgeving? Neem contact op met Zarioh voor een concrete beoordeling van uw identiteitsbeveiliging.
Was dit artikel nuttig?
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
Ontvang nieuwe artikelen direct in je inbox.
Geen spam. Afmelden kan altijd.
Security
Security
Security
