Okta Session Hijacking: gestohlene Sitzungscookies finden
Session Hijacking im Okta System Log erkennen: eine externalSessionId aus mehreren ASNs oder Browsern, Roaming und das Ausschließen von VPN und Mobilfunk.
TL;DR. Mit einem gestohlenen Okta-Sitzungscookie überspringt der Angreifer Passwort und MFA vollständig, es gibt also keine fehlgeschlagene Anmeldung zu finden. Was Sie finden können, ist eine Sitzung, die von zwei Orten aus genutzt wird: dieselbe authenticationContext.externalSessionId mit zwei verschiedenen securityContext.asNumber-Werten oder zwei verschiedenen User-Agents innerhalb weniger Stunden. Nehmen Sie Oktas eigene security.session.detect_client_roaming-Ereignisse hinzu und schließen Sie Firmen-VPNs und Telefone, die zwischen WLAN und Mobilfunk wechseln, aus, bevor Sie von Diebstahl sprechen.
Wie Sitzungen gestohlen werden
Nach einer erfolgreichen Anmeldung hält der Browser ein Sitzungscookie. Wer dieses Cookie vorlegt, ist der Benutzer, bis die Sitzung endet. Okta Security beschreibt die zwei üblichen Wege, auf denen Cookies das Gerät des Opfers verlassen: Infostealer-Malware, die Cookies aus dem Browser ausliest, und Adversary-in-the-Middle-Phishingseiten, die die echte Anmeldung durchreichen und die entstehende Sitzung abgreifen (Okta Security: Schutz vor Session Hijacking). MITRE ATT&CK führt den Diebstahl als T1539, Steal Web Session Cookie und die Wiederverwendung als T1550.004, Web Session Cookie.
Sitzungsartefakte gelangen auch über weniger offensichtliche Kanäle nach draußen. Beim Vorfall im Okta-Supportsystem im Oktober 2023 griff ein Angreifer auf Dateien zu, die an Supportfälle angehängt waren; einige davon waren HAR-Dateien mit Sitzungstokens, mit denen Sitzungen bei fünf Kunden übernommen wurden (Okta Security: Ursache und Behebung). HAR-Dateien vor dem Teilen zu bereinigen ist eine Lehre für jeden Supportprozess, nicht nur für den von Okta.
Die Felder, die eine Sitzung kennzeichnen
| Feld | Verwendung |
|---|---|
authenticationContext.externalSessionId | die Sitzungskennung (externalSessionId); danach gruppieren |
authenticationContext.rootSessionId | die Wurzel der interaktiven Sitzung; laut Okta Security kann externalSessionId nach Faktor-Lifecycle-Ereignissen neu erzeugt werden, während die Wurzel bestehen bleibt (Artikel zu rootSessionId) |
securityContext.asNumber, asOrg | das Netz (ASN), aus dem die Anfrage kam |
client.ipAddress | die genaue Quelle |
client.userAgent.rawUserAgent | Browser und Betriebssystem |
Der Kerngedanke: Die legitimen Anfragen des Opfers und die wiederverwendeten Anfragen des Angreifers teilen sich eine Sitzungskennung, unterscheiden sich aber im Netz und meist auch im Browser.
Signale, vom stärksten zum schwächsten
| Signal | Warum es zählt | Analyzer-Regel | Schweregrad |
|---|---|---|---|
| Gleiche Sitzung, 2+ ASNs innerhalb von 12 h | das Cookie wird aus einem anderen Netz verwendet | session.multi_asn | hoch |
| Gleiche Sitzung, 2+ User-Agents innerhalb von 12 h | ein anderer Browser besitzt das Cookie | session.multi_user_agent | mittel |
security.session.detect_client_roaming | Okta selbst hat die Sitzung als Roaming markiert | session.roaming | mittel |
| Sitzungsaktivität von einem Hosting-Anbieter oder Anonymisierer | Angreifer spielen von VPS und Proxys aus ein | access.hosting_provider, access.anonymizer | mittel |
| SSO in sensible Apps aus dem neuen Netz | der Angreifer nutzt, was er gestohlen hat | app.sso_after_suspicious | hoch |
In Identity-Engine-Organisationen suchen Sie außerdem nach user.session.context.change (der Sitzungskontext hat sich so stark geändert, dass Richtlinien neu bewertet werden sollten) und policy.auth_reevaluate.fail, beide in Oktas Katalog der Event Types aufgeführt. Der Analyzer nutzt sie noch nicht als Erkennungen; die Ereignistabelle zeigt sie an.
Einen Treffer durchgehen
Angenommen, der Analyzer meldet „Sitzung aus mehreren Netzen verwendet“ für a.user:
- Öffnen Sie die Belege und sortieren Sie nach Zeit. Wo hat die Sitzung begonnen? Das
user.session.start(und die MFA) sollte aus dem üblichen Netz des Benutzers kommen. Die späteren Anfragen aus einer zweiten ASN sind die mögliche Wiederverwendung. - Ordnen Sie das zweite Netz ein. Ist
asOrgein privater Internetanbieter in der Stadt des Benutzers, ist es wahrscheinlich dessen eigenes Telefon oder Zuhause. Ein Cloud-Anbieter, ein VPS-Hoster oder ein Land, in dem der Benutzer nie war, nicht. - Prüfen Sie den User-Agent. Dieselbe Browserkennung in beiden Netzen deutet auf einen Benutzer unterwegs; ein anderes Betriebssystem oder ein anderer Browser im zweiten Netz deutet auf eine Kopie des Cookies.
- Listen Sie auf, was das zweite Netz getan hat. SSO-Ziele, Admin-Aktionen, Faktorregistrierung. Ein Angreifer mit übernommener Sitzung registriert oft einen Faktor oder erstellt ein Token, um über die Lebensdauer der Sitzung hinaus zu bleiben.
- Prüfen Sie das Gerät des Benutzers. Cookie-Diebstahl per Infostealer bedeutet einen kompromittierten Endpunkt; ein Okta-Passwort-Reset bereinigt ihn nicht.
Fehlalarme, die Ihnen begegnen werden
- Telefone, die zwischen WLAN und Mobilfunk wechseln. Zwei ASNs (Heimanbieter und Mobilfunkbetreiber) in einer Sitzung, gleicher User-Agent. Sehr häufig.
- Firmen-VPN, das mitten in der Sitzung verbunden wird. Die Sitzung beginnt beim Heimanbieter und läuft über den VPN-Ausgang weiter. Wenn Ihr VPN über einen Cloud-Anbieter ausgeht, schlägt zusätzlich die Hosting-Regel an.
- Sicherheitsproxys und Secure Web Gateways, die nur für einen Teil des Verkehrs über ihre eigene ASN ausgehen.
- Browser-Updates während einer langen Sitzung ändern die User-Agent-Kennung.
Deshalb ist die Multi-ASN-Regel ein hoher Befund und kein kritischer. Der Artikel zur Feinabstimmung erklärt den Umgang damit; kurz gesagt: Kennen Sie die Ausgangs-ASNs Ihres VPN und Ihre Mobilfunkbetreiber und prüfen Sie diese zuerst.
Eindämmung
- Beenden Sie die Sitzungen des Benutzers und widerrufen Sie seine Tokens: Das macht das gestohlene Cookie in Okta ungültig.
- Widerrufen Sie Sitzungen in den nachgelagerten Apps, die der Angreifer erreicht hat. Sie sind unabhängig von Okta.
- Behandeln Sie den Endpunkt als kompromittiert, wenn ein Infostealer plausibel ist: neu aufsetzen, dann alle dort verwendeten Zugangsdaten zurücksetzen.
- Setzen Sie Passwort und Faktoren zurück, wenn der Angreifer zusätzlich einen Faktor registriert hat oder Sie einen Diebstahl der Zugangsdaten nicht ausschließen können.
Vorbeugung
Die Empfehlungen von Okta Security gegen die Wiederverwendung von Cookies umfassen die Bindung von Admin-Sitzungen an das Netz (IP oder ASN), erneute Authentifizierung für sensible Ressourcen, Phishing-resistente Authenticators (die Adversary-in-the-Middle-Phishing vereiteln), Anforderungen an die Geräteverwaltung und kürzere Sitzungsdauern, wo die Daten sensibel sind (Okta Security). Nach dem HAR-Datei-Vorfall beschrieb Okta außerdem die Bindung von Admin-Sitzungen an den Netzwerkstandort als Produktverbesserung (Ursachenartikel).