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

Das Token, das Microsoft Entra ID nach erfolgreicher Anmeldung ausstellt, steht im Zentrum vieler Angriffe auf den Dienst. Wer es in Händen hält, benötigt weder Passwort noch zweiten Faktor. Wie Angreifer an solche Token kommen und was Microsofts Schutzfunktionen dagegen leisten, hat Niklas Kerner (ERNW Enno Rey Netzwerke GmbH) im August 2026 in einer vierteiligen Serie auf insinuator.net untersucht.

Der erste Teil, "Token Theft in Microsoft Entra ID (Part 1 of 4): Threat Landscape and Attack Techniques", erschien am 24. August 2026 begleitend zum ERNW White Paper 80. Die Serie beschreibt die Angriffstechniken und misst, was Continuous Access Evaluation und Token Protection dagegen ausrichten. Dieser Beitrag ordnet das Thema für die IT-Leitung im Mittelstand ein und stützt sich für die technischen Details auf Microsofts Dokumentation.

Conditional Access prüft MFA, Gerätestatus und Standort, wenn Entra ID ein Access Token ausstellt. Danach liest der Ressourcenanbieter nur noch die im Token enthaltenen Claims. Eine erneute Prüfung findet erst statt, wenn CAE aktiv ist und ein Ereignis sie auslöst.

Was ist Session Hijacking in Entra ID?

Session Hijacking ist die unbefugte Übernahme einer bereits authentifizierten Sitzung. In Microsoft Entra ID entstehen nach der Anmeldung OAuth-2.0-Token: Access Token, Refresh Token und ID Token. Ein Angreifer extrahiert ein solches Token und nutzt es von seinem eigenen System aus weiter. Die MFA der ursprünglichen Anmeldung verliert dadurch ihre Wirkung.

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

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

Warum ein gestohlener Refresh Token die MFA mitnimmt

Der Primary Refresh Token (PRT) trägt den MFA-Nachweis und den Gerätestatus der Erstanmeldung als Claims. Microsoft beschreibt das in der PRT-Dokumentation: Wird mit einem MFA-basierten PRT ein App-Token angefordert, überträgt Entra ID den MFA-Claim auf dieses Token, damit Nutzer nicht bei jeder Anwendung erneut bestätigen müssen. Der Gerätestatus ist ein eigener Claim.

Ein gestohlener Refresh Token bringt diese Claims mit. Ressourcenanbieter prüfen beim Zugriff Signatur, Ablaufzeit und die enthaltenen Claims; den aktuellen Zustand des Geräts oder die geltenden CA-Richtlinien fragen sie nicht ab. Fordert der Angreifer damit neue Access Token an, gelten Richtlinien, die MFA oder ein konformes Gerät verlangen, durch die mitgeführten Claims als erfüllt. Erst ein abgelaufenes Sign-in-Frequency-Intervall, ein erkanntes Nutzerrisiko, ein Widerruf oder ein CAE-Ereignis erzwingt eine erneute Prüfung. 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

Adversary-in-the-Middle-Phishing (AitM, MITRE ATT&CK T1557) arbeitet mit einem Reverse-Proxy, der sich in den Login-Prozess einklinkt. Das Opfer sieht eine gewöhnliche Anmeldung: URL im Browser, Passwort eingeben, MFA-Bestätigung abschicken. Der Proxy leitet sämtliche Schritte weiter und erbeutet das Session-Cookie oder Token nach Abschluss der Authentifizierung, bevor es das Endgerät erreicht. Phishingresistente MFA wie FIDO2 oder Windows Hello for Business stoppt diesen Angriff, weil die kryptografische Bindung an die echte Domain des Anbieters fehlt. Bei allen anderen MFA-Formen erhält der Angreifer trotz aktivierter MFA ein gültiges Token. Frameworks wie Evilginx liefern die Infrastruktur als fertiges Paket.

Infoblox Threat Intel rekonstruierte im Mai 2026 eine Kampagne gegen Universitäten, Unternehmen sowie EU- und UN-Einrichtungen. Die Köder stammten aus dem Beschaffungswesen. Der Akteur nutzte die Kits Evilginx, FlowerStorm und Kali365 abwechselnd und verschickte die Nachrichten über kompromittierte Firmenkonten.

Infostealer im Browser

Infostealer extrahieren lokal abgelegte Anmeldedaten und Sitzungs-Cookies aus dem Browser. Häufig nutzen sie ClickFix als Einstieg. Laut Huntress-Analysen zeigt dabei eine präparierte Seite eine gefälschte Fehlermeldung und fordert das Opfer auf, einen angezeigten Befehl über das Windows-Ausführen-Dialogfeld (Win+R) einzufügen und auszuführen. Der Code startet auf Betriebssystemebene und umgeht browsergestützte Schutzmechanismen. Huntress dokumentiert solche Kampagnen zur Verteilung von Schadsoftware wie LummaC2 und Rhadamanthys. Die Variante TerminalFix führte im August 2026 in das Berliner Landesnetz, siehe Cyberangriff auf den Berliner Senat. Phishingresistente MFA greift hier nicht, da die Sitzung bereits legitim besteht.

Device Code Phishing mit Storm-2372

Der OAuth-2.0-Device-Code-Flow richtet sich an Geräte mit begrenzter Eingabemöglichkeit, zum Beispiel Smart-TVs oder Drucker. Der Nutzer meldet sich auf einem zweiten Gerät an. Der Code bleibt 15 Minuten gültig. Angreifer starten den Ablauf auf ihrem eigenen Rechner und veranlassen das Opfer, den Code auf der echten Microsoft-Seite einzugeben. Die Token gelangen dann zum Angreifer.

Seit August 2024 dokumentiert Microsoft eine solche Kampagne der Gruppe Storm-2372. Seit Juli 2026 wird diese Gruppe als Untergruppe von Midnight Blizzard geführt. 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.

Push Security beschrieb im Dezember 2025 unter dem Namen ConsentFix eine verwandte Technik. Der Angreifer bringt das Opfer über eine präparierte Seite dazu, einen OAuth-Autorisierungsablauf für einen legitimen Client wie die Azure CLI zu starten, der localhost als Rückgabeadresse verwendet. Das Opfer meldet sich auf der echten Microsoft-Seite an und schließt die MFA ab. Microsoft leitet danach an localhost weiter. Weil dort kein Dienst antwortet, zeigt der Browser eine Fehlerseite, in deren Adresse der Autorisierungscode steht. Das Opfer kopiert diese Adresse auf die Angreifer-Seite, die den Code ausliest und gegen Token tauscht. Der Autorisierungscode-Ablauf lässt sich in Entra ID nicht abschalten.

Conditional Access prüft beim Ausstellen von Access Token

Conditional Access steuert die Ausstellung eines Access Tokens über Grant Controls wie "Require authentication strength" oder "Require device to be marked as compliant". Die Stufe Phishing-resistant MFA ist fest integriert und umfasst Windows Hello for Business, FIDO2-Sicherheitsschlüssel und zertifikatsbasierte Authentifizierung. Der Beitrag zur Härtung von Microsoft Entra ID erläutert die Einrichtung solcher Policies für kleine und mittlere Unternehmen.

AitM-Phishing wird durch phishingresistente Methoden gestoppt, da sie die Anmeldung kryptografisch an die echte Quelle binden. Diese Methoden wirken nicht gegen Infostealer, Device Code Phishing und ConsentFix, weil dort eine legitime Anmeldung stattfindet oder die Sitzung bereits existiert. Somit schließt die Einführung von Passkeys im Unternehmen nur einen Angriffsweg. Die Maßnahmen entfalten je nach Angriffsweg unterschiedliche Wirkung:

Continuous Access Evaluation und Token Protection

Continuous Access Evaluation (CAE) ersetzt die feste Token-Laufzeit. Ein Rückkanal zwischen Entra ID und dem Ressourcenanbieter ist die Grundlage. 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, die Ereignisverteilung kann bis zu 15 Minuten dauern. Standortrichtlinien werden sofort durchgesetzt. Ein CAE-fähiger Dienst lehnt ein Token ab, das außerhalb eines vertrauenswürdigen Netzes wiederverwendet wird.

Token Protection ist ein Session Control in Conditional Access. Nur gerätegebundene Sign-in-Session-Token akzeptiert Entra ID dann, etwa den PRT. Bei funktionierendem TPM liegt dessen privater Schlüssel in der sicheren Hardware des Geräts. Ein von einem anderen Gerät vorgelegtes Token ist wertlos. Der Schutz gilt für Exchange Online, SharePoint Online und Teams. Auf Windows sind zusätzlich Azure Virtual Desktop und Windows 365 abgedeckt. Voraussetzung ist Windows 10 oder neuer mit Entra-Join, Hybrid-Join oder Registrierung; macOS und iOS laufen in der Vorschau. Im Browser ist nur Microsoft Edge für gerätegebundene Token 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 erfordern Lizenzen der Stufen P1 oder P2. Token Protection braucht zusätzlich Intune oder Microsoft Defender for Endpoint. Die Basislizenz enthält sie nicht. Standardmäßig sind sie deaktiviert.

Account Takeover erkennen: Anomalous Token und Reaktion

Entra ID Protection stuft ein Token als "Anomalous Token" ein, sobald es untypische Merkmale aufweist oder von einem unbekannten Standort genutzt wird. "Unfamiliar sign-in properties" betrifft Anmeldungen, die vom bisherigen Verhalten abweichen, insbesondere bei nicht-interaktiven Vorgängen. Auf Windows 10 und 11 erkennt Microsoft Defender for Endpoint zusätzlich verdächtige PRT-Zugriffe.

Microsofts Token-Theft-Playbook gibt für die Reaktion eine feste Abfolge vor. Zuerst wird der Nutzer gesperrt und alle Sitzungen werden widerrufen. Danach folgt das Zurücksetzen des Passworts, bei Hybridkonten zweimal. Anschließend entfernt man hinzugefügte Geräte und Authentifizierungsmethoden, blockiert die Angreifer-IP und prüft die Umgebung auf weitere betroffene Konten. AuditLogs und OfficeActivity gehören mit in die Auswertung, weil nicht jede Erkennung in den SigninLogs erscheint. Der Wiki-Eintrag erklärt generell, wie sich ein Account Takeover erkennen und abwehren lässt.

Einordnung

OAuth 2.0 und Bearer-Token gelten als Industriestandard. Microsoft betont, dass Device Code Phishing keine Schwachstelle im eigenen Code ausnutzt. Der Verteidigungsort verschiebt sich von der Anmeldung zur Sitzung. MFA für alle ist nur der erste Schritt. Ohne Token Protection und CAE bleibt die Sitzung ungeschützt.

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, zuletzt Token Protection im Report-only-Modus. Ein Penetrationstest mit explizitem Fokus auf die Identitätsebene prüft diese Kette. Die NIS-2-Richtlinie verlangt in Art. 21 Abs. 2 lit. j den Einsatz von Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierungslösungen.

---

Korrektur 16.09.2026: Eine frühere Fassung dieses Beitrags enthielt in den Abschnitten zum gestohlenen Refresh Token, zu Adversary-in-the-Middle, ClickFix und ConsentFix Formulierungen, die auf die Analyse von Niklas Kerner (ERNW) zurückgehen, ohne das Original zu nennen. Wir haben diese Passagen aus den Primärquellen neu geschrieben, den Verweis auf Kerners Serie ergänzt und den Quellenblock auf Primärquellen umgestellt.

Quellen

• Niklas Kerner (ERNW Enno Rey Netzwerke GmbH): Token Theft in Microsoft Entra ID (Part 1 of 4): Threat Landscape and Attack Techniques, insinuator.net, 24.08.2026. Begleitet das ERNW White Paper 80.
• Infoblox Threat Intel: The Procurement Trap: Inside an AitM Campaign Targeting Global Institutions, infoblox.com, 21.07.2026
• Huntress: Don't Sweat ClickFix Techniques und ClickFix Malware Buried in Images (LummaC2, Rhadamanthys)
• Push Security: ConsentFix, 11.12.2025
• 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
• Europäisches Parlament und Rat: NIS-2-Richtlinie (EU) 2022/2555, Art. 21 Abs. 2 lit. j, Amtsblatt der EU L 333/80, 27.12.2022