Microsoft 365 token diefstal: waarom MFA alleen token spraying niet stopt

Eén experiment laat zien dat MFA gestolen sessies niet voorkomt: meer dan 200.000 mislukte inlogpogingen, 497 geslaagde aanmeldingen en e-mails over salarissen en bonussen die in verborgen regels verdwijnen. Het gaat om de vraag hoe je zulke Microsoft 365 token diefstal herkent, waarom de brede verspreiding van het platform de aanval lonend maakt en wat je in een noodgeval als eerste doet.

Waar token spraying om draait

Token spraying in Microsoft 365 is de naam voor een techniek die de beveiligingsleverancier Huntress in een campagne heeft waargenomen. De aanvallers raden geen wachtwoorden. Ze stelen sessietokens nadat een medewerker zich correct heeft aangemeld met wachtwoord en multifactorauthenticatie (MFA), en spelen die tokens kort daarna af vanaf hun eigen infrastructuur. De naam verwijst naar password spraying, waarbij één wachtwoord bij veel accounts wordt geprobeerd. Hier worden gestolen inloggegevens breed verspreid en hergebruikt.

De informatie over de campagne komt van Huntress en uit een bericht van The Hacker News. Ze berust op waarnemingen bij klanten van één beveiligingsleverancier en zegt niets over alle tenants.

Microsoft 365 token diefstal: wat Huntress heeft waargenomen

Huntress beschrijft de campagne in het rapport Token Replay and Spray. De exacte publicatiedatum van het rapport is niet zeker; gedocumenteerd is de waarnemingsperiode van 14 juli 2026 tot 22 september 2026. In die tijd zag Huntress aanvallen op 79 organisaties, meer dan 200.000 mislukte inlogpogingen en 497 geslaagde aanmeldingen. In Entra-directory's werden minstens 48 nepapparaten aangemaakt. Bij 19 organisaties werden bestaande MFA-methoden verwijderd en door een nieuwe vervangen.

Voor zover bekend wordt het aantal van 97 gecompromitteerde accounts alleen door The Hacker News vermeld. Het kon in het Huntress-rapport niet worden bevestigd en wordt hier daarom genoemd als cijfer uit dat bericht. Ook de cijfers voor de afzonderlijke aanvalsgolven verschillen binnen het Huntress-verslag licht. Voor de context volstaat de orde van grootte: met 79 getroffen organisaties, 497 geslaagde aanmeldingen en meerdere aanvalsgolven over ruim tien weken was dit geen op zichzelf staand geval, maar een reeks.

Hoe token spraying verschilt van password spraying

Password spraying levert veel mislukte pogingen op, omdat de meeste wachtwoorden verkeerd zijn. Bij token spraying zijn de inloggegevens geldig. Volgens Huntress kwamen de mislukte pogingen in de campagne uit de netwerken van de aanvallers, een groot deel daarvan van een hostingprovider in Duitsland. Dat zegt niets over andere klanten van die provider. Individuele adressen blokkeren helpt ook weinig, omdat de aanvallers hun adressen in golven wisselden, met één tot twee weken rust tussen de golven.

Hoe token replay MFA ondermijnt

De techniek heet ook token replay: een gestolen token wordt opnieuw afgespeeld. Het proces is in vier stappen te beschrijven.

1. Lokaas: Een medewerker ontvangt een phishingmail of wordt via social engineering naar een externe site gestuurd. Hoe zulke e-mails vertrouwen winnen, staat in het artikel over de echtheid van elektronische berichten.
2. Onderschepping: Een adversary-in-the-middle-relay (AiTM) zit tussen de medewerker en de echte Microsoft-aanmeldpagina. Wachtwoord en MFA-melding lopen via de relay, die vervolgens het token opslaat. Bij device code phishing wordt het slachtoffer er juist toe verleid op de echte Microsoft-pagina een code in te voeren, waarmee de aanvaller een token verkrijgt.
3. Replay: Enkele minuten tot ongeveer een uur later gebruikt de aanvaller het token vanaf zijn eigen servers. Er is geen wachtwoord en geen tweede MFA-melding nodig.
4. Persistentie: De aanvaller registreert een eigen authenticator-app, verwijdert bestaande MFA-methoden of maakt een nepapparaat aan. Beide overleven een wachtwoordwijziging.

Het cruciale punt: MFA is niet gekraakt. De medewerker heeft het correct doorlopen. Wat wordt gestolen is het resultaat, het token. MFA kan hier dus alleen worden omzeild als het token ook buiten het apparaat van de medewerker werkt. Codes, sms en pushgoedkeuringen helpen tegen het raden van wachtwoorden, maar niet tegen dit soort diefstal.

Huntress vond twee families van tools. De ene is een script dat zich met de user agent "node" identificeert en tokens opvraagt via de applicaties Office en Authentication Broker. De andere speelt browsersessies opnieuw af. Aanmeldingen van het tweede soort lijken op gewone browsertoegang en vallen dienovereenkomstig minder op.

Microsoft-monocultuur: waarom Microsoft 365 het lonendste doelwit is

Microsoft 365 wordt in ontelbare bedrijven in Duitsland en wereldwijd gebruikt. Vanuit het perspectief van de aanvallers is dat een economisch argument: een eenmaal gebouwde aanval kan tegen een zeer groot aantal tenants worden herhaald. De aanmeldpagina's zien er overal hetzelfde uit, de applicatie-ID's zijn gelijk en de foutcodes ook. Wat bij het ene bedrijf werkt, werkt met kleine aanpassingen bij vele andere.

De campagne laat deze schaalvergroting zien. Gestolen tokens werden automatisch en binnen enkele minuten gebruikt, verspreid over 79 organisaties. Volgens Huntress prioriteerden de aanvallers niet op het aantal mislukte pogingen, maar op de plekken waar geldige inloggegevens bestonden. Zo werkt een massabedrijf, geen gerichte operatie tegen één onderneming.

Verspreiding is de versterker, niet de enige oorzaak

Dit is geen algemene veroordeling. Microsoft levert de tegenmaatregelen zelf: Conditional Access, Security Defaults en Token Protection. Het risico ontstaat wanneer deze instrumenten niet of slechts gedeeltelijk worden gebruikt. Aanvallers stemmen hun automatisering af op de standaardinstellingen, omdat die voor de meeste tenants gelden. Elke afwijking, zoals een aan het apparaat gebonden aanmelding of een geblokkeerde device code flow, kost aanvallers moeite en neemt de basis voor massale uitbuiting weg.

De verspreiding van Copilot en andere diensten achter dezelfde accounts vergroot bovendien de hefboom van een gecompromitteerd account. Een kritische beoordeling biedt het artikel Copilot onder de loep. In Microsoft 365 opent één account tegelijk e-mail, bestanden, agenda en chat.

Salarisfraude als doel: wat er na de overname gebeurt

Na de overname maakten de aanvallers in de campagne verborgen inboxregels aan. Die verplaatsten of verwijderden e-mails met betalingsgerelateerde termen, zoals salaris, stortingen of bonus. De doelmappen hadden onopvallende namen zoals "RSS Feeds" of "Conversation History". In één geval werd een salarismail doorgestuurd naar een externe belastingadviseur. Antwoorden werden als gelezen gemarkeerd en weggeschoven, zodat het slachtoffer ze niet zou opmerken.

Hierachter zit business email compromise (BEC): het doel is overboekingen om te leiden of salarisrekeningen te laten wijzigen. In een ander geval werd een mailbox misbruikt om spam naar honderden externe ontvangers te sturen, totdat Entra ID Protection het account als hoog risico classificeerde.

Voor kleine bedrijven is dit bijzonder gevoelig. Vaak werken er maar enkele mensen in de boekhouding en bij HR. Een gewijzigd account valt laat op en de salarisadministratie wordt vaak door derden gedaan. De directie beslist dan over het terughalen van betalingen en het informeren van bank, belastingadviseur en salarisadministratie. Dat hoort in het noodplan, niet pas in de crisis.

Typische sporen: nieuwe authenticator-app, onbekende Entra-apparaten, inboxregels

De campagne laat sporen na in Microsoft Entra ID, het gebruikersbeheer achter Microsoft 365, die zonder speciale hulpmiddelen te controleren zijn. De volgende tabel vat de belangrijkste samen. De naamgevingspatronen komen uit het Huntress-rapport en kunnen veranderen.

Foutcode 53003 verdient aandacht. Een blokkade door Conditional Access wordt meestal als succes van het beleid gezien. Maar ze toont ook dat iemand buiten het bedrijf geldige inloggegevens of een geldig token bezit. Zo'n vermelding is een reden om het account te controleren. Inboxregels die via een API zijn aangemaakt, verschijnen niet altijd in de gebruikersinterface. Ze worden zichtbaar via het Exchange-beheercentrum of PowerShell.

Kleine bedrijven zonder logbewaking zien dingen vaak pas achteraf. Hoe lang aanmeldlogboeken bewaard blijven, hangt af van de licentie en moet vooraf worden uitgezocht, want zonder logs blijft de omvang van een incident onbekend.

Conditional Access: de device code flow blokkeren en MFA eisen voor alle clienttypen

De device code flow is een aanmeldmethode voor apparaten zonder toetsenbord of browser. Aanvallers misbruiken haar bij device code phishing door gebruikers een code op een ander apparaat te laten invoeren. In zijn documentatie over het blokkeren van authenticatiestromen adviseert Microsoft zo dicht mogelijk bij een volledige blokkade te komen en de flow alleen toe te staan in goed gedocumenteerde uitzonderingen, zoals oudere tools die niet kunnen worden bijgewerkt.

Het beleid wordt aangemaakt in het Entra-beheercentrum onder Entra ID, Conditional Access, Beleid. De voorwaarde is "Authenticatiestromen" met de keuze "Device code flow", en de toegangsbeheersing is "Toegang blokkeren". Microsoft adviseert het beleid eerst in de modus "Alleen rapporteren" te laten draaien en het pas daarna in te schakelen. Twee noodtoegangsaccounts worden uitgesloten en hun lijst moet regelmatig worden gecontroleerd.

Licentie: Conditional Access of Security Defaults

Volgens Microsoft Learn vereist Conditional Access minimaal Microsoft Entra ID P1 (voorwaarde volgens de documentatie over authenticatiesterktes). Bedrijven zonder deze licentie hebben de Security Defaults, die volgens Microsoft geen licentie vereisen. Tot de daar genoemde beschermingsmaatregelen behoren MFA-registratie voor alle gebruikers, het blokkeren van verouderde protocollen en het blokkeren van de device code flow. Microsoft vermeldt ook dat alle nieuwe Entra-tenants vanaf 1 juli 2026 de device code flow blokkeren als onderdeel van de Security Defaults. Volgens Microsoft kunnen de Security Defaults niet worden aangepast, alleen in- of uitgeschakeld. Wie uitzonderingen of fijnmaziger regels nodig heeft, heeft Conditional Access nodig.

MFA voor iedereen, zonder uitzonderingen voor apps of clients

Een basisbeleid moet MFA eisen voor alle gebruikers, alle resources en alle clienttypen, of de toegang blokkeren. Dit is precies de eis uit het Huntress-rapport, en hiaten ontstaan vaak door goedbedoelde uitzonderingen zoals "alleen beheerportalen" of "alleen browser". Verouderde protocollen zoals IMAP, POP3 en SMTP-authenticatie ondersteunen geen MFA en moeten worden geblokkeerd.

Phishingbestendige methoden zoals FIDO2-beveiligingssleutels of Windows Hello for Business beschermen veel beter tegen AiTM-onderschepping dan codes, sms of pushgoedkeuringen. Microsoft noemt een samenspel tussen de authenticatiemethode en het aanmeldoppervlak als kenmerk van de sterkte "Phishing-resistant MFA" (authenticatiesterktes). Deze pagina bevat geen expliciete uitspraak over AiTM, dus deze beoordeling is de conclusie van de auteur. Hoe je een basisbeleid met authenticatiesterkte aanmaakt, staat op de pagina MFA voor alle gebruikers. Het is zinvol met beheerders te beginnen.

Token Protection en de grenzen ervan

Token Protection is een sessiebesturing in Conditional Access. Ze accepteert alleen aanmeldtokens die cryptografisch aan een geregistreerd apparaat zijn gebonden. Een gestolen token werkt dan niet op een ander apparaat. Volgens Microsoft Learn (pagina van augustus 2026) is de functie algemeen beschikbaar voor native applicaties op Windows, iOS, iPadOS en macOS en geldt ze voor Exchange Online, SharePoint Online en Teams. Op Windows komen Windows 365 en Azure Virtual Desktop erbij. De pagina bevat geen aparte licentie-informatie, dus de licentievereiste moet apart worden uitgezocht. Als Conditional Access-functie vereist Token Protection volgens de eigen afleiding van de auteur minimaal Entra ID P1. Dit is geen citaat van Microsoft.

De grenzen zijn duidelijk benoemd. Browsergebaseerde applicaties worden alleen in preview ondersteund en alleen voor geselecteerde webapps die Azure Resource Manager gebruiken. Outlook op het web valt daar dus niet onder. Bovendien moeten apparaten Entra-geregistreerd, -gekoppeld of hybride gekoppeld zijn. Apple-apparaten moeten beheerde apparaten zijn met de single sign-on-extensie. Voor bedrijven met privéapparaten is dat een echte drempel.

Token Protection vermindert token replay, maar neemt het risico niet weg. Microsoft adviseert een pilotgroep, de modus "Alleen rapporteren" en evaluatie van de aanmeldlogboeken vóór een brede uitrol. Een compliant apparaat als toegangsvoorwaarde, het beperken van toestemming voor nieuwe apps en het regelmatig controleren van nieuwe enterprise-applicaties helpen ook. Phishingbestendige MFA en apparaatgebonden toegang verlagen het risico; monitoring ontdekt wat er toch doorheen komt.

Noodprocedure: sessies intrekken, apparaten en MFA-methoden opschonen

De volgende volgorde is een aanbeveling van de auteur, afgeleid van de Microsoft-documentatie over het intrekken van toegang en het Huntress-rapport. Het is geen officiële vereiste. De algemene aanpak na een geslaagde aanval staat in het artikel Ransomware: draaiboek voor de eerste 60 minuten, en delen ervan zijn hier toepasbaar.

1. Het account blokkeren en sessies intrekken: In het Entra-beheercentrum onder Gebruikers wordt "Account ingeschakeld" uitgeschakeld en "Sessies intrekken" gekozen, of via PowerShell met Revoke-MgUserSignInSession. Dit voorkomt nieuwe tokens.
2. Het wachtwoord resetten: In hybride omgevingen adviseert Microsoft het wachtwoord tweemaal te resetten in de on-premises Active Directory. Sessies worden daarna opnieuw ingetrokken.
3. MFA-methoden controleren: Onbekende methoden, vooral een nieuwe authenticator-app, worden verwijderd. De echte gebruiker stelt zijn methoden pas daarna in, bij voorkeur met een bevestigend terugbelgesprek.
4. Apparaten controleren: Onbekende geregistreerde apparaten worden uitgeschakeld en verwijderd. Ze zijn een teken van persistentie.
5. De mailbox opschonen: Regels, doorsturen, delegaties en transportregels worden gecontroleerd en verwijderd. Verzonden en verwijderde items worden beoordeeld op alles wat ongebruikelijk is.
6. Apps controleren: Onbekende enterprise-applicaties en app-toestemmingen worden verwijderd.
7. De omvang vaststellen: Aanmeldlogboeken vanaf het vroegste verdachte tijdstip worden geëvalueerd. Ook andere accounts in dezelfde afdeling moeten worden bekeken, omdat de campagne vaak meerdere accounts per organisatie trof.
8. De zakelijke impact beoordelen: Zijn bankgegevens, salarisgegevens of facturen gewijzigd? Bank, belastingadviseur en salarisadministratie worden geïnformeerd, betalingen worden gestopt en wijzigingsverzoeken telefonisch bevestigd. De directie neemt deze beslissing.
9. De meldplicht beoordelen: Of een melding aan de toezichthouder vereist is, hangt af van het risico. De termijn is 72 uur nadat men er kennis van heeft genomen (artikel 33 AVG). Dit is geen juridisch advies.

Waarom intrekking niet onmiddellijk werkt

Volgens Microsoft zijn toegangstokens standaard een uur geldig. Intrekking blokkeert nieuwe tokens en maakt refresh-tokens ongeldig, maar reeds uitgegeven toegangstokens blijven geldig tot ze verlopen. Bij applicaties met eigen sessiecookies moet de applicatie zelf de toegang beëindigen. Continuous Access Evaluation (CAE) verkort deze tijd voor Exchange Online, SharePoint Online en Teams tot enkele minuten, volgens Microsoft met een vertraging tot 15 minuten. Huntress meldt dat toegangstokens tot ongeveer 90 minuten geldig bleven en dat een wachtwoordreset alleen noch nepapparaten noch MFA-methoden verwijdert. Beide horen bij elkaar: op "Sessies intrekken" klikken is een begin, niet het einde.

Wat beheerders en directeuren deze week kunnen controleren

• Is de device code flow geblokkeerd, of zijn de Security Defaults ingeschakeld?
• Eist een beleid MFA voor alle gebruikers, resources en clienttypen zonder app-uitzonderingen?
• Zijn verouderde protocollen zoals IMAP, POP3 en SMTP-authenticatie geblokkeerd?
• Zijn er twee noodtoegangsaccounts die van het beleid zijn uitgesloten en apart zijn beveiligd?
• Zijn verificatiemethoden, apparaten en inboxregels in de boekhouding en bij HR gecontroleerd?
• Is duidelijk wie bij een vermoeden beslist en welke dienstverlener buiten kantooruren bereikbaar is?

Bij de IT-dienstverlener komt het aan op reactietijd, toegang tot logs, kennis van het beleid en schriftelijke documentatie van uitzonderingen. Een externe blik op de configuratie kan nuttig zijn, bijvoorbeeld via de security checks. Ook de eigen website en het maildomein maken deel uit van het aanvalsoppervlak. De websitecheck bekijkt de website van buitenaf, maar controleert geen Entra-instellingen.

Door zijn brede verspreiding is Microsoft 365 het standaarddoelwit. Wie de standaardinstellingen aanscherpt, apparaten en methoden in de gaten houdt en het noodgeval vooraf doorspreekt, neemt de basis voor automatisering weg. Nuchter bekeken is dit minder een kwestie van paniek dan van configuratie en routine.