Pass-the-Cookie: Forensik im Schatten gestohlener Sessions
07.07.2026 session-hijackinginfostealeraitm-phishingtoken-theft
Ein Nutzer meldet eine verdächtige E-Mail, das Sandbox-Ergebnis ist unauffällig, die URL bereits tot – Fall geschlossen, könnte man meinen. Genau dieses Muster führte 2026 in einem realen Vorfall dazu, dass Analysten drei Stunden zu spät bemerkten, dass die Kompromittierung bereits als replayed Session-Token und ein vom Angreifer angelegter OAuth-Grant in der Identitätsebene aktiv war, drei Stunden bevor das Playbook aufholte. Session-Hijacking – oder “Pass-the-Cookie” – hat sich zum dominanten Einstiegsvektor entwickelt und stellt die DFIR-Praxis vor ein grundlegendes Problem: Der klassische Tatort, der Authentifizierungsvorgang, existiert forensisch oft gar nicht mehr.
Warum MFA hier ins Leere läuft
Moderne Webanwendungen verwalten authentifizierte Zustände über Bearer-Token – Session-Cookies, OAuth-Access-Tokens oder Refresh-Tokens. Ein Bearer-Token beweist Besitz, nicht Identität, weshalb die Anwendung ihn von jedem Gerät oder Browser akzeptiert, das ihn vorweist. Genau das erklärt, warum MFA erfolgreich sein kann und der Angreifer trotzdem als das Opfer agiert. Zwei Wege führen zum gestohlenen Token: Adversary-in-the-Middle-Phishing-Kits wie Tycoon2FA proxen die echte Login-Seite und fangen den Session-Artefakt nach abgeschlossener MFA ab, während Infostealer einen anderen Weg nehmen, direkte lokale Extraktion, das Ergebnis ist jedoch identisch: eine gültige, authentifizierte Session, die an einen Angreifer übergeht, der die Login-Seite nie berührt hat.
Das Ausmaß ist beträchtlich: Laut aktuellen Auswertungen verarbeiteten Infostealer 51,7 Millionen Pakete im Jahr 2025, ein Anstieg von 72 Prozent gegenüber dem Vorjahr, und diese Pakete sind besonders gefährlich, weil sie lebende Session-Cookies enthalten, die es Angreifern erlauben, MFA vollständig zu umgehen. Cybercheck-Analysten dokumentierten dabei, dass die Cookie-Ordner innerhalb eines einzigen Logs aktive Session-Credentials für Dutzende Dienste gleichzeitig enthalten können, darunter Google, Microsoft und Finanzplattformen, alle in Minuten von einem infizierten Gerät extrahiert.
Was am Tatort forensisch noch greifbar ist
Der entscheidende Unterschied zu klassischer Credential-Kompromittierung: MFA ist eine Kontrolle auf das Authentifizierungsereignis bezogen, den Moment, in dem ein Nutzer seine Identität beweist. Sobald die Authentifizierung erfolgreich ist, wird das Session-Token ausgestellt, und MFA hat seine Aufgabe erfüllt. Es spielt für die Session selbst keine weitere Rolle. Ein Angreifer mit gestohlenem Session-Token löst nie das Authentifizierungsereignis aus. Für Forensiker bedeutet das: Sign-in-Logs zeigen scheinbar legitime, MFA-konforme Anmeldungen – der eigentliche Kompromittierungsindikator liegt woanders. Praktiker berichten, dass sich die Erkennung zwangsläufig verlagert: die Detektion muss in Sign-in-Logs, Conditional-Access-Telemetrie und OAuth-Grant-Analyse stattfinden, weil der Verräter der Kontext rund um die Anmeldung ist, und das der einzige Ort ist, an dem der Angriff Spuren hinterlässt.
Hinzu kommt ein Zeitfenster-Problem: Alle relevanten Logs müssen vor Ablauf der 30- bis 90-tägigen Aufbewahrungsfenster in ein SIEM exportiert werden, weil die Beweiskette bei der Rotation verschwindet. Bei BEC-artigen Folgeaktionen kommen weitere Artefakte hinzu, die Ermittler nicht übersehen dürfen: Angreifer legen Postfachregeln an, um Warnungen zu verbergen oder Finanz-E-Mails automatisch weiterzuleiten – Mailbox-Konfigurationen sollten auf versteckte Weiterleitungsregeln geprüft, bösartige OAuth-App-Berechtigungen kontrolliert und Zugriffsprotokolle auf Massen-Downloads aus SharePoint oder Drive untersucht werden.
Reaktion, Beweissicherung und Grenzen der Gegenmaßnahmen
Sobald ein Verdacht erhärtet ist, zählt Geschwindigkeit: der Zugriff des Angreifers muss sofort gekappt werden, etwa durch den Befehl “Revoke All Sessions”, um jeden aktiven Token ungültig zu machen; unmittelbar danach müssen Passwort sowie MFA-Einstellungen zurückgesetzt werden, um sicherzustellen, dass der Angreifer kein Backup-Gerät zur Persistenz registriert hat. Parallel gilt es, Beweise zu sichern: relevante Sign-in-Logs, Audit-Trails und Mailbox-Regelkonfigurationen müssen gesichert werden, da sie für forensische Analyse und mögliche rechtliche Verfahren entscheidend sind.
Technische Gegenmaßnahmen wie Googles Device Bound Session Credentials (DBSC) versprechen Besserung, greifen aber nur begrenzt: Sie machen gestohlene Cookies auf verwalteten, modernen Geräten unbrauchbar, doch Organisationen, die im vergangenen Jahr Opfer von Ransomware wurden, weil Zugangsdaten in Stealer-Logs auftauchten, wären in den meisten Fällen durch DBSC nicht geschützt gewesen – ihre Zugangsdaten wurden von privaten Geräten, Auftragnehmer-Laptops und unverwalteten Endpunkten abgegriffen, nicht von verwalteten Chrome-Browsern unter Windows 11 mit TPM 2.0. Für DFIR-Teams bleibt die Konsequenz: Session-Governance, kontinuierliches Token-Monitoring und die Bereitschaft, Identitätslogs als primäre Beweisquelle zu behandeln, sind heute wichtiger als die Analyse des ursprünglichen Phishing-Links.
← Zurück zur Übersicht