Diebstahl von Sitzungscookies und Bearer-Token
Ein gestohlenes Sitzungscookie genügt, um sich ohne Passwort und zweiten Faktor als Beschäftigter auszugeben. Ablauf, Fall, Reflexe.
In 30 Sekunden
- Wo es passiert
- Auf dem Arbeitsplatzrechner (Schadsoftware), auf einer gefälschten Website, die die echte Anmeldeseite weiterleitet1, oder in einem kompromittierten Browser8.
- Was der Angreifer will
- Eine bereits geöffnete Sitzung übernehmen, Nachrichten lesen und im Namen des Opfers handeln, wobei er manche zweiten Faktoren umgeht2.
- Der Reflex
- Sich von Diensten abmelden, wenn man fertig ist, bei Zweifel die eigenen Sitzungen widerrufen, die Sitzungen des Browsers regelmäßig schließen.
- Wenn es schon passiert ist
- Die IT-Unterstützung sofort informieren, denn die gestohlene Sitzung bleibt nutzbar, solange sie aktiv ist2.
Worum es geht
Wenn sich ein Beschäftigter bei seinem Postfach oder einem Online-Werkzeug anmeldet, übergibt ihm der Dienst ein kleines Erkennungsmerkmal, meist ein Cookie, das belegt, dass er bereits authentifiziert ist. Gelangt ein Angreifer an dieses Merkmal, kann er sich als das Opfer ausgeben, ohne dessen Passwort zu kennen1.
Auf Seiten des Beschäftigten ist in der Regel nichts zu sehen: Die Sitzung läuft weiter, die Arbeit ebenso. Diese Seite erklärt, woher der Diebstahl kommt, was ein Angreifer damit anfängt und was jede und jeder tun kann, um das Risiko zu verringern.
Direkte Fragen
Was ist ein Sitzungscookie?
Nach einer erfolgreichen Anmeldung verwenden viele Webanwendungen ein Sitzungscookie als Authentifizierungsnachweis1. Das Webprotokoll merkt sich von sich aus nicht, wer bei einer Anfrage wer ist: Der Server schickt dem Browser daher ein Token, das der Browser bei jedem weiteren Austausch vorzeigt3.
Was ist ein Zugriffstoken, und wie unterscheidet es sich vom Cookie?
Ein Zugriffstoken dient dazu, autorisierte Anfragen im Namen eines Nutzers oder eines Dienstes zu stellen. Es ist in Online-Anwendungen (SaaS) und Cloud-Diensten verbreitet4. Beide Objekte haben dieselbe Schwäche: Wer eines vorzeigt, wird als die Person akzeptiert, die es erhalten hat. Die NIST SP 800-63B, eine Fassung, die seit dem 1. August 2025 durch die SP 800-63-4 ersetzt ist, hielt zudem fest, dass das Vorliegen eines OAuth-Zugriffstokens ohne weitere Signale nicht als Anwesenheit des Nutzers gedeutet werden darf und dass ein solches Token noch lange nach dem Ende der Authentifizierungssitzung gültig bleiben kann5.
Schützt mich mein zweiter Faktor nicht?
Er schützt die Anmeldung, nicht die darauf folgende Sitzung. MITRE gibt an, dass diese Technik manche Protokolle der Multifaktor-Authentifizierung umgeht, da die Sitzung bereits authentifiziert ist2. Microsoft stellt klar, dass es sich nicht um eine Schwachstelle der Multifaktor-Authentifizierung handelt: Das gestohlene Cookie authentifiziert den Angreifer unabhängig von der Anmeldemethode des Nutzers6.
Wie lange bleibt ein gestohlenes Cookie nutzbar?
Cookies bleiben oft lange gültig, auch wenn die Anwendung nicht aktiv genutzt wird1. Der Angreifer kann es verwenden, solange das Cookie aktiv ist2. Die OWASP weist außerdem darauf hin, dass ein Inaktivitäts-Timeout einen Angreifer nicht begrenzt, der die Sitzung übernommen hat: Er kann Aktivität erzeugen, um sie offen zu halten7.
1In der Haut des Angreifers1 min
Der Angreifer sucht ein wiederverwendbares Element statt eines Geheimnisses, das er erraten müsste. Cookies finden sich auf der Festplatte, im Arbeitsspeicher des Browsers und im Netzwerkverkehr zu entfernten Systemen. Auch andere Anwendungen auf dem Rechner können Authentifizierungscookies im Speicher halten, etwa solche, die sich mit Cloud-Diensten verbinden1.
Hat der Angreifer das Cookie, importiert er es in einen Browser, den er kontrolliert. Dann nutzt er die Website wie der Nutzer, solange die Sitzung aktiv ist. Er kann sensible Informationen einsehen, E-Mails lesen oder alles tun, wozu das Konto des Opfers berechtigt ist2.
Beim Zugriffstoken ist ein beschriebener Weg das Phishing: Der Angreifer registriert eine präparierte Anwendung und schickt einen Link, damit das Opfer ihr Zugriff gewährt. Ist das Token erteilt, kann die Anwendung einen potenziell dauerhaften Zugriff auf das Konto erhalten4. Zugriffstoken haben manchmal eine begrenzte Lebensdauer, doch der Angreifer kann auch ein Aktualisierungstoken stehlen, das ihm neue Zugriffstoken liefert, ohne dass er den Nutzer um etwas bitten muss4.
2Was Sie auf dem Bildschirm sehen1 min
Der Beschäftigte sieht nichts: Auf Seiten der Administratoren kann es Warnungen geben (siehe unten). Bei einer gefälschten Relay-Website (unten beschrieben) gleicht die Seite der echten aufs Haar: Der einzige sichtbare Unterschied ist die Adresse6. Nach der Eingabe des Passworts wird das Opfer auf die legitime Seite umgeleitet, und der Angriff läuft im Hintergrund weiter6.
Hier folgt eine neutralisierte Illustration der Adresse einer gefälschten Relay-Website. Sie ist für das Beispiel erfunden.
Illustration (fiktive Adresse, neutralisiert):
hxxps://login[.]exemple-connexion[.]invalid/
[Seite identisch mit der echten Anmeldeseite, nur die Adresse unterscheidet sich]Es gibt einige indirekte Anzeichen. Meldet sich der Angreifer an, während das Opfer arbeitet, können bei den Administratoren Warnungen wegen „unmöglicher Reise“ erscheinen6. Unbekannte Posteingangsregeln sind ein weiteres Anzeichen: In dem unten beschriebenen Fall hat der Angreifer eine angelegt, damit das Opfer die Antworten seines Ziels nicht sieht6.
3Unter der HaubeIT-Teams2 min
Die hier zitierten Quellen beschreiben drei Wege des Diebstahls.
- Die Stealer-Schadsoftware: Schadprogramme zielen auf die Cookies der Browser auf dem Rechner1. Manche lesen das Sitzungscookie aus und schicken es an den Server des Angreifers1.
- Die gefälschte Relay-Website: Beim sogenannten Angriff durch einen Mittelsmann (Adversary-in-the-Middle) setzt der Angreifer einen Proxyserver zwischen den Nutzer und die anvisierte Website. So fängt er das Passwort und das Sitzungscookie ab6. Freie Werkzeuge wie Evilginx2, Modlishka und Muraena automatisieren dieses Vorgehen6.
- Der kompromittierte Browser: Ein Angreifer kann Software in einen Browser einschleusen, um die Cookies, HTTP-Sitzungen und Clientzertifikate des Nutzers zu erben und damit in ein authentifiziertes Intranet zu gelangen8. Diese Technik kann auch die Zwei-Faktor-Authentifizierung umgehen8. Sie kann besondere Rechte auf dem Rechner erfordern8.
Warum funktioniert die Wiederverwendung? Das Cookie ist der Nachweis der Anmeldung: Der Server prüft das Passwort nicht bei jeder Seite erneut6. Die NIST SP 800-63B lässt andere Methoden zur sicheren Identifizierung des Geräts zu, darunter gegenseitiges TLS und Token Binding5. Die OWASP empfiehlt, die Sitzungskennung an andere Eigenschaften des Clients zu binden, etwa die IP-Adresse oder den User-Agent. Sie räumt jedoch ein, dass ein geschickter Angreifer diese Kontrolle umgehen kann, zum Beispiel indem er dasselbe Netzwerk wie das Opfer nutzt oder den User-Agent kopiert7.
Zu den Zeitspannen nennt die OWASP übliche Inaktivitäts-Timeouts von 2 bis 5 Minuten für Anwendungen mit hohem Wert und von 15 bis 30 Minuten für Anwendungen mit geringem Risiko. Für einen Büroangestellten, der eine Anwendung den ganzen Tag nutzt, nennt sie ein absolutes Timeout von 4 bis 8 Stunden7. Die NIST SP 800-63B, seit dem 1. August 2025 durch die SP 800-63-4 ersetzt, verlangte, dass Sitzungsgeheimnisse bei der Abmeldung gelöscht oder ungültig gemacht werden5.
4FallanalysenReale Fälle2 min
Phishing-Kampagne über gefälschte Relay-Websites gegen Microsoft 365 (dokumentiert am 12. Juli 2022)
Am 12. Juli 2022 veröffentlicht Microsoft die Analyse einer groß angelegten Kampagne. Nach seinen Daten versuchte sie seit September 2021, mehr als 10 000 Organisationen ins Visier zu nehmen6. Die Angreifer nutzten Relay-Websites, um Passwörter zu stehlen und die Sitzung des Opfers zu kapern, auch wenn die Multifaktor-Authentifizierung aktiviert war6.
In einer der beobachteten Wellen kündigte eine E-Mail mit HTML-Anhang eine Sprachnachricht an. Der Anhang zeigte eine gefälschte Download-Leiste und leitete dann auf eine mit Evilginx2 gebaute Relay-Website um, die die Anmeldeseite der Organisation nachbildete6. Das Opfer gab seine Zugangsdaten ein, wurde auf die legitime Seite office.com umgeleitet, und der Angreifer war in seinem Namen authentifiziert6.
Der weitere Verlauf zielte auf Zahlungsbetrug. Laut Microsoft vergingen zwischen Diebstahl und Beginn des Betrugs manchmal nur fünf Minuten. Der Angreifer nutzte das gestohlene Cookie, um in das Online-Postfach zu gelangen, teils mit einem Cookie, das bereits den Vermerk der Multifaktor-Authentifizierung trug6. Danach suchte er nach Austauschen zu Zahlungen, löschte die ursprüngliche Phishing-Mail und legte eine Posteingangsregel an, die die Antworten seines Ziels archivierte und als gelesen markierte, damit das Opfer nichts bemerkte6. Schließlich löschte er seine eigenen Antworten aus den Ordnern für gesendete und gelöschte Elemente6.
Microsoft empfiehlt phishingresistente Authentifizierung (FIDO 2.0 oder Zertifikate) und Richtlinien für bedingten Zugriff, die jeden Versuch bewerten, ein gestohlenes Cookie zu verwenden6.
5Was Sie tun1 min
Diese Maßnahmen stammen aus den hier zitierten Quellen. Sie verkürzen die Dauer oder verringern die Reichweite einer gestohlenen Sitzung, garantieren aber nicht, dass keine gestohlen wird.
- Sich ausdrücklich von Diensten abmelden, wenn man fertig ist. Die OWASP gibt an, dass das Schließen des Browsers die Abmeldung nicht zuverlässig erzwingt, und empfiehlt eine ausdrückliche Abmeldung mit Timeouts auf Serverseite7.
- Die eigenen Sitzungen widerrufen, wenn ein Zweifel aufkommt (infizierter Rechner, verdächtige Anmeldeseite). Die hier zitierten Quellen beschreiben das Vorgehen nicht im Einzelnen: Die IT-Unterstützung des Unternehmens nennt das Verfahren.
- Die im Browser geöffneten Sitzungen regelmäßig schließen. MITRE empfiehlt, alle Browsersitzungen regelmäßig zu schließen8.
- Die Adresse prüfen, bevor man sein Passwort eingibt: Die Adresse ist der einzige sichtbare Unterschied zwischen einer gefälschten Relay-Website und der echten6.
- Jeden Zweifel sofort der IT-Unterstützung melden: Solange die Sitzung aktiv ist, kann der Angreifer sie nutzen2.
Auf Unternehmensseite nennt MITRE die Konfiguration der Browser, damit persistente Cookies regelmäßig gelöscht werden2.
Merkblatt
- Kennung
- CP-048
- Flügel
- 1. Angriffe und Techniken
- Brain-Kompetenz
- Passwörter beherrschen (master_passwords)
- Brain-Reflex
- cr-023
- Schema
- G3 · Anatomischer Schnitt
- Sprachen
- de, en, fr
- Quellen
- 8 Quellen geprüft am 3. November 2026
Quellen8 Quellen
- MITRE ATT&CK, „Steal Web Session Cookie“. https://attack.mitre.org/techniques/T1539/ (abgerufen am 3. November 2026)
- MITRE ATT&CK, „Use Alternate Authentication Material: Web Session Cookie“. https://attack.mitre.org/techniques/T1550/004/ (abgerufen am 3. November 2026)
- OWASP, „Session hijacking attack“. https://community.owasp.org/attacks/Session_hijacking_attack (abgerufen am 3. November 2026)
- MITRE ATT&CK, „Steal Application Access Token“. https://attack.mitre.org/techniques/T1528/ (abgerufen am 3. November 2026)
- NIST, „NIST Special Publication 800-63B“. https://pages.nist.gov/800-63-3/sp800-63b.html (abgerufen am 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/ (abgerufen am 3. November 2026)
- OWASP, „Session Management - OWASP Cheat Sheet Series“. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (abgerufen am 3. November 2026)
- MITRE ATT&CK, „Browser Session Hijacking“. https://attack.mitre.org/techniques/T1185/ (abgerufen am 3. November 2026)
Diesen Artikel zitieren
Brain, „Diebstahl von Sitzungscookies und Bearer-Token“, Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp048_de_2026,
author = {Brain},
title = {Diebstahl von Sitzungscookies und Bearer-Token},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/},
note = {CC BY 4.0}
}