Diefstal van sessiecookies en bearer-tokens
Met een gestolen sessiecookie kan iemand zich als medewerker voordoen, zonder wachtwoord of tweede factor. Werking, een echt geval en reflexen.
In 30 seconden
- Waar het gebeurt
- Op de werkplek (malware), op een nepsite die de echte inlogpagina doorgeeft1, of in een gecompromitteerde browser8.
- Wat de aanvaller wil
- Een al geopende sessie overnemen, berichten lezen en namens het slachtoffer handelen, waarbij sommige tweede factoren worden omzeild2.
- De reflex
- Uitloggen bij diensten als u klaar bent, uw sessies intrekken bij twijfel, de browsersessies regelmatig sluiten.
- Als het al gebeurd is
- Waarschuw de IT-helpdesk meteen, want de gestolen sessie blijft bruikbaar zolang ze actief is2.
Waar gaat het over
Wanneer een medewerker inlogt op zijn mailbox of een online hulpmiddel, geeft de dienst hem een klein identificatiegegeven mee, meestal een cookie, dat bewijst dat hij al is geauthenticeerd. Als een aanvaller dat gegeven in handen krijgt, kan hij binnenkomen alsof hij het slachtoffer is, zonder diens wachtwoord te kennen1.
Aan de kant van de medewerker is meestal niets te zien: de sessie loopt door, en het werk ook. Deze fiche legt uit waar de diefstal vandaan komt, wat een aanvaller ermee doet en wat ieder kan doen om het risico te verkleinen.
Directe vragen
Wat is een sessiecookie?
Na een geslaagde aanmelding gebruiken veel webtoepassingen een sessiecookie als bewijs van authenticatie1. Het webprotocol onthoudt zelf niet wie wie is van het ene verzoek tot het volgende: de server stuurt de browser daarom een token, dat de browser daarna bij elke uitwisseling toont3.
Wat is een toegangstoken en waarin verschilt het van een cookie?
Een toegangstoken dient om geautoriseerde verzoeken te doen namens een gebruiker of een dienst. Het komt veel voor in online toepassingen (SaaS) en clouddiensten4. Beide objecten hebben dezelfde zwakte: wie het toont, wordt geaccepteerd als de persoon die het heeft verkregen. NIST SP 800-63B, een versie die sinds 1 augustus 2025 is vervangen door SP 800-63-4, vermeldde ook dat de aanwezigheid van een OAuth-toegangstoken zonder andere signalen niet mag worden uitgelegd als de aanwezigheid van de gebruiker, en dat zo'n token lang na het einde van de authenticatiesessie geldig kan blijven5.
Beschermt mijn tweede factor mij niet?
Hij beschermt het inloggen, niet de sessie die daarop volgt. MITRE geeft aan dat deze techniek sommige protocollen voor multifactorauthenticatie omzeilt, omdat de sessie al is geauthenticeerd2. Microsoft preciseert dat het geen zwakte van multifactorauthenticatie is: de gestolen cookie authenticeert de aanvaller, ongeacht de inlogmethode van de gebruiker6.
Hoe lang blijft een gestolen cookie bruikbaar?
Cookies blijven vaak lang geldig, ook als de toepassing niet actief wordt gebruikt1. De aanvaller kan een cookie gebruiken zolang het actief is2. OWASP merkt ook op dat een time-out bij inactiviteit een aanvaller die de sessie heeft overgenomen niet beperkt: hij kan activiteit genereren om de sessie open te houden7.
1In de huid van de aanvaller1 min
De aanvaller zoekt een herbruikbaar element in plaats van een geheim dat hij moet raden. Cookies staan op de schijf, in het geheugen van de browser en in het netwerkverkeer naar externe systemen. Andere toepassingen op de werkplek kunnen ook authenticatiecookies in het geheugen bewaren, bijvoorbeeld toepassingen die verbinding maken met clouddiensten1.
Zodra de aanvaller de cookie heeft, importeert hij die in een browser die hij zelf beheert. Hij gebruikt de site dan als de gebruiker, zolang de sessie actief is. Hij kan gevoelige informatie inzien, e-mails lezen of alles doen wat het account van het slachtoffer mag2.
Bij het toegangstoken is phishing een beschreven route: de aanvaller registreert een valse toepassing en stuurt een link om het slachtoffer toegang te laten verlenen. Zodra het token is verleend, kan de toepassing een mogelijk langdurige toegang tot het account krijgen4. Toegangstokens hebben soms een beperkte levensduur, maar de aanvaller kan ook een vernieuwingstoken stelen, dat hem nieuwe toegangstokens geeft zonder dat hij de gebruiker iets vraagt4.
2Wat u op het scherm ziet1 min
De medewerker ziet niets: aan de kant van de beheerder kunnen wel meldingen bestaan (zie verderop). Bij een nepsite die als relais dient (verderop beschreven) lijkt de pagina sprekend op de echte: het enige zichtbare verschil is het adres6. Nadat het wachtwoord is ingevoerd, wordt het slachtoffer doorgestuurd naar de echte pagina, en gaat de aanval op de achtergrond verder6.
Hier volgt een geneutraliseerde illustratie van het adres van een relaissite. Het is voor dit voorbeeld verzonnen.
Illustration (adresse fictive, neutralisée) :
hxxps://login[.]exemple-connexion[.]invalid/
[page identique à la vraie page de connexion, seule l'adresse diffère]Er zijn enkele indirecte signalen. Als de aanvaller inlogt terwijl het slachtoffer werkt, kunnen aan de kant van de beheerder meldingen over "onmogelijke verplaatsing" verschijnen6. Onbekende regels in de inbox zijn een ander signaal: in het verderop beschreven geval maakte de aanvaller er een aan, zodat het slachtoffer de antwoorden van zijn doelwit niet zou zien6.
3Onder de motorkapIT-teams2 min
De hier geciteerde bronnen beschrijven drie manieren van diefstal.
- De stealer-malware: kwaadaardige software richt zich op de cookies van de browsers op de werkplek1. Sommige haalt de sessiecookie eruit en stuurt die naar de server van de aanvaller1.
- De nepsite als relais: bij de zogeheten adversary-in-the-middle-aanval plaatst de aanvaller een proxyserver tussen de gebruiker en de beoogde site. Zo onderschept hij het wachtwoord en de sessiecookie6. Vrije tools als Evilginx2, Modlishka en Muraena automatiseren dit proces6.
- De gecompromitteerde browser: een aanvaller kan software in een browser injecteren om de cookies, HTTP-sessies en clientcertificaten van de gebruiker over te nemen, en daarmee een geauthenticeerd intranet binnen te gaan8. Deze techniek kan ook tweefactorauthenticatie omzeilen8. Ze kan bijzondere rechten op de werkplek vereisen8.
Waarom werkt het opnieuw afspelen? De cookie is het bewijs van de aanmelding: de server controleert het wachtwoord niet op elke pagina opnieuw6. NIST SP 800-63B laat andere methoden toe om het apparaat veilig te identificeren, waaronder mutual TLS en token binding5. OWASP raadt aan de sessie-identificator te koppelen aan andere eigenschappen van de client, zoals het IP-adres of de User-Agent. Het erkent echter dat een bekwame aanvaller deze controle kan omzeilen, bijvoorbeeld door hetzelfde netwerk als het slachtoffer te delen of de User-Agent te kopiëren7.
Wat de duur betreft noemt OWASP gebruikelijke time-outs bij inactiviteit van 2 tot 5 minuten voor toepassingen met hoge waarde en van 15 tot 30 minuten voor toepassingen met laag risico. Voor een kantoormedewerker die de hele dag met een toepassing werkt, noemt het een absolute time-out van 4 tot 8 uur7. NIST SP 800-63B, sinds 1 augustus 2025 vervangen door SP 800-63-4, vroeg dat sessiegeheimen bij uitloggen worden gewist of ongeldig gemaakt5.
4IncidentanalysesEchte gevallen2 min
Phishingcampagne met een nepsite als relais tegen Microsoft 365 (gedocumenteerd op 12 juli 2022)
Op 12 juli 2022 publiceert Microsoft de analyse van een grootschalige campagne. Volgens zijn gegevens probeerde die sinds september 2021 meer dan 10.000 organisaties te treffen6. De aanvallers gebruikten relaissites om wachtwoorden te stelen en de sessie van het slachtoffer te kapen, ook als multifactorauthenticatie was ingeschakeld6.
In een van de waargenomen golven kondigde een e-mail met een HTML-bijlage een voicemailbericht aan. De bijlage toonde een valse downloadbalk en stuurde daarna door naar een relaissite die met Evilginx2 was gebouwd en de inlogpagina van de organisatie overnam6. Het slachtoffer voerde zijn inloggegevens in, werd doorgestuurd naar de echte pagina office.com, en de aanvaller werd intussen namens hem geauthenticeerd6.
Het vervolg was gericht op betalingsfraude. Volgens Microsoft duurde het soms maar vijf minuten tussen de diefstal en het begin van de fraude. De aanvaller gebruikte de gestolen cookie om de online mailbox binnen te gaan, soms met een cookie die al de vermelding van multifactorauthenticatie droeg6. Daarna zocht hij naar gesprekken over betalingen, verwijderde hij de eerste phishingmail en maakte hij een inboxregel die de antwoorden van zijn doelwit archiveerde en als gelezen markeerde, zodat het slachtoffer niets zou merken6. Ten slotte verwijderde hij zijn eigen antwoorden uit de mappen Verzonden items en Verwijderde items6.
Microsoft beveelt phishingbestendige authenticatie aan (FIDO 2.0 of certificaten) en beleid voor voorwaardelijke toegang, dat elke poging om een gestolen cookie te gebruiken beoordeelt6.
5Wat u doet1 min
Deze handelingen komen uit de hier geciteerde bronnen. Ze verkorten de duur of de reikwijdte van een gestolen sessie, maar garanderen niet dat een sessie niet gestolen wordt.
- Log expliciet uit bij diensten als u klaar bent. OWASP geeft aan dat het sluiten van de browser het uitloggen niet betrouwbaar afdwingt en raadt expliciet uitloggen aan, met time-outs aan de serverkant7.
- Trek uw sessies in als er twijfel is (geïnfecteerde werkplek, verdachte inlogpagina). De hier geciteerde bronnen beschrijven de werkwijze niet: de IT-helpdesk van het bedrijf geeft de procedure.
- Sluit de in de browser geopende sessies regelmatig. MITRE raadt aan alle browsersessies regelmatig te sluiten8.
- Controleer het adres voordat u uw wachtwoord invoert: het adres is het enige zichtbare verschil tussen een nepsite als relais en de echte6.
- Meld elke twijfel meteen aan de IT-helpdesk: zolang de sessie actief is, kan de aanvaller ze gebruiken2.
Aan de kant van het bedrijf noemt MITRE het instellen van browsers om persistente cookies regelmatig te verwijderen2.
Fiche
- Identificatie
- CP-048
- Vleugel
- 1. Aanvallen en technieken
- Brain-competentie
- Wachtwoorden beheersen (master_passwords)
- Brain-reflex
- cr-023
- Schema
- G3 · Anatomische doorsnede
- Talen
- de, en, es, fr, it, nl
- Bronnen
- 8 bronnen gecontroleerd op 3 november 2026
Bronnen8 bronnen
- MITRE ATT&CK, “Steal Web Session Cookie”. https://attack.mitre.org/techniques/T1539/ (geraadpleegd op 3 november 2026)
- MITRE ATT&CK, “Use Alternate Authentication Material: Web Session Cookie”. https://attack.mitre.org/techniques/T1550/004/ (geraadpleegd op 3 november 2026)
- OWASP, “Session hijacking attack”. https://community.owasp.org/attacks/Session_hijacking_attack (geraadpleegd op 3 november 2026)
- MITRE ATT&CK, “Steal Application Access Token”. https://attack.mitre.org/techniques/T1528/ (geraadpleegd op 3 november 2026)
- NIST, “NIST Special Publication 800-63B”. https://pages.nist.gov/800-63-3/sp800-63b.html (geraadpleegd op 3 november 2026)
- Microsoft, “From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud”, 12 juli 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (geraadpleegd op 3 november 2026)
- OWASP, “Session Management - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (geraadpleegd op 3 november 2026)
- MITRE ATT&CK, “Browser Session Hijacking”. https://attack.mitre.org/techniques/T1185/ (geraadpleegd op 3 november 2026)
Dit artikel citeren
Brain, “Diefstal van sessiecookies en bearer-tokens”, Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp048_nl_2026,
author = {Brain},
title = {Diefstal van sessiecookies en bearer-tokens},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/nl/articles/diefstal-sessiecookies-bearer-tokens/},
note = {CC BY 4.0}
}