Token-Diebstahl ist auch 2025 eine reale Gefahr. In meinen Projekten spreche ich das Thema immer wieder an, vor allem bei Mandanten, die sich ganz auf die Multi-Faktor-Authentifizierung (MFA) verlassen. Ein Allheilmittel ist MFA aber nicht. Mit Methoden wie Adversary-in-the-Middle (AiTM) stehlen Angreifer Session-Cookies oder Refresh-Tokens, und zwar auch dann, wenn die MFA erfolgreich war. Richtig heikel wird es mit Infostealer-Malware, die Zugangsdaten direkt auf kompromittierten Endpunkten abgreift. Der rechtmäßige Nutzer merkt davon in der Regel nichts. In vielen Tenants, die ich betreue, tauchten in den letzten Monaten immer wieder Warnungen zu verdächtigen Anmeldeaktivitäten auf, hinter denen sich schließlich gestohlene Sessions verbargen.

Angreifer stehlen das Token erst nach der erfolgreichen MFA

Beim AiTM-Phishing arbeiten Angreifer mit manipulierten Login-Seiten. Diese fangen das Passwort und die MFA-Eingabe ab, bauen im Namen des Opfers eine gültige Session auf und nehmen das zugehörige Token gleich mit. Infostealer-Malware erbeutet dagegen direkt auf dem Gerät alles, was das Opfer im Browser oder in nativen Apps gespeichert hat. Klassische Schutzmechanismen wie MFA oder IP-Filter laufen dann ins Leere, weil das gestohlene Token als „gültig“ erscheint. Tückisch ist vor allem, dass viele dieser Zugriffe für Entra ID völlig normal aussehen, solange das Token nicht abgelaufen ist. Einen solchen Angriff bemerkt man erst, wenn man gezielt nach Anomalien sucht, etwa nach ungewohnten Orten oder Geräten. Weiterführende Informationen bieten unter anderem die Microsoft-Dokumentation zu den Risiken in Identity Protection und das Token-Theft-Playbook.

Vereinfacht sieht ein AiTM-Angriff mit Token-Diebstahl so aus:

flowchart TD
    User["Benutzer meldet sich an"] --> AiTM["Phishing-Seite leitet Login weiter"]
    AiTM --> MFA["MFA wird eingegeben"]
    MFA --> EntraID["Entra ID authentifiziert"]
    EntraID --> AiTM
    AiTM --> Token["Token wird gestohlen"]
    Token --> Attacker["Angreifer nutzt Session"]

Abbildung: Typischer Ablauf eines Adversary-in-the-Middle-Angriffs mit gestohlenem Token.

Conditional Access und Token Protection entwerten gestohlene Tokens

Meiner Erfahrung nach ist Conditional Access (CA) mit passend gewählten Bedingungen nach wie vor der stärkste Hebel, den wir haben, um gestohlene Tokens weitgehend nutzlos zu machen. Am meisten bringt es, für den Zugriff auf sensible Anwendungen neben MFA zusätzlich ein gerätebasiertes Signal zu verlangen, etwa „Compliant Device“ oder „Hybrid mit Entra ID verbunden“. Damit schrumpft die Angriffsfläche deutlich, denn ein nicht verwaltetes oder durch Malware kompromittiertes Gerät trifft dann auf eine echte Hürde. In besonders kritischen Szenarien hilft zusätzlich „Sign-in frequency“, weil Sessions dann in regelmäßigen Abständen erneuert werden müssen. Einen Schritt weiter geht Continuous Access Evaluation (CAE). Wie ich in meinem Beitrag über CAE und Strict Location Enforcement beschrieben habe, macht CAE Sitzungen bei bestimmten Risiken oder einem Standortwechsel sofort ungültig.

Spannend finde ich außerdem Token Protection für Anmeldesitzungen. Allerdings steckt das Feature noch in der Public Preview und funktioniert derzeit nur mit modernen Windows-Desktopanwendungen (Dokumentation zu Token Protection). Das ausgestellte Token wird dabei an ein Gerät gebunden, sodass es auf einem anderen Rechner nicht mehr funktioniert. Für Browser und mobile Apps heißt es noch abwarten, bis die allgemeine Verfügbarkeit (GA) erreicht ist und die Unterstützung breiter wird. Desktopzugriffe auf Exchange Online und SharePoint lassen sich aber schon jetzt in Pilotgruppen testen, sofern die Lizenzvoraussetzungen erfüllt sind (Entra ID P1/P2, je nach Richtlinie).

Entra ID Protection meldet verdächtige Anmeldeaktivitäten

Um Anomalien wie „Anomalous Token“ oder „Ungewöhnliche Anmeldeeigenschaften“ aufzuspüren, nutze ich in der Praxis gern Microsoft Entra ID Protection (Lizenz: Entra ID P2). Tauchen Sessions plötzlich auf neuen Geräten oder aus anderen Ländern auf, schlägt der Dienst an und informiert auch das SOC-Team. Wer die Erkennung voll ausschöpfen will, sollte im Portal unter Entra ID → Schutz → Risikoerkennung regelmäßig die Liste durchgehen.

Mein Tipp: Nach einer Kontokompromittierung sind Inbox-Regeln häufig ein Warnsignal. Ich prüfe deshalb im Exchange Admin Center grundsätzlich alle Regeln auf verdächtige Weiterleitungen oder Löschaktionen. Dieser Schritt geht oft unter, liefert aber ein klares Indiz für aktiven Missbrauch.

Im Ernstfall sperrt man zuerst alle Sitzungen und prüft dann die Methoden

Besteht der Verdacht auf Token-Diebstahl oder meldet Identity Protection einen Alarm, braucht es ein klares Vorgehen. Als Erstes widerruft man alle aktiven Sessions des betroffenen Nutzers. Das erledigt man direkt im Microsoft Entra Admin Center → Benutzer → Nutzer auswählen → Sitzungen widerrufen. Wer die nötigen Rechte hat, kann das auch per Microsoft Graph PowerShell skripten:

# Vorausgesetzt: Microsoft Graph PowerShell mit UserAuthenticationMethod.ReadWrite.All Rechte
Revoke-MgUserSignInSession -UserId <UPN oder Objekt-ID>

Danach setzt man das Kennwort zurück, überprüft sämtliche MFA-Methoden und sucht in Exchange Online nach schädlichen Inbox-Regeln. Ich verwende dafür gern die Filter im Exchange Admin Center unter „Mailflow → Regeln“ und die „Posteingangsregeln“ des jeweiligen Benutzers.

Angriffserkennung und Prävention gehören zusammen

Token-Diebstahl nach MFA ist längst kein Randthema mehr. In vielen Tenants, die ich zu sehen bekomme, sind Angreifer genau auf diesem Weg eingedrungen. MFA bleibt unverzichtbar. Ohne gerätebasierte CA-Bedingungen, eine regelmäßige Überwachung mit Entra ID Protection und ein klares Incident-Response-Playbook bleibt die Verteidigung aber lückenhaft. Wer schon jetzt in Piloten mit Token Protection investiert, verschafft sich einen Vorsprung. Wichtiger ist es allerdings, die eigenen Abläufe für den schnellen Widerruf von Sessions und die Aufklärung der Benutzer zu schärfen. Mit etwas Übung und den passenden Werkzeugen bekommt man Token-Diebstahl gut in den Griff. Mehr Hintergrund zu den Angriffsmethoden liefert mein Beitrag über AiTM-Phishing in Microsoft 365.