Sessiekaping: waarom MFA je niet altijd redt

Multifactorauthenticatie is een van de beste dingen die je kunt regelen. Het houdt een enorme hoeveelheid gestolen wachtwoorden buiten de deur. Maar er is een misverstand dat hardnekkig is: dat een aanvaller die MFA tegenkomt, klaar is.

Dat klopt niet. Er is een aanvalsvorm waarbij MFA gewoon netjes wordt doorlopen — door jou, op het echte moment — en de aanvaller daarna alsnog binnen zit. Niet omdat hij je code heeft gekraakt, maar omdat hij het bewijs heeft gestolen dat je al ingelogd bent. Dat heet sessiekaping.

Dit is geen reden om aan MFA te twijfelen. Het is een reden om te stoppen met denken dat het inlogscherm de finish is. Hieronder leggen we uit wat een sessie is, hoe die gestolen wordt, en welke maatregelen hier wél verschil maken.

Wat een sessie eigenlijk is

Als je inlogt bij een webdienst, moet die dienst onthouden dat jij het bent. Anders zou je bij elke klik opnieuw je wachtwoord en je code moeten invoeren. Daarom krijgt je browser na een geslaagde login een sessietoken, meestal opgeslagen als cookie.

Vergelijk het met een polsbandje op een festival. Bij de ingang controleren ze je ticket en je identiteitsbewijs — dat is het inloggen met MFA. Daarna loop je vrij rond en kijkt niemand meer naar je ticket. Ze kijken naar je polsbandje.

Een aanvaller die dat polsbandje in handen krijgt, hoeft de ingang niet meer langs. Hij loopt naar binnen alsof hij er al was. Zijn browser laat hetzelfde token zien als dat van jou, en de dienst ziet geen reden om iets te vragen.

Waarom MFA hier niet helpt

MFA beschermt het moment van inloggen. Sessiekaping speelt zich af ná dat moment. Dat is het hele punt, en het is belangrijk om dat onderscheid scherp te hebben, want het bepaalt welke maatregelen wél werken.

Het is dus geen lek in MFA en geen fout in je authenticator-app. De aanvaller probeert je tweede factor niet te verslaan. Hij wacht tot jij hem zelf hebt gebruikt en pakt daarna wat er overblijft.

Dit onderwerp raakt aan twee artikelen die we eerder schreven, maar het is er niet hetzelfde als. In waarom sms-codes niet meer genoeg zijn gaat het over het onderscheppen of omleiden van de code zelf. In de onverwachte routes naar accounts komt sessiediefstal langs als één van zeven zij-ingangen. Dit artikel behandelt die ene route volledig.

Drie manieren waarop een sessie wordt gestolen

1. Phishing via een tussenpagina

Dit is veruit de meest voorkomende variant en tegelijk de meest onderschatte. Je klikt op een link en komt op een inlogpagina die er precies uitziet zoals je gewend bent. Het verschil: die pagina is een doorgeefluik. Alles wat jij invult, wordt in real time doorgestuurd naar de échte dienst.

Je vult je wachtwoord in en dat komt aan. Je krijgt een MFA-verzoek, want de echte dienst vraagt daar netjes om. Je keurt goed. Je komt binnen en ziet je eigen mailbox — alles werkt. Maar de tussenpagina heeft het sessietoken dat op dat moment werd uitgegeven, meegepikt.

Voor jou voelt het als een normale login. Er is geen foutmelding, geen tweede prompt, geen moment waarop je denkt: dit klopt niet. Dat is precies waarom deze aanval werkt op mensen die goed opletten. Zie ook hoe AI phishing overtuigender maakt.

2. Meelezen in de browsersessie zelf

Een variant waarbij de aanvaller nog dichter op de huid zit: hij laat jou werken in een browser die hij feitelijk bestuurt of meekijkt. Je ziet een echte inlogpagina van de echte dienst, dus de gebruikelijke controles — klopt het adres, klopt het slotje — leveren niets verdachts op.

Zodra de login rond is, is het token beschikbaar aan de kant van de aanvaller. Ook hier geldt: er wordt niets gekraakt, er wordt meegekeken op het moment dat het waardevolle stukje wordt afgegeven.

3. Cookies van het apparaat plukken

De derde route heeft niets met een nepwebsite te maken. Als er malware op een laptop staat — vaak zogeheten infostealers, die specifiek zoeken naar opgeslagen wachtwoorden en cookies — kan die de sessietokens gewoon uit de browser halen en doorsturen.

Dit is de stilste variant. Er is geen verdachte e-mail waar je later op terug kunt kijken. De besmetting kwam misschien via een gekraakte download, een kwaadaardige advertentie of een browserextensie. We schreven eerder over malware die je virusscanner niet ziet en over malvertising.

Het gevolg is wel het opvallendst: als iemand de tokens van je apparaat haalt, gaat het meestal niet om één dienst. Alles waar je in die browser op ingelogd was, ligt tegelijk open.

Hoe dit er in de praktijk uitziet

Een administratiekantoor met 19 medewerkers. Een medewerkster krijgt een bericht dat er een gedeeld document voor haar klaarstaat. Ze logt in, komt binnen, opent het document. Het is een nietszeggende factuur en ze denkt er verder niet over na.

Drie dagen later belt een klant over een betalingsherinnering die hij niet begrijpt. In de verzonden items staat inderdaad een mail vanaf haar adres, met een factuur waarop een ander rekeningnummer staat. In de mailbox blijkt een regel te staan die alle berichten met het woord factuur direct naar een submap verplaatst, zodat de reacties haar nooit bereikten.

In het aanmeldlogboek was maar één ding te zien: een geslaagde aanmelding vanaf een onbekend apparaat, zonder MFA-uitdaging, want die was volgens de dienst al gedaan. Het wachtwoord veranderen loste niets op — de sessie liep gewoon door. Pas toen de sessies expliciet werden ingetrokken, stopte de toegang.

Dat laatste is de belangrijkste les van dit scenario: wachtwoord wijzigen is niet genoeg. Een gestolen sessie blijft geldig tot je hem actief beëindigt.

Wat hier wél tegen helpt

Er is geen enkele knop die dit oplost. Wel een stapel maatregelen die elkaar aanvullen, in volgorde van effect.

1. Passkeys of hardwaresleutels. Dit is verreweg het sterkste antwoord op de eerste twee routes, en het wordt te weinig genoemd. Een passkey is gekoppeld aan het echte adres van de dienst. Sta je op een nagemaakte pagina, dan wérkt de passkey simpelweg niet — er valt niets door te geven, want er is geen code die je kunt overtypen. De tussenpagina loopt vast. Zie wat passkeys zijn en hoe ver de invoering inmiddels is.

2. Stel eisen aan het apparaat, niet alleen aan de gebruiker. Als je afdwingt dat toegang alleen mag vanaf een bekend, beheerd en bijgewerkt apparaat, wordt een gestolen token op een vreemde laptop een stuk minder bruikbaar. Dit regel je met voorwaardelijke toegang; lees wat conditional access voor je doet.

3. Kort de levensduur van sessies in waar het telt. Niet overal — dan word je collega’s gek van het opnieuw inloggen. Wel voor beheerdersaccounts, financiële systemen en toegang vanaf onbeheerde apparaten. Vraag daarnaast om herbevestiging bij gevoelige handelingen, zoals het wijzigen van bankgegevens.

4. Zorg dat je sessies kúnt intrekken. Weet wie dit mag doen en hoe het gaat, vóórdat het nodig is. Bij verdenking is de volgorde: sessies intrekken, wachtwoord wijzigen, MFA-methodes controleren op onbekende toevoegingen, en de mailboxregels nalopen.

5. Kijk in je aanmeldlogboek. Een aanmelding zonder MFA-uitdaging vanaf een nieuw apparaat in een ander land is een signaal. Je hoeft daar geen duur platform voor; het gaat erom dat iemand er periodiek naar kijkt. Zie logging op orde brengen en doorlopende monitoring.

6. Houd de laptops schoon. Tegen route drie helpt geen enkele instelling aan de inlogkant. Daar gaat het om bijgewerkte apparaten, fatsoenlijke endpointbeveiliging en grip op wat er in de browser wordt geïnstalleerd.

Veelgestelde vragen

Wat is het verschil tussen sessiekaping en session hijacking?

Niets — session hijacking is de Engelse term die je in vrijwel alle documentatie tegenkomt. Je ziet ook sessiediefstal of cookie hijacking voorbijkomen. Het gaat steeds om hetzelfde: een aanvaller neemt het sessie-ID van een ingelogde gebruiker over en krijgt daarmee ongeautoriseerde toegang tot het account, zonder het wachtwoord of de code te kennen.

Speelt cross-site scripting (XSS) hier ook een rol?

Ja, bij websites met een kwetsbaarheid erin. Met cross-site scripting laat een aanvaller kwaadaardige scripts meeliften op een pagina die bezoekers vertrouwen, en die scripts kunnen sessiecookies stelen en doorsturen. Voor de meeste MKB-bedrijven is dat vooral relevant voor de eigen website of webshop: houd software en plug-ins bijgewerkt en zorg dat sessiecookies alleen via HTTPS worden verstuurd en niet uit te lezen zijn door scripts.

Is openbare wifi nog steeds een risico voor sessiekaping?

Minder dan vroeger. Nu vrijwel alle websites HTTPS gebruiken, valt een sessie-ID niet meer zomaar uit de lucht te plukken op het netwerk van een café. Het risico zit tegenwoordig in nagemaakte netwerken die je naar een tussenpagina sturen, niet in het meelezen zelf. Gebruik openbare wifi dus gerust, maar log alleen in via een adres dat je zelf hebt ingetypt of uit je bladwijzers haalt.

Moeten we MFA dan uitzetten?

Absoluut niet. MFA blijft de maatregel met de grootste opbrengst per geïnvesteerd uur en blokkeert het overgrote deel van de aanvallen met gestolen wachtwoorden. Het punt van dit artikel is dat je het niet als eindpunt moet zien. Als je nog aan het begin staat, begin dan gewoon bij de keuze van je MFA-methode.

Hoe weet ik of een sessie van ons gekaapt is?

De duidelijkste signalen staan in het aanmeldlogboek: een geslaagde aanmelding vanaf een onbekend apparaat of een onlogische locatie, zonder bijbehorende MFA-uitdaging. Verder: mailboxregels die niemand heeft gemaakt, verzonden berichten die je niet kent, en een MFA-methode die er ineens bij staat. Zie ook wat je doet bij een gehackt account.

Helpt een VPN hiertegen?

Nauwelijks. Een VPN versleutelt je verbinding, maar bij deze aanvallen wordt de verbinding niet afgeluisterd — het token wordt afgegeven op de eindpunten zelf. Een VPN heeft zijn nut, maar niet voor dit probleem.

Wat doen we als eerste, als we morgen willen beginnen?

Twee dingen. Zet passkeys of hardwaresleutels aan voor de accounts die het meest waard zijn: beheerders, directie en iedereen die betalingen doet. En zorg dat iemand weet hoe je sessies intrekt, zodat je bij een verdenking niet gaat zoeken. De rest kan daarna.

Twijfel je of dit bij jullie goed staat? We kijken graag een keer mee naar je aanmeldinstellingen en je logboek — vaak is in een uur al duidelijk waar de ruimte zit.