Session-Hijacking: Warum ein gestohlener Cookie mehr wert ist als ein Passwort
Ein gestohlenes Passwort muss zunächst das Login-Formular überstehen: Liegt hinter dem Konto eine Multi-Faktor-Authentifizierung, hält die Tür in der Regel. Ein gestohlener Session-Cookie ist etwas anderes — er wird erst ausgestellt, nachdem ein Login bereits erfolgreich war, und alles, was das Konto danach tut, authentifiziert der Cookie allein. Diese Asymmetrie erklärt, warum der Diebstahl von Sessions still und leise zum bevorzugten Weg in geschützte Konten geworden ist.
Die Mechanik ist einfach: Bei der Anmeldung übergibt der Server dem Browser einen Session-Cookie, und von diesem Moment an authentifiziert der Cookie allein jede weitere Anfrage. Der MITRE-Eintrag zur Technik T1539, Steal Web Session Cookie, hält fest, dass diese Cookies „auf der Festplatte, im Prozessspeicher des Browsers und im Netzwerkverkehr“ liegen können und dass ihr Besitzer die Anwendung „als authentifizierter Nutzer ganz ohne Zugangsdaten“ nutzen kann. Die zugehörige Technik für die Wiederverwendung, T1550.004, vermerkt, dass eine wiedergespielte Session „manche Multi-Faktor-Authentifizierungsverfahren aushebelt, da die Session bereits authentifiziert ist“, und dass Cookies „oft über einen längeren Zeitraum gültig“ bleiben.Warum ein Cookie mehr wert ist als ein Passwort
Drei Eigenschaften machen den Cookie wertvoller als die Zugangsdaten, die er ersetzt hat. Er ist bereits hinter der MFA-Mauer, weil der legitime Nutzer den zweiten Faktor präsentiert hat, als die Session entstand. Seine Verwendung erzeugt kein Rauschen fehlgeschlagener Logins — der Angreifer kommt als normaler, authentifizierter Browser daher. Und ein Passwortwechsel beendet die Session nicht zwangsläufig. Die Erkennung stützt sich deshalb auf Verhalten statt auf die Anfrage selbst: MITRE nennt Cookie-Wiederverwendung „aus ungewöhnlichen User Agents oder von ungewöhnlichen Standorten“ sowie „Impossible-Travel-Szenarien und auffälliges Verhalten“. Staatliche Akteure arbeiten an derselben Naht. MITRE dokumentiert, wie APT29 während der SolarWinds-Kompromittierung Chrome-Cookies stahl, indem es Browserprofil-Verzeichnisse komplett kopierte, und später einen gefälschten duo-sid-Cookie zur Umgehung der MFA nutzte; Star Blizzard gelangte über durch einen Evilginx-artigen Proxy eingesammelte Session-Cookies an Opfer-Postfächer. Kein davon erforderte, eine Verschlüsselung zu brechen oder einen Faktor zu knacken — nur eine Kopie von etwas, das der Browser längst besitzt.AiTM-Kits tunneln die Login-Mauer
Die industrielle Variante ist das Adversary-in-the-Middle-Kit. Eine gefälschte Login-Seite, die nur Passwörter erntet, scheitert am zweiten Faktor. Eine AiTM-Seite dagegen proxyt den echten Login: Das Opfer authentifiziert sich regulär über das Relay des Angreifers, der Code wird eingegeben, und das Kit sammelt den Session-Cookie ein, der am Ende des Vorgangs ausgestellt wird. Microsoft dokumentierte eine solche Kampagne im Juli 2022, aufgebaut um Office-Dokument- und Sprachnachrichten-Köder, die laut Unternehmen seit September 2021 rund 10.000 Organisationen getroffen hatte — eine Kampagne, die darauf ausgelegt war, in Microsofts Worten, „Passwörter zu stehlen, angemeldete Sessions zu entführen (Session-Cookies zu stehlen) und die MFA zu umgehen“. Das Modell läuft heute als Abo. Im September 2026 berichtete BleepingComputer über BigBear 2.0, ein auf Evilginx2 basierendes Phishing-as-a-Service-Framework, mit dem die MFA bei 258 Organisationen umgangen wurde. Ein dort zitierter CloudSEK-Bericht bezifferte das Betreiber-Panel auf 5.137 Datensätze mit Zugangsdaten — darunter 474 vollständige Authentifizierungen mit umgehener MFA, 1.032 Klartext-Passwörter und 4.148 Session-Cookies — verknüpft mit 3.331 eindeutigen Opfer-IP-Adressen aus mehr als 40 Ländern. Die Wiedergaben laufen über Residential-Proxies, die zum jeweiligen Opferland passen, und das eingebrachte JavaScript des Kits stört FIDO2/WebAuthn-Prompts, um Opfer zu schwächeren Faktoren zu lenken.Stealer-Logs sind Cookie-Inventare
Die leisere Pipeline ist Infostealer-Malware, und ihr Markt hat sichtlich gedreht. BleepingComputers Bericht vom April 2026 über einen als Storm vermarkteten Stealer beschreibt ein Miet-Panel — 300 Dollar für eine Sieben-Tage-Demo, bis zu 1.800 Dollar im Monat für eine Team-Stufe — dessen Kernstück kein Passwort-Dump ist, sondern ein Cookie-Restoration-Dashboard, das authentifizierte Sessions serverseitig wiederherstellt:Füttere das Panel mit einem Google-Refresh-Token und einem geografisch passenden SOCKS5-Proxy, und es stellt die authentifizierte Session des Opfers still wieder her.Die Forscher hinter dem Bericht stellten fest, dass der Diebstahl von Session-Cookies den Passwortdiebstahl als wichtigstes Ziel der Stealer-Entwicklung abgelöst hat. Das verschiebt, was ein Stealer-Log ist: weniger eine Liste zu testender Zugänge als ein Inventar bereits offener Türen, von denen jede gilt, bis die Session abläuft.
Was das Risiko tatsächlich senkt
Die Gegenmaßnahmen sind unspektakulär — ein Grund, warum sie so oft übersprungen werden. Sie decken sich weitgehend mit dem, was Microsoft und MITRE seit den ersten AiTM-Wellen empfehlen:- Session-Lebenszeiten verkürzen und persistente Cookies regelmäßig löschen — die MITRE-Mitigation sagt exakt das. Langlebige „Angemeldet bleiben“-Sessions sind der Rohstoff dieses Handels.
- Sessions an Geräte- oder Netzwerkkontext binden: Conditional-Access-Regeln, die ein verwaltetes Gerät verlangen, lassen eine nackte Cookie-Wiedergabe scheitern, selbst wenn der Cookie echt ist.
- Die Wiedergabe erkennen: Impossible-Travel-Prüfungen und Alarme bei Session-Anomalien erwischen die meisten Cookie-Wiederverwendungen.
- Sensible Konten auf phishing-resistente Authentifizierung umstellen. Hardwaregebundene Passkeys (FIDO2/WebAuthn) sind an die aufgerufene Domain gebunden, ein AiTM-Proxy kann sie nicht weiterleiten — genau deshalb versuchen Kits wie BigBear, diese Prompts zu unterdrücken.
- Ausloggen. Eine Session serverseitig zu beenden, macht den Cookie ungültig; das Schließen des Tabs tut es nicht.