'We hebben MFA aan' is geen strategie: de aanval verschoof naar je sessie

Bij de twee geraffineerdste overnames van Microsoft 365-accounts van de afgelopen week viel geen wachtwoord te stelen, want er werd er geen gebruikt. De aanvaller liet het slachtoffer zelf een apparaat goedkeuren, of zelf een sleutel koppelen, en nam daarna de ingelogde sessie over. De inlog was echt. De multi-factor stond aan. En het account was toch weg.

Dat is het ongemakkelijke deel van twee verse aanvalscampagnes, en het is precies waarom de zin die ik het vaakst hoor in een securitygesprek geen antwoord meer is: “maar wij hebben MFA aanstaan”. MFA aanzetten was de makkelijke stap. De aanval is er allang omheen gaan lopen.

Mijn stelling is simpel. Aanvallers stelen je wachtwoord niet meer, ze kapen je ingelogde sessie en het moment waarop je een sleutel registreert. Zolang niemand naar aanmeld- en sessiegedrag kijkt, geeft “we hebben MFA aan” een vals gevoel van veiligheid: het beschrijft één slot op één deur, terwijl de inbraak nu door het raam van de sessie naar binnen komt.

De aanval verschoof van het wachtwoord naar de sessie

Neem Forg365, een phishing-as-a-service-platform dat deze maand opdook. Het valt het wachtwoord niet aan, maar de token die na de inlog wordt afgegeven. In de ene variant misbruikt het de device-code-inlog van Microsoft en laat het slachtoffer een apparaat van de aanvaller goedkeuren; in de andere zet het een tussenliggende proxy tussen jou en Microsoft, die de sessiecookies onderweg wegvangt. Een bijgeleverde browserextensie ververst daarna geruisloos de single-sign-on-cookies, zodat de toegang blijft werken.

Het venijn zit in de volgorde. Een geldige sessietoken is het bewijs dat je MFA al gepasseerd bént. Wie die token in handen krijgt, staat niet vóór je beveiliging maar erachter. Er valt niets meer te vragen om een tweede factor, want het systeem denkt dat die stap net gezet is.

En dit is geen boetiek-aanval van één begaafde inbreker. Forg365 wordt verhuurd als kant-en-klaar platform, met een dashboard dat de phishingmails door AI laat schrijven en de gekaapte postbussen automatisch afzoekt op trefwoorden. De vaardigheid die zo'n overname vroeger vereiste, is ingebouwd en te huur. Dat verschuift de rekensom voor elke organisatie, klein of groot: je hoeft geen strategisch doelwit te zijn om aangevallen te worden, je hoeft alleen op Microsoft 365 te draaien en één medewerker te hebben die de telefoon opneemt.

Dezelfde mechaniek zag ik terug bij de afpersgroep Helix, die via een device-code-inlog een geldige sessietoken opvangt en binnen minuten een eigen authenticator op het account registreert. Die inlog omzeilt zelfs Conditional Access en komt binnen vanaf een onbeheerd apparaat op een woon-IP dat is afgestemd op de locatie van het slachtoffer, zodat een alarm voor een onmogelijke reis niet afgaat. In sommige gevallen begon het leegtrekken van SharePoint al zes minuten na de eerste inlog.

Zelfs je “phishingbestendige” factor wordt omzeild

En passkeys dan? Die gelden als phishingbestendig, en op de inlog zelf zijn ze dat ook: een passkey werkt niet op een namaakpagina. Maar een tweede verse campagne mikt niet op de inlog, hij mikt op het registratiemoment. Een groep die Okta als O-UNC-066 volgt en zichzelf “Pink” noemt, belt medewerkers en praat ze een frauduleuze Entra-passkey aan.

De truc is de omkering. De aanvaller doet zich telefonisch voor als de helpdesk en zegt dat een beveiligingsupgrade een nieuwe sleutel vereist. Terwijl het slachtoffer op een namaakpagina de stappen doorloopt, logt een operator-gestuurd paneel op hetzelfde moment mee op het echte account en registreert het een passkey die de aanvaller beheert. De campagne raakte al organisaties in voedsel en drank, techniek, de zorg, de auto-industrie, de bouw en de luchtvaart.

De kracht van een factor doet er niet toe als je de gebruiker overtuigt om zelf een verse sleutel voor de aanvaller aan te maken. De sleutel is onkraakbaar. Het moment eromheen is dat niet.

Wat het cijfer je vertelt

Dit is geen randverschijnsel. Microsoft detecteerde in één jaar 147.000 token-replay-aanvallen, een stijging van 111 procent, waarbij een gestolen sessie werd hergebruikt om langs de inlog te komen. En dat is niet nieuw: eerder omzeilde een password-spray via een verouderde Azure CLI-route de MFA op Microsoft 365 in 81 miljoen inlogpogingen.

Het patroon is telkens hetzelfde. MFA blokkeert de voordeur, dus de aanvaller loopt eromheen: hij pakt de token, of laat je zelf de sleutel aanreiken. “We hebben MFA aan” beschrijft dat ene slot, en zegt niets over wie er meekijkt als er een sessie binnenkomt vanaf een apparaat dat niet van jou is, of als er ineens een nieuwe authenticator wordt geregistreerd. Dat zijn zichtbare signalen. Ze zijn alleen onzichtbaar als niemand ernaar kijkt.

Om eerlijk te zijn: MFA is niet zinloos

Het tegenargument verdient zijn beste vorm, want het klopt grotendeels. MFA is geen theater. Het blokkeert de overgrote meerderheid van de aanvallen, en tokendiefstal is nog altijd minder dan 5 procent van alle identiteitscompromitteringen. Heb je nog geen MFA, dan is dat je eerste zet, niet een monitoringproject. Zet het aan, overal, zonder uitzonderingen. Wie dat nalaat en meteen over sessiegedrag begint, lost het kleine probleem op en laat het grote openstaan.

En toch houd ik mijn lijn. Diezelfde categorie die onder de 5 procent blijft, is wél de snelst groeiende (die 111 procent) én precies de categorie die MFA niet stopt, omdat de aanvaller de factor omzeilt in plaats van hem te kraken. “We hebben MFA aan” is daarmee een startpunt, geen eindpunt. Het als eindpunt behandelen is precies waar het valse gevoel van veiligheid zit.

Dit ligt een laag dieper dan het probleem waar ik eerder over schreef, dat een vlekkeloze Nederlandse phishingmail niet meer van echt te onderscheiden is en dat de verdediging daarom bij je proces begint, niet bij je software. Daar ging het om het herkennen van de aanval. Hier worden zelfs je phishingbestendige factoren omzeild, dus schuift de controle naar wat er ná de inlog gebeurt.

Identiteit is geen schakelaar

De kern: identiteit is geen schakelaar die je één keer omzet en daarna vergeet. Het is gedrag dat je blijft bekijken. De vraag is niet langer “hebben we MFA aan”, maar “ziet iemand het wanneer een sessie van een onbeheerd apparaat binnenkomt, of wanneer er een vreemde sleutel wordt geregistreerd”. Dat vraagt om een paar concrete dingen: een vaste manier om te verifiëren dat helpdeskcontact echt is voordat iemand een inlogwijziging doorvoert, een melding bij elke wijziging aan een passkey of MFA-factor, en het beperken van die wijzigingen tot beheerde apparaten en bekende locaties.

De aanvaller die geen wachtwoord meer hoeft te typen, laat wel degelijk een spoor na: in het apparaat, het IP, de sessie, de nieuwe sleutel. Het spoor ligt er. De enige vraag die telt, is of iemand kijkt.