Token-Diebstahl und Session-Hijacking erkennen und stoppen

Token-Diebstahl bedeutet, dass Angreifer den Session- oder Refresh-Token eines bereits authentifizierten Nutzers stehlen und damit MFA umgehen. Der klassische Weg ist Reverse-Proxy-Phishing (Adversary-in-the-Middle), zunehmend auch Info-Stealer auf dem Endpoint. Ein SOC erkennt das über Token-Nutzung ausserhalb des Nutzerkontexts, nicht über den Login selbst. Verteidigung heisst: phishing-resistente MFA, Continuous Access Evaluation, Token-Bindung und Detection auf Refresh-Token-Wiederverwendung.

SOC as a ServiceAlleToken-Diebstahl und Session-Hijacking erkennen und stoppen

Abgrenzung zu Nachbarthemen

Diese Seite beschreibt den Angriffsvektor Token-Diebstahl auf der technischen Ebene: Wie Session- und Refresh-Token gestohlen und wiederverwendet werden, und wie ein SOC das erkennt. Die geschäftliche Fortsetzung im Postfach (Betrug, IBAN-Wechsel) ist unter Business Email Compromise in M365 beschrieben. Die kategoriale Einordnung als eigene Erkennungsdisziplin steht auf ITDR; die Kurzdefinition im Glossar ITDR. Die Plattformseite mit Entra ID und Sentinel auf SOC für Microsoft 365 und Sentinel. Das gesamte Betriebsbild im Pillar SOC as a Service Schweiz.

Merksatz zur Abgrenzung

Token-Diebstahl ist das Wie (die Technik). ITDR ist die Disziplin, die dieses Wie zusammen mit Passwort-Sprays, Consent-Missbrauch und AD-Angriffen abdeckt. BEC ist ein häufiges Was danach passiert.

Wie Token-Diebstahl funktioniert

Weg	Beispiel	Was gestohlen wird
Adversary-in-the-Middle-Phishing	Evilginx-Reverse-Proxy zwischen Nutzer und echter Login-Seite.	Session-Cookie nach erfolgreichem MFA-Prompt.
Info-Stealer auf dem Endpoint	RedLine, Raccoon, Lumma; oft über bösartige Downloads oder Crack-Software.	Browser-Cookies, gespeicherte Refresh-Tokens, Passwort-Manager-Datenbank.
Device-Code-Phishing	Angreifer initiiert OAuth-Device-Code-Flow und lässt das Opfer den Code eingeben.	Refresh-Token für das Angreifer-Gerät, gültig für Wochen.
Primary-Refresh-Token-Diebstahl	Zugriff auf ein Entra-ID-joined Gerät mit lokalem Admin-Recht.	PRT plus Session-Key, ermöglicht Silent-SSO als Opfer.

Gemeinsam ist allen Wegen: Der Login sieht sauber aus, weil er real war. Das Signal liegt darin, wie der Token danach benutzt wird, nicht darin, wie der Nutzer sich angemeldet hat.

Warum klassische MFA nicht mehr reicht

SMS-, Push- und TOTP-basierte MFA authentifizieren einen Login-Vorgang, nicht die spätere Nutzung des Tokens. Sobald ein Angreifer den Session- oder Refresh-Token besitzt, benötigt er keinen weiteren MFA-Prompt. Wirksam sind Kontrollen, die den Token an das Gerät binden (FIDO2 mit Token-Binding, Windows-Hello-for-Business, Zertifikats-basierte Auth) und Kontrollen, die den Token laufend neu bewerten (Continuous Access Evaluation).

Wie ein SOC Token-Diebstahl erkennt

Refresh-Token-Wiederverwendung von ungewöhnlichen IPs, ASNs oder Ländern gegenüber dem Nutzer-Baseline.
Non-interactive Sign-ins ohne MFA-Claim direkt nach einem interaktiven Login vom echten Nutzer.
Impossible Travel zwischen Session-Nutzung und letztem interaktivem Login.
Client-App-Wechsel: Token, für Web ausgestellt, wird auf einmal aus einem Skript- oder CLI-Client benutzt.
Anomalie in Graph-API- oder Exchange-Web-Services-Nutzung (Massen-Reads, ungewöhnliche Endpunkte).
Korrelation mit EDR-Signalen auf Info-Stealer-Familien (Cookie-Zugriff, Browser-Storage-Dumping).

Response-Playbook Token-Diebstahl

Alle Sessions und Refresh-Tokens des Nutzers widerrufen (revokeSignInSessions plus Refresh-Token-Reset).
MFA-Methoden zurücksetzen, phishing-resistente Methode neu einrollen (FIDO2 oder CBA).
Betroffenes Gerät isolieren und auf Info-Stealer prüfen; Browserprofile bereinigen oder neu anlegen.
Bei Entra-ID-joined Geräten: Gerät disablen, PRT invalidieren, Neu-Registrierung erzwingen.
Conditional Access schärfen: Sign-in-Frequency reduzieren, Continuous Access Evaluation erzwingen, Risk-basierte Policies aktivieren.
Nachgelagerte Aktivität untersuchen: Inbox-Regeln, OAuth-Consents, ausgehende Nachrichten; siehe BEC in M365.

Einordnung im SOC-Betrieb

Wie die Token-Detection im laufenden 24/7-Betrieb liegt, steht im Pillar SOC as a Service Schweiz.

Häufige Fragen

Ist Token-Diebstahl dasselbe wie BEC?

Nein. Token-Diebstahl ist die Technik, die Angreifer nutzen, um an ein Konto zu kommen. BEC ist ein häufiges Folgedelikt im Postfach. Ein SOC muss beide Ebenen erkennen: die Token-Nutzung (diese Seite) und den Postfach-Missbrauch (siehe [BEC in M365](/de/soc/business-email-compromise-m365)).

Schützt FIDO2 vollständig gegen Token-Diebstahl?

FIDO2 macht Reverse-Proxy-Phishing praktisch wirkungslos, weil der Origin geprüft wird. Info-Stealer, die den Cookie aus dem lokalen Browser stehlen, bleiben aber ein Risiko, solange der Endpoint kompromittiert ist. Token-Bindung, Continuous Access Evaluation und EDR-Detection auf dem Endpoint gehören dazu.

Wie oft rotieren Tokens standardmässig?

Access-Tokens in Entra ID sind meist 60 bis 90 Minuten gültig; Refresh-Tokens können ohne Continuous Access Evaluation Wochen bis Monate leben. Genau deshalb ist Refresh-Token-Wiederverwendung so wertvoll für Angreifer, und Detection darauf so wertvoll für die Verteidigung.

Brauchen wir ITDR zusätzlich zum SOC?

ITDR ist keine separate Anschaffung, sondern eine Detection-Disziplin, die ein modernes SOC abdeckt (Details auf [ITDR](/de/soc/itdr-identity-threat-detection)). Wichtig ist, dass Identitäts-Signale (Entra ID, AD, Okta) korreliert werden, nicht nur Endpoint-Signale.

Wie schnell sollte man auf Token-Diebstahl reagieren?

Minutenlogik. Solange die Session lebt, hat der Angreifer aktive Rechte im Tenant. Session-Revoke und MFA-Reset gehören in die erste Stunde. Zielwerte siehe [MTTD und MTTR im SOC](/de/soc/soc-mttd-mttr).

Weiterlesen im Cluster

Business Email Compromise in Microsoft 365 erkennen und stoppen

Business Email Compromise (BEC) in Microsoft 365 ist selten ein Malware-Fall, sondern eine Kette aus Phishing, Session- oder Token-Diebstahl, Inbox-Regeln und OAuth-Consent-Missbrauch. Ein SOC erkennt BEC über korrelierte Signale aus Entra ID, Exchange Online und Defender for Cloud Apps, nicht über den E-Mail-Text allein. Reaktion heisst: Session widerrufen, Inbox-Regeln entfernen, OAuth-Consents zurückziehen, MFA neu erzwingen, dokumentiert nach ISG- und Versicherungslogik.

SOC für Microsoft 365 und Sentinel: Was zählt

Ein SOC für Microsoft-365- und Sentinel-Umgebungen korreliert Signale aus Entra ID, Defender XDR, Exchange Online und Azure in einem Detection-Layer und reagiert 24/7. Der Wert entsteht nicht durch die Lizenz, sondern durch Analysten, Playbooks und dokumentierte Reaktion.

Security Awareness Training: aus Klick-Risiko wird Meldebereitschaft

Security-Awareness-Training ist keine E-Learning-Pflichtübung, sondern ein messbarer Verhaltens-Prozess. Ziel ist nicht die Klickrate von null, sondern die Melderate von verdächtigen E-Mails im Zielkorridor von 40 bis 50 Prozent, bevor das SOC eskaliert. ANOMAL kombiniert kurze rollen-spezifische Module, realistische Phishing-Simulationen und eine Meldeschnittstelle in Microsoft 365, damit Awareness zur Detection-Quelle wird. Die Anforderung «Regelmässige Security-Awareness-Trainings mit Phishing-Simulationen» der meisten Schweizer Cyberversicherer wird damit dokumentiert erfüllt.

Incident Response in 72 Stunden

Ein ernsthafter Cyber-Vorfall wird nicht in Wochen gemanagt, sondern in den ersten Stunden entschieden. ANOMAL stellt ein Schweizer Incident-Response-Team, das innerhalb der 72-Stunden-Frist der Cyberversicherung greift: Erstanalyse, Eindämmung, Beweissicherung und Kommunikation mit Versicherung, Regulator und Geschäftsleitung. Kein Retainer erforderlich, aber empfohlen, damit die Uhr nicht erst beim ersten Anruf startet.

MTTD und MTTR: Die zwei SOC-Kennzahlen, auf die es ankommt

Mean Time to Detect (MTTD) misst, wie schnell ein SOC einen Angriff erkennt. Mean Time to Respond oder Contain (MTTR, MTTC) misst, wie schnell er gestoppt ist. Beide Werte sind der einzige verlässliche Nachweis, dass ein SOC arbeitet und nicht nur läuft.

Kurzdefinitionen im Glossar nachschlagen