Adversary-in-the-Middle gegen Entra ID: wo Conditional Access aufhört zu wirken

MFA war das Versprechen. Es hat nur nie den Token geschützt.

Die meisten Organisationen im DACH-Mittelstand haben Multi-Faktor-Authentifizierung ausgerollt und betrachten die Identitätsschicht damit als abgesichert. Das ist nachvollziehbar — und im Kern falsch. MFA schützt den Moment der Anmeldung. Sie schützt nicht das Artefakt, das nach erfolgreicher Anmeldung entsteht: den Token, mit dem sich der Client fortan gegenüber Entra ID und den nachgelagerten Ressourcen ausweist.

Genau hier setzt Adversary-in-the-Middle an. Der Angreifer fängt nicht das Passwort und den zweiten Faktor ab, um sie später erneut einzugeben — das würde an moderner MFA scheitern. Er positioniert sich als transparenter Reverse-Proxy zwischen Opfer und echtem Anmeldedienst, lässt das Opfer die komplette Authentifizierung inklusive MFA durchführen und greift die dabei ausgestellte Session ab. Was er stiehlt, ist kein Geheimnis, das man rotieren könnte, sondern ein bereits eingelöster Berechtigungsnachweis.

Der Effekt ist unangenehm konkret. Ein gültiges Primary Refresh Token, kurz PRT, ist für den Ressourcenserver von einer legitimen Sitzung nicht zu unterscheiden. Es wurde korrekt ausgestellt, es trägt die richtigen Claims, und es übersteht jede erneute Conditional-Access-Auswertung, die keine frische Interaktion erzwingt. Der Angreifer muss sich nie wieder anmelden. Er nutzt einfach weiter.

Die letzte Zeile ist der eigentliche Punkt dieses Artikels. Die Telemetrie ist vorhanden. Sie liegt nur nicht dort, wo die meisten Detections hinschauen.

Vom Phishing-Proxy zum Primary Refresh Token

Der Ablauf ist seit den ersten breit dokumentierten AiTM-Kampagnen stabil geblieben, weil er an der Mechanik der Sitzung ansetzt und nicht an einer einzelnen Schwachstelle. Das Opfer erhält einen Link, der auf eine vom Angreifer betriebene Proxy-Infrastruktur zeigt. Diese Infrastruktur spiegelt die echte Anmeldeseite in Echtzeit — jede Eingabe wird an den legitimen Endpunkt weitergereicht, jede Antwort zurück an das Opfer.

Aus Sicht des Opfers funktioniert alles korrekt: die vertraute Oberfläche, die MFA-Aufforderung, die Bestätigung. Aus Sicht von Entra ID ist die Anmeldung ebenfalls valide, denn sie kommt tatsächlich vom echten Nutzer, nur eben über einen zwischengeschalteten Kanal. Am Ende dieses Flows hält der Angreifer die ausgestellten Session-Cookies beziehungsweise, im Fall eines registrierten Geräts, Material zur Nutzung eines PRT.

Warum das PRT die interessantere Beute ist

Session-Cookies sind an den Browser gebunden und laufen vergleichsweise zügig ab. Ein Primary Refresh Token ist der Generalschlüssel der Geräteebene: langlebig, an das Gerät und den Nutzer gekoppelt, und in der Lage, fortlaufend Access Tokens für beliebige Ressourcen auszustellen, ohne dass eine neue interaktive Anmeldung nötig wäre. Wer ein PRT kontrolliert, braucht die Anmeldeseite nie wieder zu sehen.

Der entscheidende Perspektivwechsel für die Detection: Nach dem initialen Diebstahl verschwindet der Angreifer aus dem interaktiven Anmeldepfad. Alle weiteren Zugriffe erscheinen als nicht-interaktive Anmeldungen — Token-Erneuerungen und Ressourcenzugriffe, die im Betrieb völlig unauffällig aussehen, weil genau so auch legitime Clients arbeiten.

Was Conditional Access noch sieht — und was nicht

Conditional Access ist eine präventive Kontrolle am Anmeldeereignis. Ihre Wirksamkeit gegen AiTM hängt vollständig davon ab, ob die Bedingung im Moment der Token-Nutzung überhaupt erneut ausgewertet wird. Bei einem gestohlenen, bereits ausgestellten Token ist das häufig nicht der Fall — und dann greift die Richtlinie ins Leere.

Nicht jede Kontrolle ist gleich wirkungslos. Die Unterscheidung, welche Maßnahme den Diebstahl erschwert und welche nur den ersten Login absichert, ist die Grundlage jeder ehrlichen Risikobewertung.

Die praktische Konsequenz: Wer AiTM adressieren will, verschiebt Budget von generischer MFA-Abdeckung hin zu phishing-resistenten Verfahren und Gerätebindung. Alles andere ist Detektion nach dem Ereignis — notwendig, aber nachgelagert. Und genau diese Detektion ist der Teil, den die meisten Setups gar nicht erst instrumentieren.

Die Signale liegen im nicht-interaktiven Log

Wenn die Prävention umgangen ist, bleibt die Frage: Woran erkennt man den Missbrauch? Die Antwort beginnt mit einer Verschiebung des Blickfelds. Die meisten Detections werten SigninLogs aus — das interaktive Anmeldelog. Die relevante Aktivität nach dem Token-Diebstahl liegt jedoch in AADNonInteractiveUserSignInLogs, das um Größenordnungen mehr Einträge führt und deshalb oft aus Kostengründen gar nicht erst ausgewertet wird.

Der erste Ansatz sucht nach nicht-interaktiven Anmeldungen, denen keine passende interaktive Anmeldung von derselben Identität und IP gegenübersteht. Ein legitimer Client, der ein Token erneuert, hat sich vorher irgendwann interaktiv angemeldet. Ein gestohlenes Token, das von fremder Infrastruktur genutzt wird, hat das nicht.

Der Filter auf mehr als fünf Anmeldungen unterdrückt vereinzeltes Rauschen. In der Praxis lohnt es sich, zusätzlich bekannte Service-IPs und Ausgangs-Proxies des eigenen Netzes auszuschließen, damit legitime zentrale Gateways nicht dauerhaft als Treffer erscheinen.

Der zweite Ansatz betrachtet die geografische Streuung erfolgreicher MFA-Anmeldungen in einem engen Zeitfenster. Ein Token, das an mehreren Orten gleichzeitig verwendet wird, ist ein starkes Signal — unabhängig davon, ob der eigentliche Diebstahl schon sichtbar war.

Beide Abfragen liefern Kandidaten, keine Urteile. Ihre Aussagekraft und ihr False-Positive-Risiko unterscheiden sich deutlich — und diese Einordnung gehört in die Detection-Dokumentation, nicht in den Kopf einer einzelnen Person.

In Sentinel wird aus Kandidaten ein Vorfall

Einzelsignale erzeugen Alarm-Müdigkeit. Der Mehrwert entsteht in der Korrelation: Eine risikobehaftete Anmeldung für sich ist ein Kandidat. Eine risikobehaftete Anmeldung, gefolgt von der Registrierung einer neuen MFA-Methode durch dieselbe Identität innerhalb weniger Minuten, ist ein Muster, das legitime Nutzer praktisch nie erzeugen — und Angreifer fast immer, weil sie sich Persistenz sichern wollen.

Das Zeitfenster von 30 Minuten ist bewusst eng gewählt. Es korreliert nicht irgendeine spätere Methodenregistrierung, sondern nur solche, die dem verdächtigen Login unmittelbar folgt. Dadurch bleibt die Regel scharf genug, um ohne Tragästchen als Analytics Rule mit hoher Priorität zu laufen.

Ein zweites, komplementäres Signal zielt direkt auf das Token: Ressourcenzugriffe auf Exchange Online oder Microsoft Graph, die von keinem registrierten Gerät ausgehen. Legitime verwaltete Clients tragen eine Geräte-ID; ein von fremder Infrastruktur genutztes Token häufig nicht.

Diese Abfrage ist bewusst als Near-Real-Time-Kandidat formuliert — enges Zeitfenster, klarer Schwellwert. In einer Umgebung mit durchgängiger Geräteregistrierung ist das leere DeviceId-Feld ein bemerkenswert sauberes Signal.

Was heute Konsequenzen hat

Detektion ohne Reaktionsplan ist Dokumentation eines Vorfalls, nicht seine Eindämmung. Bei bestätigtem Token-Diebstahl reicht das Zurücksetzen des Passworts nicht — das Refresh Token bleibt gültig. Die Reihenfolge der Gegenmaßnahmen ist entscheidend und sollte vor dem ersten Ernstfall festgelegt sein.

• Refresh Tokens widerrufen. Der einzige Schritt, der ein gestohlenes PRT tatsächlich entwertet. Passwort-Reset allein lässt den Angreifer im System.
• Registrierte MFA-Methoden prüfen. Neu hinzugefügte Methoden nach dem Vorfall sind Persistenz und gehören entfernt, bevor der Zugang wiederhergestellt wird.
• Geräteregistrierungen kontrollieren. Ein während des Vorfalls neu registriertes Gerät verlängert den Zugriff über die Token-Invalidierung hinaus.
• Blast Radius bestimmen. Welche Ressourcen hat das Token in seinem Gültigkeitsfenster berührt? Diese Frage steuert den Umfang der Aufarbeitung.

Präventiv führt der Weg zu phishing-resistenter Authentifizierung, Token Protection und konsequenter Gerätebindung — jede Maßnahme verkleinert das Fenster, in dem ein gestohlenes Token überhaupt nutzbar ist. Keine davon macht Detektion überflüssig; sie verschieben nur das Gleichgewicht zurück in Richtung Verteidiger.