--- id: CP-048 slug: diebstahl-sitzungscookies-bearer-token lang: de title: Diebstahl von Sitzungscookies und Bearer-Token description: Ein gestohlenes Sitzungscookie genügt, um sich ohne Passwort und zweiten Faktor als Beschäftigter auszugeben. Ablauf, Fall, Reflexe. canonical_url: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ markdown_url: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, „Diebstahl von Sitzungscookies und Bearer-Token“, Cyberpedia, 2026. https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ (CC BY 4.0) wing: 1 theme: master_passwords reflex: cr-023 schema: G3 updated: "2026-11-03" translations: de: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ fr: https://startbrain.io/cyberpedia/fr/articles/vol-cookies-session-jetons-porteurs/ en: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ es: https://startbrain.io/cyberpedia/es/articles/robo-cookies-sesion-tokens-portador/ sources: - "n": 1 title: Steal Web Session Cookie publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 2 title: "Use Alternate Authentication Material: Web Session Cookie" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/004/ accessed: "2026-11-03" - "n": 3 title: Session hijacking attack publisher: OWASP url: https://community.owasp.org/attacks/Session_hijacking_attack accessed: "2026-11-03" - "n": 4 title: Steal Application Access Token publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 5 title: NIST Special Publication 800-63B publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63b.html accessed: "2026-11-03" - "n": 6 title: "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud" publisher: Microsoft url: 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/ published: "2022-07-12" accessed: "2026-11-03" - "n": 7 title: Session Management - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: Browser Session Hijacking publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1185/ accessed: "2026-11-03" --- # Diebstahl von Sitzungscookies und Bearer-Token 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 kennen [1]. 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. ## In 30 Sekunden - Wo es passiert: auf dem Arbeitsplatzrechner (Schadsoftware), auf einer gefälschten Website, die die echte Anmeldeseite weiterleitet [1], oder in einem kompromittierten Browser [8]. - Was der Angreifer will: eine bereits geöffnete Sitzung übernehmen, Nachrichten lesen und im Namen des Opfers handeln, wobei er manche zweiten Faktoren umgeht [2]. - 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 ist [2]. ## Direkte Fragen ### Was ist ein Sitzungscookie? Nach einer erfolgreichen Anmeldung verwenden viele Webanwendungen ein Sitzungscookie als Authentifizierungsnachweis [1]. 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 vorzeigt [3]. ### 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 verbreitet [4]. 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 kann [5]. ### 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 ist [2]. 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 Nutzers [6]. ### Wie lange bleibt ein gestohlenes Cookie nutzbar? Cookies bleiben oft lange gültig, auch wenn die Anwendung nicht aktiv genutzt wird [1]. Der Angreifer kann es verwenden, solange das Cookie aktiv ist [2]. 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 halten [7]. ## In der Haut des Angreifers 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 verbinden [1]. 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 ist [2]. 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 erhalten [4]. 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 muss [4]. ## Was Sie auf dem Bildschirm sehen 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 Adresse [6]. Nach der Eingabe des Passworts wird das Opfer auf die legitime Seite umgeleitet, und der Angriff läuft im Hintergrund weiter [6]. Hier folgt eine neutralisierte Illustration der Adresse einer gefälschten Relay-Website. Sie ist für das Beispiel erfunden. ```text 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“ erscheinen [6]. Unbekannte Posteingangsregeln sind ein weiteres Anzeichen: In dem unten beschriebenen Fall hat der Angreifer eine angelegt, damit das Opfer die Antworten seines Ziels nicht sieht [6]. ## Unter der Haube Die hier zitierten Quellen beschreiben drei Wege des Diebstahls. - Die Stealer-Schadsoftware: Schadprogramme zielen auf die Cookies der Browser auf dem Rechner [1]. Manche lesen das Sitzungscookie aus und schicken es an den Server des Angreifers [1]. - 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 ab [6]. Freie Werkzeuge wie Evilginx2, Modlishka und Muraena automatisieren dieses Vorgehen [6]. - 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 gelangen [8]. Diese Technik kann auch die Zwei-Faktor-Authentifizierung umgehen [8]. Sie kann besondere Rechte auf dem Rechner erfordern [8]. Warum funktioniert die Wiederverwendung? Das Cookie ist der Nachweis der Anmeldung: Der Server prüft das Passwort nicht bei jeder Seite erneut [6]. Die NIST SP 800-63B lässt andere Methoden zur sicheren Identifizierung des Geräts zu, darunter gegenseitiges TLS und Token Binding [5]. 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 kopiert [7]. 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 Stunden [7]. 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 werden [5]. ## Fallanalysen ### 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 nehmen [6]. Die Angreifer nutzten Relay-Websites, um Passwörter zu stehlen und die Sitzung des Opfers zu kapern, auch wenn die Multifaktor-Authentifizierung aktiviert war [6]. 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 nachbildete [6]. Das Opfer gab seine Zugangsdaten ein, wurde auf die legitime Seite office.com umgeleitet, und der Angreifer war in seinem Namen authentifiziert [6]. 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 trug [6]. 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 bemerkte [6]. Schließlich löschte er seine eigenen Antworten aus den Ordnern für gesendete und gelöschte Elemente [6]. Microsoft empfiehlt phishingresistente Authentifizierung (FIDO 2.0 oder Zertifikate) und Richtlinien für bedingten Zugriff, die jeden Versuch bewerten, ein gestohlenes Cookie zu verwenden [6]. ## Was Sie tun 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 Serverseite [7]. - 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ßen [8]. - Die Adresse prüfen, bevor man sein Passwort eingibt: Die Adresse ist der einzige sichtbare Unterschied zwischen einer gefälschten Relay-Website und der echten [6]. - Jeden Zweifel sofort der IT-Unterstützung melden: Solange die Sitzung aktiv ist, kann der Angreifer sie nutzen [2]. Auf Unternehmensseite nennt MITRE die Konfiguration der Browser, damit persistente Cookies regelmäßig gelöscht werden [2]. ## Quellen 1. MITRE ATT&CK, „Steal Web Session Cookie“. https://attack.mitre.org/techniques/T1539/ (abgerufen am 3. November 2026) 2. MITRE ATT&CK, „Use Alternate Authentication Material: Web Session Cookie“. https://attack.mitre.org/techniques/T1550/004/ (abgerufen am 3. November 2026) 3. OWASP, „Session hijacking attack“. https://community.owasp.org/attacks/Session_hijacking_attack (abgerufen am 3. November 2026) 4. MITRE ATT&CK, „Steal Application Access Token“. https://attack.mitre.org/techniques/T1528/ (abgerufen am 3. November 2026) 5. NIST, „NIST Special Publication 800-63B“. https://pages.nist.gov/800-63-3/sp800-63b.html (abgerufen am 3. November 2026) 6. 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) 7. OWASP, „Session Management - OWASP Cheat Sheet Series“. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (abgerufen am 3. November 2026) 8. MITRE ATT&CK, „Browser Session Hijacking“. https://attack.mitre.org/techniques/T1185/ (abgerufen am 3. November 2026) --- Originalquelle: Cyberpedia, die öffentliche Enzyklopädie zu Cybersicherheit und KI von Brain. Kanonische Version: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ Sie dürfen diesen Text unter der Lizenz CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) frei weiterverwenden, sofern Sie „Brain, Cyberpedia“ mit einem Link auf die obige Adresse nennen.