Microsoft 365-phishing ondanks MFA: sessies overnemen

Microsoft 365-phishing draait om meer dan slechte e-mails en vervalste aanmeldpagina’s. Aanvallen beginnen in een gecompromitteerd bedrijfsaccount, leiden naar overtuigende of legitieme Microsoft-pagina’s en eindigen ondanks MFA in de mailbox, SharePoint of Teams.

Het halfjaarbericht 2026/1 van het Zwitserse federale cyberveiligheidsbureau is relevant voor Zwitserse bedrijven. In de eerste helft van 2026 nam het aantal meldingen over gecompromitteerde Microsoft 365-accounts toe. Deze accounts werden gebruikt voor phishing en fraude. Aanvallers deden zich voor als IT-helpdesk of leidinggevende en omzeilden controles met sessietokens, Device Code Phishing of reverse proxies.

MFA blijft onmisbaar. Niet elke methode is phishing-resistant. Een bevestigde sessie kan zelf het doelwit van een aanval worden. Microsoft 365 moet daarom als identiteitsplatform worden beveiligd en niet alleen als e-maildienst.

Hoe Microsoft 365-phishing ondanks MFA werkt

Nadat het wachtwoord, de tweede factor, de apparaatstatus en andere voorwaarden zijn gecontroleerd, verstrekt Entra ID tokens of sessiecookies. Net als bij een bezoekerspas telt daarna vooral de geldigheid. Als deze bij iemand anders terechtkomen, hoeft die persoon de controle mogelijk niet opnieuw te doorlopen.

De verschillende tokenvarianten in Microsoft Entra ID hebben elk een eigen functie en geldigheidsduur. Doorslaggevend is: een gestolen token of een token dat voor de aanvaller is vrijgegeven, kan een geauthenticeerde sessie vertegenwoordigen.

Adversary-in-the-Middle-phishing met reverse proxy

Bij Adversary-in-the-Middle (AiTM) bevindt de phishinginfrastructuur zich tussen de browser en Microsoft en stuurt zij de echte aanmelding in realtime door:

1. Een e-mail verwijst bijvoorbeeld naar een SharePoint-document, voicemail, factuur of handtekening.
2. De link leidt via de reverse proxy van de aanvaller naar de Microsoft-aanmelding.
3. Gebruikersnaam, wachtwoord en MFA-reactie worden doorgestuurd naar Microsoft.
4. Microsoft accepteert de bevestigde aanmelding en maakt de sessie aan.
5. De proxy onderschept de sessiecookie of tokens. De toegang eindigt pas na verloop, intrekking of blokkering.

De MFA is niet gekraakt. De gebruiker heeft een onderschepte sessie bevestigd. TOTP-codes en pushbevestigingen voorkomen deze relay niet principieel. FIDO2-sleutels, Windows Hello for Business en correct toegepaste passkeys binden de aanmelding daarentegen cryptografisch aan de legitieme dienst. Ook deze methoden bieden geen bescherming tegen malware op een aangemeld apparaat of tegen elke vorm van sessiediefstal.

Device Code Phishing via een echte Microsoft-pagina

De Device Code Flow is bedoeld voor apparaten waarop invoer lastig is. Een vergaderruimteapparaat of opdrachtregelprogramma toont een code die via Microsoft op een tweede apparaat wordt bevestigd.

Aanvallers starten dit proces zelf en versturen de code onder een voorwendsel. Nadat de code op de echte Microsoft-pagina is ingevoerd, komen de tokens in hun sessie terecht. Het domein en certificaat kloppen, maar er wordt een vreemde aanmelding geautoriseerd. Microsoft classificeert deze flow als risicovol en adviseert deze zonder gedocumenteerde noodzaak te blokkeren.

E-mailbombardement, nep-IT-support en ketenphishing

Een aanvalsketen kan beginnen met honderden nieuwsbrieven, registratieberichten en meldingen. Deze veroorzaken stress en verbergen echte waarschuwingen. Vervolgens vraagt een vermeende IT-supportmedewerker via Teams of telefoon om Quick Assist of een remote-supporttool te gebruiken. Daarmee kunnen opdrachten worden uitgevoerd, malware worden geïnstalleerd, browsergegevens worden uitgelezen en inloggegevens worden gestolen. De werkplek wordt overgenomen, niet de login.

Na de overname gebruikt de aanvaller echte correspondentie, bekende leveranciers en bestaande gesprekken voor gemanipuleerde facturen, nieuwe phishing en verdere accountovernames. SPF, DKIM en DMARC zijn niet voldoende wanneer het bericht uit de legitieme Microsoft 365-tenant komt.

Wat MFA doet en waar de grens ligt

MFA voorkomt veel accountovernames omdat een wachtwoord alleen niet langer volstaat. De methoden verschillen echter:

• Wachtwoord plus sms, telefoon of eenvoudige pushbevestiging: beter dan alleen een wachtwoord, maar kwetsbaar voor social engineering, SIM-swapping, MFA-fatigue en realtime phishing.
• TOTP of Authenticator met Number Matching: robuuster tegen onbedoelde bevestigingen, maar een code kan op een AiTM-pagina direct worden doorgestuurd.
• Phishing-resistant authenticatie: FIDO2, Windows Hello for Business, certificaatgebaseerde authenticatie en passkeys controleren de legitieme dienst cryptografisch en beperken AiTM-aanmeldingen aanzienlijk.

Risico’s blijven bestaan. Een geïnfecteerd endpoint kan sessies uitlezen, een OAuth-app kan permanente rechten krijgen en een gebruiker kan vreemde device codes of externe toegang bevestigen. Phishing-resistant MFA is een centraal onderdeel, maar geen volledig beveiligingsconcept.

Microsoft Entra ID doelgericht beveiligen

Conditional Access en Token Protection vereisen passende Entra-licenties, terwijl apparaatvoorwaarden een beheerde apparaatbasis nodig hebben. Beleidsregels moeten eerst in Report-only met een pilotgroep worden getest.

Phishing-resistant aanmelding prioriteren

De eerste uitrol moet beheerders, financiële medewerkers, directieleden en helpdeskmedewerkers omvatten. Met Conditional Access Authentication Strengths kunnen daar Windows Hello for Business, FIDO2-sleutels, passkeys of certificaatgebaseerde authenticatie verplicht worden gesteld.

Daarbij hoort een herstelproces met minstens twee geregistreerde methoden, gecontroleerde reserveapparaten en afzonderlijk bewaakte noodaccounts. Een verloren sleutel mag niet tot langdurige uitval of gemakkelijk manipuleerbare helpdeskuitzonderingen leiden. Passkeys zijn ook geschikt voor de aanmelding bij Sophos Central, waarbij herstel en apparaatwissels eveneens moeten worden gepland.

Device Code Flow controleren en waar mogelijk blokkeren

Het gebruik kan in de Entra Sign-in Logs via Authentication protocol > Device code worden geïnventariseerd. Vergaderruimteapparaten, oudere tools of opdrachtregelapplicaties kunnen hiervan afhankelijk zijn. Zonder onderbouwde noodzaak wordt onder Entra ID > Conditional Access > Policies een beleidsregel gemaakt:

1. Reguliere gebruikers of groepen selecteren.
2. Noodaccounts en gemotiveerde technische uitzonderingen uitsluiten.
3. Onder Target resources bij voorkeur All resources kiezen en beperktere doelen alleen met een duidelijke reden gebruiken.
4. Onder Conditions > Authentication flows de Device code flow activeren.
5. Onder Grant de toegang blokkeren.
6. Eerst Report-only gebruiken, logs controleren en de beleidsregel pas daarna activeren.

Uitzonderingen moeten strikt beperkt, gedocumenteerd en aan specifieke accounts of resources gekoppeld zijn.

Toegang aan beheerde apparaten koppelen

Conditional Access kan voor gevoelige applicaties een compliant of Microsoft Entra-joined apparaat vereisen. Dit bemoeilijkt tokenmisbruik op onbekende apparaten, maar heeft gevolgen voor BYOD, gasten, mobiele apparaten en speciale clients. Daarom moeten apparaatbestand, besturingssystemen en applicaties bekend zijn. Verouderde vermeldingen, zwakke enrollment of ruime uitzonderingen ondermijnen de controle.

Token Protection gericht testen

Token Protection bindt ondersteunde Sign-in Session Tokens cryptografisch aan het apparaat dat ze heeft uitgegeven en bemoeilijkt replay op andere systemen. De functie vereist Entra ID P1 en dekt alleen bepaalde platformen, applicaties en resources. Onder Windows beschermt zij vooral ondersteunde native Microsoft 365-applicaties. Apple-apparaten hebben beheer en de Microsoft Enterprise SSO Plug-in nodig. De Mail- en Agenda-apps van Apple ondersteunen Token Protection momenteel niet.

De introductie begint met een strikt beperkte scope in Report-only. Daarna worden Token Protection Status Details, clients en resources in de Sign-in Logs gecontroleerd. Handhaving volgt pas wanneer de compatibiliteit is bevestigd. Browsers, legacysoftware en speciale apparaten worden afzonderlijk beoordeeld.

Teams en remote support controleren

Er moet worden vastgelegd met welke externe domeinen of tenants gebruikers via Teams contact mogen opnemen en hoe externe deelnemers herkenbaar zijn. Voor support geldt:

• Remote support start alleen met een ticket of een geverifieerd terugbelverzoek via een bekend telefoonnummer.
• Onverwachte Quick Assist-sessies vanuit chats of telefoongesprekken worden niet geaccepteerd.
• Toegestane remote-supporttools zijn gedocumenteerd en worden bewaakt.
• Onbekende RMM-tools worden via Application Control, AppLocker, Windows Defender Application Control of vergelijkbare controles geblokkeerd of gemeld.
• Een ongewoon e-mailbombardement wordt aan IT of Security gemeld en niet alleen als spam behandeld.

Awareness moet deze processen weerspiegelen. Sophos Phish Threat wordt effectiever met duidelijke meldkanalen, Teams-scenario’s en een realistisch helpdesk-runbook.

Welke sporen beheerders moeten controleren

Een geslaagde MFA-gebeurtenis bewijst niet dat een aanmelding legitiem was. Bij AiTM of Device Code kan de factor door de gebruiker zelf zijn bevestigd. Identiteit, mailbox, endpoint en communicatie moeten gezamenlijk worden onderzocht.

Microsoft Entra Sign-in Logs

De logboeken staan onder Entra ID > Monitoring & health > Sign-in logs en zijn vanaf de rol Reports Reader leesbaar. Afhankelijk van de verdenking moeten interactieve en niet-interactieve aanmeldingen, Service Principals en Managed Identities in de analyse worden opgenomen. Relevant zijn:

• onbekende of niet-compliant apparaten en ongebruikelijke IP-adressen, regio’s, applicaties en clients,
• Device code als Authentication Protocol,
• nieuwe browser- of apparaatcombinaties na een normale aanmelding,
• ongebruikelijke toegang tot Exchange Online, SharePoint of Microsoft Graph,
• het Conditional Access-resultaat, de vervulde authenticatievereisten en
• geslaagde toegang zonder de verwachte gebruikersinteractie via bestaande tokens.

Eén signaal is niet voldoende. Een Zwitsers IP-adres kan bij mobiel internet of een VPN horen en een buitenlandse aanmelding kan zakelijk zijn. De combinatie van gebruiker, apparaat, tijd, applicatie en vervolgactiviteit is doorslaggevend.

Exchange Online, Audit en Endpoint

Na een overname zoeken aanvallers vaak naar facturen en bestaande gesprekken. Te controleren zijn interne en externe doorsturingen, zichtbare en verborgen Inbox Rules, delegaties en Send-as-rechten, ongebruikelijke zoek-, lees-, download- en verzendactiviteiten, nieuwe OAuth-consents en Enterprise Applications, gewijzigde authenticatiemethoden en alle verzonden berichten binnen het tijdvenster.

Bij nep-IT-support zijn sporen op het endpoint te vinden: remote-supportprogramma’s, downloads, PowerShell, MSHTA, geplande taken, browsertoegang en verdachte processen. E-mailbeveiliging, Endpoint Protection en XDR of MDR kunnen deze activiteiten blokkeren en correleren als de gegevensbronnen gelicentieerd, geïntegreerd en bewaakt zijn. De Sophos Fusion-strategie ondersteunt dit, maar vervangt Conditional Access of het incidentproces niet.

De bewaartermijn en gedetailleerdheid van auditgegevens hangen af van licentie en configuratie. Beide moeten vooraf zijn vastgesteld, omdat achteraf geactiveerde logging geen historie oplevert.

Noodplan voor een gecompromitteerd Microsoft 365-account

Alleen het wachtwoord wijzigen is niet voldoende. Sessies, vreemde MFA-methoden, OAuth-consents en mailboxregels kunnen blijven bestaan.

1. Een schoon beheerderapparaat gebruiken

Bij een mogelijke endpointcompromittering worden het wachtwoord en de beheeracties op een ander apparaat uitgevoerd. Het getroffen systeem wordt geïsoleerd zonder overhaast sporen te wissen. Bij een actieve aanval of een account met verhoogde rechten kan tijdelijke deactivering zinvol zijn.

2. Actieve sessies intrekken

Sessies kunnen in het Entra Admin Center of met Microsoft Graph PowerShell worden ingetrokken:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

De User Principal Name wordt aangepast. Afhankelijk van de applicatie, het tokentype en Continuous Access Evaluation kan toegang nog kort blijven bestaan. Daarom wordt het resultaat in de logs en applicaties gecontroleerd.

3. Wachtwoord en authenticatie opschonen

Het wachtwoord wordt in de primaire identiteitsbron gewijzigd, bij gesynchroniseerde of gefedereerde accounts in het lokale Active Directory of bij de Identity Provider. Daarna worden MFA-methoden, passkeys, telefoonnummers, apparaten en Temporary Access Passes gecontroleerd en vreemde vermeldingen verwijderd. Bij malware of externe toegang wordt het endpoint parallel onderzocht en indien nodig opnieuw opgebouwd.

4. OAuth-consents en rollen controleren

User consents, Enterprise Applications en verdachte Service Principals kunnen permanente toegang mogelijk maken. Bij accounts met verhoogde rechten worden ook de rollen in Entra, Azure en Microsoft 365 gecontroleerd.

5. Doorsturingen en Inbox Rules controleren

Exchange Online PowerShell toont de belangrijkste mailboxinstellingen:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Verdachte regels worden gedocumenteerd en verwijderd. Delegaties, Send-as-rechten en administratieve transportregels worden afzonderlijk gecontroleerd.

6. Vervolgslachtoffers identificeren en informeren

Message Trace en auditgegevens tonen verzonden berichten. Interne en externe ontvangers worden geïnformeerd voordat links, betalingen of andere accounts worden getroffen. Bij gewijzigde betalingsgegevens wordt via bekende kanalen contact opgenomen met de bank, boekhouding en zakenpartners. Meer stappen staan in het artikel over directe maatregelen bij phishing en hacking.

7. Oorzaak en omvang bepalen

Tot slot wordt vastgesteld of AiTM, Device Code, bevestigde MFA of remote support betrokken waren, welke SharePoint- of OneDrive-bestanden zijn buitgemaakt, of andere accounts, applicaties of apparaten zijn geregistreerd en of persoonsgegevens of bedrijfsgeheimen zijn getroffen. Zonder oorzaakanalyse blijft het beveiligingslek bestaan.

Praktische checklist voor Microsoft 365-beheerders

• Phishing-resistant aanmelding prioriteren voor beheerders, financiële functies, directie en helpdesk.
• Noodaccounts gescheiden houden, bewaken en regelmatig testen.
• Het gebruik van Device Code inventariseren, blokkeren of onderbouwd uitzonderen.
• Conditional Access in Report-only met een pilotgroep testen.
• Voor gevoelige resources beheerde apparaten vereisen en Token Protection alleen met compatibele clients uitrollen.
• Externe Teams-communicatie, remote-supporttools, helpdeskterugbelprocedures en identiteitscontroles bindend vastleggen.
• Alarmen instellen voor e-mailbombardementen, ongebruikelijke aanmeldingen, OAuth-consents en doorsturingen.
• Het intrekken van sessies, het opschonen van MFA, Inbox Rules, verzendsporen en endpointisolatie testen.
• Bewaartermijnen voor auditgegevens en verantwoordelijkheden vóór een incident vastleggen.

Mijn aanbeveling

MFA blijft verplicht, maar een wachtwoord plus push-app houdt onvoldoende rekening met moderne aanvallen. Eerst moeten accounts met verhoogde rechten en financieel kritieke accounts phishing-resistant worden. Daarna volgen controle op Device Code, beheerde apparaten en Conditional Access. Vanwege de beperkingen vraagt Token Protection om een gecontroleerde uitrol. Tegelijkertijd heeft de helpdesk veilige procedures voor onverwachte Teams-contacten nodig.

Doorslaggevend is de combinatie van een sterke identiteit, een vertrouwd apparaat, een gecontroleerde sessie, bewaakte communicatie en een noodplan voor actieve tokens en verborgen persistentie.

FAQ