Account gekaapt ondanks 2FA: een gestolen cookie is voldoende

Het antivirusprogramma meldt dat de scan succesvol is verlopen. Malware gevonden, verwijderd, alles schoon. Twee dagen later verstuurt uw Google-account spam en op de apparatenlijst staat een computer die niet van u is. Tweefactorauthenticatie stond de hele tijd ingeschakeld.

Wat hier gebeurt, wordt ‘sessiekaping’ genoemd: het overnemen van een sessie die al actief is. De aanvaller heeft noch uw wachtwoord, noch uw tweede authenticatiefactor nodig. Het enige wat hij nodig heeft, is het kleine bestandje dat uw browser opslaat nadat u zich hebt aangemeld, zodat u bij uw volgende bezoek niets meer hoeft in te voeren. Dat bestandje is de sessiecookie.

Google beschrijft dit openlijk op zijn eigen Chromium-blog: de diefstal vindt plaats na het inloggen en omzeilt daardoor de tweefactorauthenticatie. Bovendien is het moeilijk om dit met antivirussoftware te verhelpen, omdat de cookies blijven werken, zelfs nadat de malware is verwijderd.

Hoe de diefstal werkt

In het begin is er bijna altijd sprake van een infostealer, een programma dat is ontwikkeld om inloggegevens te verzamelen. Het dringt de computer binnen via gekraakte software, een gemanipuleerd installatieprogramma of een bijlage. Eenmaal daar aangekomen leest het de bestanden waarin de browser zijn cookies opslaat. De aanvaller importeert vervolgens de cookie in zijn eigen browser en roept de website op. De dienst ziet een geldige, ingelogde sessie en stelt geen verdere vragen.

Hoe groot deze markt is, blijkt uit het Global Threat Intelligence Report dat beveiligingsbedrijf Flashpoint op 11 maart 2026 heeft gepubliceerd. Voor het jaar 2025 telt Flashpoint meer dan 11,1 miljoen computers die zijn geïnfecteerd met infostealers en 3,3 miljard inloggegevens en cloudtokens die daaruit zijn gestolen. Sessiecookies zijn in die telling niet eens meegerekend.

Hoe dicht dit bij huis komt, bleek uit Operatie Endgame. Op 24 juni 2026 meldde Europol een actie tegen de infostealers StealC en Amadey en tegen het SocGholish-distributienetwerk, waarbij ook Duitsland betrokken was. 326 servers en 142 domeinen werden buiten werking gesteld en 27 miljoen sets inloggegevens werden teruggewonnen. Slachtoffers werden onder meer via Have I Been Pwned op de hoogte gebracht.

De tweede factor staat op de verkeerde plaats. Een sms-code, een app-melding en een beveiligingssleutel controleren allemaal wie er inlogt. De cookie wordt pas achteraf aangemaakt, als bewijs dat deze controle is doorstaan. Wie in het bezit is van dit bewijs, hoeft de controle niet opnieuw te doorlopen. Zelfs het Advanced Protection Program van Google verandert daar niets aan. Volgens Google wordt iemand die ingelogd blijft mogelijk niet opnieuw om de beveiligingssleutel gevraagd. Hoe u uw accounts op de juiste wijze kunt beveiligen, wordt behandeld in „Een wachtwoord alleen is niet voldoende“.

Wat de browsers hieraan doen

Op Windows versleutelt Chrome cookies sinds versie 127 van juli 2024 met „App-Bound Encryption“ en koppelt de sleutel aan de applicatie. Google noemt zelf de beperking: malware die met verhoogde rechten draait, omzeilt de beveiliging. Dat maakt diefstal weliswaar duurder, maar voorkomt deze niet.

De echte vooruitgang heet ‘Device Bound Session Credentials’, kortweg DBSC. De browser genereert een sleutelpaar waarvan de privé-sleutel het apparaat nooit verlaat. Op Windows bevindt deze zich in de TPM, de beveiligingschip op het moederbord. De dienst vraagt regelmatig of de browser nog steeds over die sleutel beschikt. Een cookie op de computer van iemand anders voldoet niet aan die vraag.

Voor websites is de technologie al beschikbaar sinds Chrome 145. Google heeft deze functie op 9 april 2026 voor zichzelf ingeschakeld met Chrome 146 onder Windows en rolt deze sinds 25 mei 2026 uit voor Workspace-accounts en persoonlijke Google-accounts, zonder dat gebruikers iets hoeven in te schakelen. Er blijven twee beperkingen bestaan. Volgens de W3C-specificatie voorkomt DBSC geen toegang zolang de aanvaller zich nog op het apparaat bevindt. Bovendien moet elke website zelf meewerken, waardoor de bescherming eerst bij Google-diensten wordt geïmplementeerd.

Firefox presteert op dit punt slechter dan veel mensen veronderstellen. De cookiedatabase staat onversleuteld op de schijf. De vermelding in de bugtracker van Mozilla, bug 56788, werd 25 jaar geleden ingediend, in 2000 gesloten als WONTFIX en twee jaar geleden opnieuw geopend. De bug heeft prioriteit P3 en is aan niemand toegewezen. Total Cookie Protection brengt hier geen verandering in; dat betreft trackingbescherming.

Wat u nu kunt doen

De volgorde is bepalend. Bij een infectie met malware schrijft het Duitse Federale Bureau voor Informatiebeveiliging (BSI) de volgende volgorde voor: installeer eerst het systeem opnieuw, wijzig daarna de wachtwoorden. Wie het andersom doet en het nieuwe wachtwoord op de geïnfecteerde computer invoert, levert deze direct uit.

Vervolgens komt de stap die de meeste mensen overslaan. Een nieuw wachtwoord zorgt er niet noodzakelijkerwijs voor dat een aanvaller die in het bezit is van een geldige cookie, wordt uitgesloten. U moet de geopende sessies afzonderlijk beëindigen.

Google: myaccount.google.com, sectie Beveiliging, „Alle apparaten beheren“. Elke sessie wordt afzonderlijk weergegeven; tik op het apparaat en meld u af. Google biedt geen enkele knop waarmee u ze allemaal tegelijk kunt afmelden.

Microsoft: account.microsoft.com, geavanceerde beveiligingsopties, „Overal afmelden”. Volgens Microsoft kan het afmelden tot 24 uur duren, en de Xbox is hiervan uitgesloten.

Apple: account.apple.com, sectie ‘Apparaten’, selecteer het apparaat, ‘Verwijderen uit account’. Het apparaat verschijnt opnieuw als iemand er nog steeds op is aangemeld.

Wat passkeys wel en niet doen

Passkeys worden gezien als de opvolger van het wachtwoord, en het BSI noemt ze een zeer veilige vorm van authenticatie. Dat is waar, maar nogmaals: dit heeft alleen betrekking op het inloggen zelf. Een passkey voorkomt dat iemand zich als u aanmeldt. Het voorkomt niet dat iemand de sessie overneemt die u al open hebt staan. Dat het inloggen zelf kwetsbaar blijft, blijkt uit Pass-the-Passkey.

Het eerlijke beeld is ongemakkelijk. In zijn beveiligingsblog van 9 april 2026 schrijft Google dat er op geen enkel besturingssysteem een betrouwbare manier bestaat om cookiediefstal met alleen software te voorkomen zodra er malware op het apparaat aanwezig is. Wat DBSC verandert, is de houdbaarheid van de buit. De gestolen cookie is dan alleen nog bruikbaar op de machine waarop deze is aangemaakt.

Totdat dit overal het geval is, blijft het ongemakkelijke deel voor uw rekening. Geen gekraakte software, alleen downloads van de originele bron, en bij elk vermoeden eerst het systeem opnieuw installeren en daarna de sessies beëindigen. In die volgorde.