Kort samengevat: hergebruik sessietoken na authenticatie tussen apparaten
- Het gat: Elke pitchdeck behandelt MFA als eindstreep. Cookie-diefstal ontmaskert die bluf. MFA authenticeert het login-event, en een gestolen sessiecookie is het bewijs dat de login al plaatsvond, dus geeft de server het account zonder tweede prompt weg.
- Het bewijs: SpyCloud herwon in 2024 meer dan 17 miljard gestolen credential-records uit de crimineleonderwereld en DBSC dekt alleen Chrome 146+ op Windows. cside fingerprintt apparaten via meer dan 250 signalen op 99,7% nauwkeurigheid en pakt het moment dat een cookie vanaf de verkeerde machine wordt afgespeeld.
- De beslissing: Elk team dat leunt op MFA plus HttpOnly voor levende sessies is blootgesteld. Voeg dit kwartaal runtime-scriptmonitoring voor token-exfiltratie en apparaatgerichte gedragsanalyse toe, voordat een infostealerverkoop op Telegram jouw incident wordt.
Weinig tijd? Bekijk cside accountovername-detectie. Dit dekt alles hieronder in één deployment.
Cookiediefstal is wanneer een aanvaller het sessietoken dat een website heeft uitgegeven na het inloggen van een gebruiker, afvangt en opnieuw afspeelt vanaf een ander apparaat. De aanvaller erft de toegang van de gebruiker zonder het wachtwoord te kennen. Er wordt geen MFA-prompt geactiveerd. De gebruiker blijft ingelogd en merkt niets; beide sessies draaien parallel.
De reden dat MFA dit niet stopt is structureel. MFA authenticeert de gebruiker bij de inloggebeurtenis. Na het inloggen vertrouwt de server op de sessiecookie, een tijdgebonden credential die bewijst dat de browser al door authenticatie is gegaan. Een gestolen cookie is bewijs dat de browser er al doorheen is. De server kan het verschil niet zien tussen de echte gebruiker en de aanvaller tenzij het iets controleert buiten het token zelf.
Beveiligingsonderzoekers noemen dit een pass-the-cookie-aanval. Het is de dominante techniek achter een groot deel van de accountovernames in 2026.
Hoe sessieovername werkt
De aanvalsketen is dezelfde ongeacht hoe de cookie werd verkregen.
- De gebruiker authenticeert. De browser voltooit het inloggen en MFA. De server geeft een sessiecookie uit, een lange willekeurige string, en stuurt deze terug met het antwoord.
- De aanvaller vangt de cookie af. Dit gebeurt via infostealer-malware, een phishingproxy of een kwaadaardig script dat op de pagina draait.
- De aanvaller speelt de cookie opnieuw af. Vanuit zijn eigen browser of een script stelt hij de gestolen cookie in en stuurt een verzoek naar de doelsite.
- De server ziet een geldige sessie. De cookie is actief en werd uitgegeven aan een geauthenticeerde gebruiker. Toegang wordt verleend.
De legitieme sessie blijft open. De gebruiker browst nog steeds op zijn apparaat; de aanvaller browst hetzelfde account op het zijne.
Drie manieren waarop aanvallers sessietokens stelen
Infostealer-malware
Infostealer-malware is de meest voorkomende route. Families zoals Lumma, Vidar en RedLine doorzoeken de cookie-opslag op schijf van de browser, extraheren sessietokens voor honderden sites en sturen deze binnen minuten na infectie naar een door de aanvaller beheerste server. Het SpyCloud 2025 Jaarlijks Rapport Blootstelling Identiteit herstelde meer dan 17 miljard gestolen inloggegevensrecords uit de criminele onderwereld in 2024. Gestolen sessiecookies bereiken Telegram-markten binnen uren na een succesvolle infectie.
De cookie-opslag van de browser is een lokaal bestand, in platte tekst of een lokale SQLite-database. Elk proces dat met de rechten van de gebruiker draait, kan het lezen. Infostealers onderscheppen geen netwerkverkeer; ze lezen van schijf nadat de browser de gegevens al heeft gedecodeerd.
Adversary-in-the-middle (AiTM) phishing
AiTM-phishing plaatst een reverse proxy tussen het slachtoffer en de echte inlogpagina. Het slachtoffer ziet een exacte visuele kopie van de login, voert inloggegevens in en voltooit MFA. De proxy stuurt alles door naar de echte site en vangt de resulterende sessiecookie op bij terugkomst. De aanvaller beschikt nu over een geldig post-authenticatie token zonder zelf MFA te hebben doorlopen.
Deze techniek omzeilt traditionele antiphishingcontroles omdat de pagina authentiek oogt, de MFA-prompt wordt voltooid bij de echte service en het slachtoffer normaal inlogt. Alleen de proxy van de aanvaller zit in het midden, onzichtbaar.
Kwaadaardige scripts van derden en XSS
Een XSS-kwetsbaarheid of een gecompromitteerd script van derden kan sessietokens bij runtime uit de browser extraheren. JavaScript dat in de oorsprongscontext van de pagina draait, kan cookies lezen die niet als HttpOnly zijn gemarkeerd, ze coderen en exfiltreren in verzoeken die op routinematige analyseoproepen lijken.
Dit is het client-side supply chain-vector: de aanvaller richt zich niet direct op jouw site maar compromitteert een analysetag, een chatwidget of een betalingsbibliotheek die jouw site vertrouwt en op elke pagina laadt. De skimmer arriveert in code die de site al als veilig beschouwt.
Waarom standaardverdedigingen dit missen
Het HttpOnly-attribuut
HttpOnly voorkomt dat JavaScript de cookie leest via document.cookie. Het blokkeert XSS-tokenleesacties voor die specifieke cookie, wat belangrijk is. Maar het doet niets tegen infostealer-malware die de cookie rechtstreeks van schijf leest nadat de browser deze heeft opgeslagen, en beschermt niet tegen een AiTM-proxy die het token via het netwerk afvangt voordat het de beschermde opslag bereikt.
HTTPS en TLS
TLS versleutelt verkeer in transit en stopt passief afluisteren van het netwerk. Infostealers lezen van schijf, na decodering. AiTM-proxies beëindigen TLS aan beide kanten van de verbinding. Geen van beide wordt alleen door transportversleuteling gestopt.
MFA
MFA verifieert de gebruiker bij het inloggen. Na het inloggen vertrouwt de server alleen op de cookie. Een gestolen cookie activeert nooit een andere MFA-prompt tenzij de server herauthenticatie afdwingt op basis van apparaat- of gedragssignalen, wat de meeste servers niet bij elk verzoek doen.
Apparaat-gebonden sessies en DBSC
De structurele oplossing voor pass-the-cookie-aanvallen is het koppelen van de sessie aan de hardware die deze heeft aangemaakt. Een gestolen cookie wordt nutteloos als de server cryptografisch bewijs vereist dat de browser nog steeds een specifieke apparaat-gehouden privésleutel beheert.
Het Device Bound Session Credentials (DBSC)-protocol van Google doet dit met behulp van de TPM of Secure Enclave van het apparaat. Op Chrome 146+ voor Windows genereert de browser bij het opzetten van de sessie een privésleutel in hardware. Kortdurende sessiecookies worden alleen uitgegeven zolang de browser het bezit van die sleutel kan bewijzen. Een aanvaller die de cookie van een ander apparaat steelt, kan deze niet vernieuwen zonder de privésleutel.
Praktische beperkingen medio 2026:
- Dekking: Chrome 146+ op Windows is de primaire implementatie. iOS, Firefox en Safari ondersteunen DBSC nog niet.
- Terugvalpaden: wanneer geen TPM aanwezig is of een netwerkfout optreedt tijdens sleutelverificatie, kan DBSC koppeling overslaan. Die sessie gedraagt zich dan als een conventionele cookie.
- Malware op hetzelfde apparaat: als een infostealer op dezelfde machine draait die de privésleutel bezit, kan de aanvaller de sessie vanaf dat apparaat gebruiken. DBSC richt zich op off-device herhaling, niet op compromittering op hetzelfde apparaat.
Deze hiaten maken DBSC tot één laag, niet tot een complete oplossing.
Checklist voor het voorkomen van sessieovername
| Controle | Wat het stopt |
|---|---|
| TLS + HSTS | Netwerk afluisteren (session sidejacking) |
| HttpOnly-, Secure-, SameSite-attributen | XSS-leesacties via document.cookie |
| Rotatie sessie-ID na inloggen | Sessiefixatie |
| Korte absolute en inactieve time-outs | Venster voor herhaling na diefstal |
| Lange willekeurige sessietokens | Token raden |
| Serverside intrekking bij uitloggen | Actieve sessies na accountactie |
| DBSC (Chrome 146+ / Windows) | Off-device herhaling van gestolen cookie |
| Monitoring van client-side scripts | Token-exfiltratie via XSS of supply chain |
| Apparaatintelligentie + gedragsscore | Opnieuw afgespeeld token dat de actieve sessie bereikt |
Geen enkel controle is volledig. Infostealers omzeilen transportcontroles. AiTM-proxies omzeilen MFA en HTTPS op de sessielaag. HttpOnly beperkt één JavaScript-leesroute maar niet schijfleesacties. Het gelaagde model werkt omdat elke controle omzeilt wat de anderen niet kunnen.
Een gekaapte sessie detecteren in de live browser
Preventie vermindert de kans op tokendiefstal. Detectie vangt de sessie op die al gestolen is en opnieuw wordt afgespeeld.
cside draait als een enkel eigen JavaScript-snippet in de browser van de bezoeker zonder proxy en zonder DNS-wijzigingen. Het monitort wat scripts van derden en de sessie zelf daadwerkelijk doen op de live pagina voor echte gebruikers, niet wat een crawler of scanner observeert bij code in rust.
Token-exfiltratie aan de bron. Een script van derden dat onverwachte event listeners aan formuliervelden koppelt, cookiewaarden leest buiten normale analyseoproepen of gegevens naar een onbekend domein stuurt, activeert een detectiesignaal voordat het token de pagina verlaat. Dit sluit het XSS- en supply chain-vector voordat een cookie wordt gestolen. Dezelfde runtime-monitoring detecteert ook affiliate cookie stuffing en link hijacking, waarbij geïnjecteerde scripts door de aanvaller beheerde affiliate-cookies plaatsen of uitgaande links herschrijven om attributie om te leiden, een even onzichtbare browserlaag-aanval.
Apparaatmismatch bij herhaling. Wanneer een gestolen cookie vanaf een ander apparaat wordt gebruikt, verandert de vingerafdruk van de sessie. De apparaatintelligentie van cside genereert een persistente apparaat-ID uit meer dan 250 browser-, hardware- en netwerksignalen met 99.7% nauwkeurigheid. Een vingerafdrukwisseling na een gevestigde sessie is een anomalie die de gedragsscore-laag markeert voor herauthenticatie of blokkering.
Gedragssignalen. Geautomatiseerde sessie-herhaling vanuit een script of een AI-agent produceert patronen die verschillen van echte menselijke sessies: geen realistisch muisbeweging, geen scrollvariatie, geen natuurlijk typritme. De gedragsniveau-signalen van cside scheiden automatisering van echt gebruik.
cside integreert ook AI-agentdetectie en vangt orkestratiegereedschappen en geautomatiseerde browsers op die gestolen sessies opnieuw afspelen of gescripte accounttoegang op schaal uitvoeren.
PCI DSS 4.0.1 en sessiebeveiliging op betaalpagina's
Voor e-commerce- en betaalplatforms zijn de client-side script- en XSS-vectoren die sessietokens exfiltreren dezelfde risico's die PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1 aanpakken. Vereiste 6.4.3 vereist een scriptinventaris en autorisatiemethode voor elk script op betaalpagina's. Vereiste 11.6.1 vereist continue monitoring en alertering over ongeautoriseerde wijzigingen in betaalpagina-scripts en HTTP-beveiligingsheaders.
Een kwaadaardig script van derden dat een sessietoken of betaalkaartgegevens exfiltreert op een betaalpagina is precies de dreiging die deze vereisten aanpakken. cside automatiseert beide controles en produceert wekelijkse QSA-klare rapporten (VikingCloud-gevalideerd). Monitoring die een kwaadaardig script detecteert dat sessietokens steelt, voldoet ook aan het tamper-detectiemandat dat QSA's nu beoordelen.
PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1 zijn verplicht en worden beoordeeld sinds 1 april 2025.
