Verhindern Sie Session-Hijacking mit Identity Intelligence

Sitzungs-Cookies werden über zwei unterschiedliche Angriffspfade gestohlen, die zum gleichen Ergebnis führen. Beim „Infostealer“-Pfad infiziert Malware das Gerät eines Nutzers und extrahiert alle im Browser gespeicherten Sitzungs-Cookies aller Anwendungen, bei denen der Nutzer angemeldet war. Es ist keine Interaktion erforderlich – der Diebstahl erfolgt unbemerkt, der Nutzer hat keinen Hinweis darauf, dass er stattgefunden hat, und die gestohlenen Cookies zirkulieren bereits innerhalb weniger Stunden auf kriminellen Märkten. Beim „Adversary-in-the-Middle“-Phishing-Angriff (AiTM) kommt keine Malware zum Einsatz. Der Angreifer betreibt einen Phishing-Proxy, der sich zwischen den Nutzer und die legitime Anmeldeseite schaltet und die Authentifizierung in Echtzeit weiterleitet. Aus Sicht des Nutzers wird die MFA erfolgreich abgeschlossen. Wenn der legitime Server das Sitzungs-Cookie zurücksendet, fängt der Proxy des Angreifers es ab, bevor es den Browser des Nutzers erreicht. In beiden Fällen verfügt der Angreifer am Ende über ein gültiges, bereits authentifiziertes Sitzungs-Cookie. Er hat weder ein Passwort noch einen MFA-Code in die Hände bekommen. Er spielt das Cookie in einem Anti-Detect-Browser ab, der den Fingerabdruck des vertrauenswürdigen Geräts des Opfers nachahmt, und die Anwendung erkennt eine legitime, authentifizierte Sitzung. Im Jahr 2025 hat SpyCloud 8,6 Milliarden gestohlene Sitzungs-Cookies aus kriminellen Quellen zurückgewonnen. Sowohl MFA als auch Passkeys verhindern unbefugte Anmeldungen – aber keine der beiden Methoden kontrolliert, was mit den durch eine erfolgreiche Anmeldung erzeugten Authentifizierungsdaten geschieht.

Das Widerrufen des Sitzungs-Cookies unterbricht den Zugriff in diesem Moment, doch in den meisten Unternehmens- und Verbraucheranwendungsumgebungen wurde zudem ein zweites Element gestohlen: das Aktualisierungstoken. Ein Aktualisierungstoken ist eine langfristig gültige Berechtigung, die ein Identitätsanbieter verwendet, um im Hintergrund neue Sitzungs-Cookies auszustellen, ohne dass sich der Benutzer erneut authentifizieren muss. In Unternehmensumgebungen mit Microsoft Entra ID oder Okta bleiben Aktualisierungstoken standardmäßig in der Regel 90 Tage lang gültig. Ein Angreifer, der im Besitz eines gestohlenen Refresh-Tokens ist, kann monatelang im Hintergrund neue Sitzungs-Cookies generieren – selbst nachdem das ursprüngliche Cookie widerrufen wurde und selbst nachdem der Benutzer sein Passwort zurückgesetzt hat. In den meisten Standardkonfigurationen führen Passwortzurücksetzungen nicht zur Ungültigmachung von Refresh-Tokens. Der Angreifer wird einfach jedes Mal neu authentifiziert, wenn seine aktuelle Sitzung abläuft – ohne Anmeldevorgang, ohne MFA-Aufforderung und ohne Verhaltenssignal. Eine vollständige Behebung einer kompromittierten Sitzung erfordert die Sperrung sowohl des Sitzungs-Cookies als auch des Refresh-Tokens. In SSO-Umgebungen ist zudem die Beendigung der Sitzung auf IdP-Ebene erforderlich – da diese Sitzung den Zugriff auf alle nachgelagerten Anwendungen in der SSO-Instanz weitergibt. SpyCloud erkennt die Exfiltration sowohl von Sitzungs-Cookies als auch von Refresh-Tokens aus kriminellen Quellen und liefert damit das Signal, das Sicherheitsteams benötigen, um die richtigen und vollständigen Abhilfemaßnahmen einzuleiten.

Nein. Passkeys und die passwortlose Authentifizierung machen das Passwort als potenziell gestohlenes Element überflüssig, wodurch eine Angriffsfläche beseitigt wird. Doch nach jedem erfolgreichen Authentifizierungsvorgang – unabhängig davon, ob sich der Benutzer mit einem Passwort, einem Passkey, biometrischen Daten oder einem Hardware-Schlüssel authentifiziert hat – stellt die Anwendung weiterhin ein Sitzungs-Cookie und in OAuth/OIDC- sowie SSO-Umgebungen ein Aktualisierungstoken aus. AitM-Phishing-Angriffe zielen speziell darauf ab, diese nach der Authentifizierung generierten Elemente zu stehlen. Der Angreifer leitet den Authentifizierungsvorgang über einen Proxy weiter, lässt ihn normal ablaufen und fängt das Sitzungs-Cookie und das Aktualisierungstoken beim Verlassen ab. Der Nutzer hat sich erfolgreich mit seinem Passkey authentifiziert. Der Angreifer verfügt nun über das Ergebnis dieser Authentifizierung. Passwortlose Umgebungen weisen dieselbe Anfälligkeit auf der Sitzungsebene auf wie passwortbasierte – die Angriffsfläche verlagert sich lediglich vom Diebstahl von Anmeldedaten zum Diebstahl von Token. Für Unternehmen, die auf eine passwortlose oder passkey-basierte Authentifizierung umstellen, ist die Transparenz auf der Sitzungsebene während der Übergangsphase umso wichtiger, da das falsche Sicherheitsgefühl durch den Verzicht auf Passwörter dazu führen kann, dass die nach der Authentifizierung weiterhin vollständig exponierte Angriffsfläche weniger beachtet wird.

SpyCloud arbeitet mit drei Abhilfemaßnahmen, die je nach Umgebung und den erkannten Artefakten in der Reihenfolge ihrer Priorität angewendet werden. Oberste Priorität hat die Sperrung von Refresh-Tokens. Refresh-Tokens sind der Hauptschlüssel – sie sind bis zu 90 Tage gültig und bleiben auch nach einer Passwortzurücksetzung bestehen. SpyCloud konzentriert sich zuerst darauf und weist den Identitätsanbieter automatisch an, das Token zu sperren, sobald die Kompromittierung bestätigt ist. Die zweite Ebene ist die Beendigung der IdP-SSO-Sitzung. In Unternehmensumgebungen, die über Okta, Entra ID oder Ping Identity vernetzt sind, weist SpyCloud den Identitätsanbieter an, die Sitzung auf IdP-Ebene zu beenden, was sich automatisch auf alle nachgelagerten Anwendungen in dieser SSO-Instanz auswirkt. Die dritte Ebene ist die Ungültigmachung von Sitzungs-Cookies auf Anwendungsebene. Einzelne Anwendungen verwalten ihre eigenen Sitzungs-Cookies, und der Identitätsanbieter kann nicht immer direkt eingreifen, um diese zu widerrufen. SpyCloud löst dies durch eine erzwungene erneute Authentifizierung – beim nächsten Versuch des Angreifers, das gestohlene Cookie zu verwenden, stößt er auf eine Anmeldebarriere. Für Verbraucheranwendungen gilt dasselbe Prinzip: SpyCloud übermittelt den kompromittierten Cookie-Datensatz über eine API, sodass die Anwendung die Sitzung ungültig machen und den Nutzer zur erneuten Authentifizierung auffordern kann. Die Sperrung des Refresh-Tokens und der SSO-Sitzung erfolgt sofort und automatisch. Sitzungen auf Anwendungsebene werden beim nächsten Zugriffsversuch unterbrochen.

Herkömmliche Tools zur Sitzungsverwaltung und Betrugserkennung arbeiten mit Verhaltenssignalen – sie suchen nach anomalen Zugriffsmustern, ungewöhnlichen Geräteeigenschaften oder verdächtigen Transaktionsabläufen, nachdem die Authentifizierung bereits erfolgreich war. SpyCloud greift bereits vor dem eigentlichen Verhalten ein. Es erfasst gestohlene Sitzungs-Cookies, Aktualisierungstoken und Authentifizierungsartefakte direkt aus kriminellen Quellen – aus den Protokollen von Infostealer-Malware, den Ergebnissen von AiTM-Phishing-Operationen und auf Schwarzmärkten, auf denen gestohlene Anmeldedaten und Sitzungsdaten verbreitet werden. Diese Daten erreichen SpyCloud in der Regel innerhalb weniger Stunden nach dem ursprünglichen Diebstahl, noch bevor Angreifer die Gelegenheit hatten, sie zu nutzen. Die Zeitspanne zwischen dem Diebstahl eines Cookies und seinem ersten Auftauchen auf kriminellen Märkten ist das Zeitfenster, in dem SpyCloud die Gefährdung aufdecken und Abhilfemaßnahmen ermöglichen kann. Bei Verbraucheranwendungen kann der kontinuierlich aktualisierte Feed von SpyCloud mit kompromittierten Sitzungs-Cookies anhand von Anwendungsdomänen abgefragt werden, sodass Sicherheits- und Betrugsbekämpfungsteams kompromittierte Sitzungen fortlaufend identifizieren und ungültig machen können. Bei Unternehmensanwendungen lässt sich SpyCloud in Entra ID Guardian, Okta Workforce Guardian und Active Directory Guardian integrieren, um eine automatische Sitzungsbeendigung auszulösen, sobald eine Übereinstimmung in den wiedergewonnenen kriminellen Daten erkannt wird. Dadurch wird das Zeitfenster zwischen Diebstahl und Abhilfe auf wenige Minuten verkürzt.