Session Hijacking in Microsoft Entra ID: Warum Angreifer Token statt Passwörter stehlen

Viele Angriffe auf Microsoft Entra ID zielen auf das Token, das der Dienst nach einer erfolgreichen Anmeldung ausstellt. Wer es besitzt, braucht weder Passwort noch zweiten Faktor. Die Fachpresse diskutiert diese Verschiebung seit Anfang September 2026 unter dem Stichwort Token-Diebstahl.

Conditional Access prüft MFA, Gerätestatus und Standort im Moment der Token-Ausstellung. Danach validiert Entra ID nur noch das Token selbst. Ein gestohlener Refresh Token ist deshalb so vertrauenswürdig wie die legitime Sitzung, aus der er stammt.

Was ist Session Hijacking in Entra ID?

Session Hijacking bezeichnet die unbefugte Übernahme einer bereits authentifizierten Sitzung. In Microsoft Entra ID sind das die OAuth-2.0-Token, die nach der Anmeldung entstehen: Access Token, Refresh Token und ID Token. Der Angreifer extrahiert ein solches Token und verwendet es von seinem eigenen System weiter, wodurch die MFA der ursprünglichen Anmeldung wirkungslos wird.

Access Token sind in Entra ID als Bearer-Token umgesetzt. Der Besitz genügt, um im Namen des Nutzers auf eine Ressource zuzugreifen. Ein Ressourcenanbieter prüft bei der Vorlage nur Signatur, Ablaufzeit und Berechtigungen. Access Token laufen standardmäßig nach einer Stunde ab. Der zugehörige Refresh Token gilt in den meisten Szenarien 90 Tage und ersetzt sich bei jeder Nutzung durch einen neuen.

Nach dem Microsoft Digital Defense Report 2024 machen Passwortangriffe über 99 Prozent der rund 600 Millionen täglichen Identitätsangriffe aus. Die Cloud Security Alliance führt unzureichendes Identity and Access Management im Bericht Top Threats to Cloud Computing 2026 als größte Cloud-Bedrohung.

Warum ein gestohlener Refresh Token die MFA mitnimmt

Conditional Access prüft die Bedingungen einer Anmeldung einmal, bei der Ausstellung des Tokens. Wurde dabei eine phishingresistente Methode auf einem konformen Gerät genutzt, überträgt sich dieser Nachweis auf den Refresh Token. Microsoft beschreibt das für den Primary Refresh Token (PRT): Der MFA-Nachweis wird an nachfolgende App-Token weitergegeben, damit Nutzer nicht bei jeder Anwendung erneut bestätigen müssen.

Wer den Refresh Token erbeutet, erhält deshalb alle damit verbundenen Berechtigungen samt MFA- und Gerätekonformitätsnachweis. Er muss weder den Gerätestatus belegen noch sich erneut authentifizieren. Strenge Conditional-Access-Richtlinien bleiben bei jeder weiteren Token-Anfrage erfüllt, solange kein Ereignis eine Neubewertung auslöst. Die Standardeinstellung für die Anmeldehäufigkeit ist ein rollierendes Fenster von 90 Tagen.

Drei Wege zum Token: AitM-Phishing, Infostealer, Device-Code-Missbrauch

Evilginx und Adversary-in-the-Middle

Beim Adversary-in-the-Middle-Phishing (AitM, MITRE ATT&CK T1557) leitet ein Reverse-Proxy den Anmeldevorgang zwischen Opfer und der echten Microsoft-Anmeldeseite in Echtzeit durch. Zugangsdaten und MFA-Bestätigung werden weitergereicht, das resultierende Token fängt der Proxy ab. Frameworks wie Evilginx machen die Technik massentauglich.

Infoblox Threat Intel rekonstruierte im Mai 2026 eine Kampagne, die mit Ködern aus dem Beschaffungswesen Universitäten, Unternehmen sowie Einrichtungen der EU und der UN angriff. Der Akteur wechselte zwischen den Kits Evilginx, FlowerStorm und Kali365 und versendete über bereits gekaperte Firmenkonten.

Infostealer im Browser

Infostealer lesen lokal gespeicherte Anmeldedaten und Sitzungs-Cookies aus dem Browser aus. Der Zugang läuft häufig über ClickFix: Eine gefälschte Fehlermeldung bringt das Opfer dazu, einen verschleierten Befehl in den Ausführen-Dialog von Windows einzufügen. Nach Analysen von Huntress verbreiten solche Kampagnen Schadsoftware wie LummaC2 und Rhadamanthys. Phishingresistente MFA hilft hier nicht, weil die Sitzung bereits legitim aufgebaut wurde.

Device Code Phishing mit Storm-2372

Der OAuth-2.0-Device-Code-Flow ist für Geräte mit eingeschränkter Eingabe gedacht, etwa Smart-TVs oder Drucker. Der Nutzer meldet sich auf einem zweiten Gerät an, der Code ist 15 Minuten gültig. Angreifer starten den Ablauf auf ihrem eigenen Rechner und bringen das Opfer dazu, den Code auf der echten Microsoft-Seite einzugeben. Die Token landen beim Angreifer.

Microsoft dokumentiert seit August 2024 eine solche Kampagne der Gruppe Storm-2372, seit Juli 2026 als Untergruppe von Midnight Blizzard eingeordnet. Die Köder imitieren Teams-Einladungen, WhatsApp und Signal. Betroffen waren unter anderem Regierungen, NGOs, IT-Dienstleister und Energieunternehmen in Europa, Nordamerika, Afrika und dem Nahen Osten.

Einen verwandten Weg beschrieb Push Security im Dezember 2025 unter dem Namen ConsentFix: Das Opfer startet einen Autorisierungscode-Ablauf für einen öffentlichen Client wie die Azure CLI und kopiert die Fehler-URL von localhost zurück zum Angreifer. Der Autorisierungscode-Ablauf lässt sich in Entra ID nicht blockieren.

Conditional Access prüft nur bei der Token-Ausstellung

Conditional Access entscheidet über Grant Controls wie "Require authentication strength" oder "Require device to be marked as compliant", ob ein Token ausgestellt wird. Die eingebaute Stufe Phishing-resistant MFA umfasst Windows Hello for Business, FIDO2-Sicherheitsschlüssel und zertifikatsbasierte Authentifizierung. Wie diese Policies für kleine und mittlere Unternehmen aufgesetzt werden, beschreibt der Beitrag zur Härtung von Microsoft Entra ID.

Phishingresistente Methoden binden die Anmeldung kryptografisch an die echte Quelle und stoppen AitM-Phishing. Gegen Infostealer, Device Code Phishing und ConsentFix greifen sie nicht, weil dort eine legitime Anmeldung stattfindet oder die Sitzung bereits existiert. Wer Passkeys im Unternehmen einführt, schließt also einen Weg. Die Wirkung der einzelnen Maßnahmen unterscheidet sich je nach Angriffsweg:

Continuous Access Evaluation und Token Protection

Continuous Access Evaluation (CAE) ersetzt die starre Token-Laufzeit durch einen Rückkanal zwischen Entra ID und dem Ressourcenanbieter. Exchange Online, SharePoint Online und Teams abonnieren kritische Ereignisse: Konto deaktiviert oder gelöscht, Passwort geändert oder zurückgesetzt, hohes Nutzerrisiko in Entra ID Protection. Die Sperrung erfolgt nahezu in Echtzeit, mit bis zu 15 Minuten Latenz durch die Ereignisverteilung. Standortrichtlinien werden sofort durchgesetzt. Ein Token, das außerhalb eines vertrauenswürdigen Netzes wiederverwendet wird, lehnt der CAE-fähige Dienst ab.

Token Protection ist ein Session Control in Conditional Access. Entra ID akzeptiert dann nur gerätegebundene Sign-in-Session-Token wie den PRT, dessen privater Schlüssel bei funktionierendem TPM in der sicheren Hardware des Geräts liegt. Ein von einem anderen Gerät vorgelegtes Token ist wertlos. Der Schutz gilt für Exchange Online, SharePoint Online und Teams, auf Windows zusätzlich für Azure Virtual Desktop und Windows 365. Voraussetzung sind Windows 10 oder neuer mit Entra-Join, Hybrid-Join oder Registrierung; macOS und iOS laufen in der Vorschau. Im Browser ist für gerätegebundene Token allein Microsoft Edge geschützt.

Microsoft empfiehlt, Token Protection zunächst im Report-only-Modus mit einer Pilotgruppe zu betreiben. Interaktive und nicht-interaktive Anmeldeprotokolle sollten lange genug ausgewertet werden, bevor die Richtlinie erzwungen wird. Ältere Apps und nicht registrierte Geräte fallen sonst aus.

Beide Funktionen setzen Lizenzen der Stufen P1 oder P2 voraus, Token Protection zusätzlich Intune oder Microsoft Defender for Endpoint. In der Basislizenz sind sie nicht enthalten und standardmäßig nicht aktiv.

Account Takeover erkennen: Anomalous Token und Reaktion

Entra ID Protection meldet ein "Anomalous Token", wenn ein Token untypische Eigenschaften zeigt oder von einem unbekannten Ort verwendet wird. "Unfamiliar sign-in properties" weist auf Anmeldungen hin, die vom bisherigen Muster abweichen, besonders bei nicht-interaktiven Anmeldungen. Microsoft Defender for Endpoint erkennt auf Windows 10 und 11 zudem verdächtige Zugriffe auf den PRT.

Für die Reaktion beschreibt Microsofts Token-Theft-Playbook eine feste Reihenfolge. Zuerst wird der Nutzer blockiert und jede Sitzung widerrufen, dann das Passwort zurückgesetzt, bei Hybridkonten zweimal. Danach werden hinzugefügte Geräte und Authentifizierungsmethoden entfernt, die Angreifer-IP blockiert und die Umgebung nach weiteren betroffenen Konten durchsucht. Nicht jede Erkennung erzeugt einen Eintrag in den SigninLogs, deshalb gehören AuditLogs und OfficeActivity mit in die Auswertung. Wie sich ein Account Takeover generell erkennen und abwehren lässt, fasst der Wiki-Eintrag zusammen.

Einordnung

OAuth 2.0 und Bearer-Token sind Industriestandard, und Microsoft betont, dass Device Code Phishing keine Schwachstelle im eigenen Code ausnutzt. Der Ort der Verteidigung wandert von der Anmeldung in die Sitzung. Ein Unternehmen, das MFA für alle erzwungen hat, hat den ersten Schritt getan. Die Sitzung bleibt ungeschützt, solange Token Protection und CAE nicht laufen.

Für die IT-Leitung ergibt sich eine Reihenfolge. Zuerst den Device-Code-Flow per Conditional Access blockieren, wo er nicht gebraucht wird. Dann phishingresistente Authentication Strengths für privilegierte Rollen. Danach CAE-fähige Clients und Standortrichtlinien, schließlich Token Protection im Report-only-Modus. Ob diese Kette in der eigenen Umgebung hält, zeigt ein Penetrationstest, der die Identitätsebene ausdrücklich in den Scope nimmt. NIS2 verlangt in Art. 21 Abs. 2 lit. j den Einsatz von Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierungslösungen.

Quellen

• All About Security: Entra ID: Wie Token-Diebstahl Firmen bedroht, 04.09.2026
• All About Security: Gefälschte Ausschreibungen als Einfallstor, 23.07.2026
• Microsoft Learn: Refresh tokens in the Microsoft identity platform
• Microsoft Learn: Continuous access evaluation
• Microsoft Learn: Token Protection in Microsoft Entra Conditional Access
• Microsoft Learn: What is a Primary Refresh Token?
• Microsoft Learn: Configure adaptive session lifetime policies
• Microsoft Learn: Conditional Access authentication strength
• Microsoft Learn: Grant controls in Conditional Access policy
• Microsoft Learn: OAuth 2.0 device authorization grant flow
• Microsoft Learn: Token theft playbook
• Microsoft Security Blog: Storm-2372 conducts device code phishing campaign, 13.02.2025, Updates 14.02.2025 und 31.07.2026
• Microsoft: Digital Defense Report 2024
• Cloud Security Alliance: Top Threats to Cloud Computing 2026
• MITRE ATT&CK: T1557 Adversary-in-the-Middle, T1528 Steal Application Access Token, T1550.001 Application Access Token