AiTM-Phishing erkennen: Token-Replay in Entra ID finden

Kurz gesagt. Beim Adversary-in-the-Middle-Phishing (AiTM) meldet sich das Opfer über den Reverse Proxy des Angreifers an, der Passwort und MFA an Microsoft weiterreicht und das Sitzungscookie behält. Danach spielt der Angreifer diese Sitzung von seinem eigenen Rechner ab. In den Protokollen: eine interaktive Anmeldung aus dem Netz des Proxys (oft ein Hosting-Anbieter), dann nicht interaktive Anmeldungen mit derselben Session ID von einer anderen IP oder aus einem anderen Land, dann Einträge im Unified Audit Log mit passender AADSessionId. Eindämmen durch Widerrufen der Sitzungen, nicht nur durch ein neues Passwort; vorbeugen durch phishing-resistente MFA.

Microsoft beschrieb eine AiTM-Kampagne, die ab September 2021 versuchte, mehr als 10.000 Organisationen anzugreifen, wobei die Angreifer schon fünf Minuten nach dem Diebstahl von Anmeldedaten und Sitzung mit dem Zahlungsbetrug begannen. Seitdem sind solche Kits zur Massenware geworden. Die gute Nachricht für Ermittelnde: AiTM hinterlässt eine sehr charakteristische Spur, weil die gestohlene Sitzung von zwei Orten aus genutzt wird.

Wie der Angriff funktioniert

1. Das Opfer klickt auf einen Link zu einer Seite, die die echte Microsoft-Anmeldung durchreicht.
2. Es gibt sein Passwort ein und bestätigt die MFA. Der Proxy leitet beides an Entra ID weiter, das dem Proxy ein Sitzungscookie ausstellt; der Proxy gibt eine Kopie an das Opfer weiter. Aus Sicht des Opfers hat die Anmeldung funktioniert.
3. Das Kit speichert das Cookie (und oft das Passwort).
4. Der Angreifer importiert das Cookie in seinen Browser oder nutzt abgeleitete Token und greift auf Outlook im Web, Exchange und SharePoint zu, ohne erneut nach MFA gefragt zu werden.

MITRE ATT&CK beschreibt die Schritte als Adversary-in-the-Middle (T1557) und Use Alternate Authentication Material: Web Session Cookie (T1550.004).

Was die Protokolle zeigen

Entscheidend ist, dass jedes aus der ursprünglichen Anmeldung abgeleitete Token die Sitzungskennung erbt (Microsoft Learn, verknüpfbare Kennungen). Auch eine legitime Sitzung wechselt das Netz (Laptop vom Büro nach Hause), aber ein Sprung in ein anderes Land oder ein Hosting-Netz wenige Minuten nach einer Anmeldung aus einem Hosting-Netz lässt sich kaum harmlos erklären.

Microsofts Analyse einer mehrstufigen Kampagne vom Juni 2023 beschreibt genau diese Abfolge: das gestohlene Cookie Stunden später von einer IP in einem anderen Land abgespielt, dann eine neue MFA-Methode hinzugefügt (mit dem Hinweis, dass das Hinzufügen einer Methode standardmäßig keine erneute Authentifizierung erforderte), dann Regeln, die alle eingehenden E-Mails nach Archive verschieben und als gelesen markieren (Microsoft-Security-Blog).

Manuelle Suche, Schritt für Schritt

1. Beide Anmeldedateien exportieren (interaktiv und nicht interaktiv) für den ganzen Tenant, so weit zurück, wie die Aufbewahrung reicht (Export-Anleitung).
2. Nach Session ID gruppieren. Notieren Sie für jede Sitzung, wo sie begann: die IPs ihrer interaktiven Anmeldungen (oder ihres ersten Ereignisses).
3. Sitzungen markieren, die anderswo genutzt wurden: jede erfolgreiche Anmeldung der Sitzung von einer IP, deren Land oder ASN vom Ursprung abweicht. Ohne Land und ASN ist ein anderes /16 (IPv4) eine grobe, aber nützliche Näherung.
4. Priorisieren Sie Sitzungen, deren Ursprung ein Hosting-Netz ist und deren Replay aus dem Ausland kommt.
5. Ins UAL pivotieren über die Replay-IPs und die Session ID und die Aktionen auflisten (UAL-Untersuchung).
6. Andere Benutzer prüfen auf Anmeldungen von denselben Proxy- oder Replay-IPs: Kampagnen bleiben selten bei einem Postfach stehen.

Hat der Tenant Entra ID P2, helfen die Risikofelder: anomalousToken, unfamiliarFeatures und die benutzerbezogene Erkennung Attacker in the Middle, beschrieben auf Microsoft Learn. Microsoft weist darauf hin, dass Anomalous token auf niedriger und mittlerer Stufe überdurchschnittlich viele Fehlalarme erzeugt; prüfen Sie daher immer die Rohprotokolle.

Fehlalarme

Wie M365 Forensics es erkennt

Der Analysator im Browser setzt diese Suche als Befund „Eine Sitzung von mehreren Orten genutzt (Token-Wiederverwendung)“ (hoch) um: Für jede Session ID bilden ihre interaktiven Anmeldungen (oder das erste Ereignis) den Ursprung, und jedes erfolgreiche Ereignis derselben Sitzung von einer anderen IP zählt als Replay, wenn das Land abweicht, wenn die ASN abweicht, obwohl die Länder gleich oder unbekannt sind, oder wenn es in einem anderen /16 (/48 bei IPv6) liegt, sofern nichts anderes bekannt ist. Der Befund nennt Sitzung geöffnet von und Sitzung genutzt von.

Dann folgt die Korrelation: Jede UAL- oder Überwachungsaktion mit der wiederverwendeten Sitzung, der Replay-IP oder einem Token einer verdächtigen Anmeldung wird unter „Aktionen aus der Sitzung oder von der IP des Angreifers“ (kritisch) zusammengefasst. Als Marker dienen nur Anmeldebefunde, die die Anmeldung des Angreifers selbst abbilden (Hosting-Netz, wiederverwendete Sitzung, Gerätecode, riskante Anmeldung, MFA-Ermüdung mit anschließendem Erfolg); die unmögliche Reise nicht, weil eine ihrer beiden Anmeldungen vom Benutzer stammt. Der kommentierte fiktive Vorfall zeigt das Ergebnis an einem AiTM-Beispielfall.

Eindämmung und Vorbeugung

• Sitzungen widerrufen (Entra Admin Center → Benutzer → Revoke sessions oder Revoke-MgUserSignInSession). Das macht Aktualisierungstoken ungültig; Zugriffstoken können bis zu ihrem Ablauf gültig bleiben (standardmäßig eine Stunde), sofern die Anwendung keine fortlaufende Zugriffsevaluierung unterstützt.
• Entfernen, was der Angreifer hinzugefügt hat: MFA-Methoden, Posteingangsregeln und Weiterleitungen, App-Zustimmungen.
• Passwort zurücksetzen, von einem sauberen Gerät aus.
• Vorbeugen: phishing-resistente MFA (Passkeys / FIDO2, Windows Hello for Business, zertifikatbasierte Authentifizierung), bedingter Zugriff mit konformen oder hybrid eingebundenen Geräten und Tokenschutz, wo verfügbar. Microsofts Playbook zu Tokendiebstahl beschreibt Untersuchung und Reaktion im Detail.

Die vollständige Reihenfolge steht in Die erste Stunde nach einem BEC.

Häufige Fragen

Stoppt MFA das AiTM-Phishing?

Klassische MFA (Push, SMS, Codes) nicht. Der Proxy leitet den MFA-Schritt weiter und stiehlt das Sitzungscookie, das dessen Abschluss belegt. Phishing-resistente Methoden wie Passkeys, FIDO2-Sicherheitsschlüssel oder Windows Hello for Business sind an die echte Website gebunden und lassen sich so nicht weiterleiten.

Wo zeigt sich Token-Replay in den Protokollen?

In den nicht interaktiven Anmeldungen von Entra ID: Anmeldungen mit derselben Session ID wie die ursprüngliche interaktive Anmeldung, aber von einer anderen IP, einem anderen Netz oder Land. Mit der gestohlenen Sitzung ausgeführte Postfachaktionen tragen im Unified Audit Log dieselbe Kennung.

Reicht nach AiTM-Phishing ein Zurücksetzen des Passworts?

Nein. Widerrufen Sie die Sitzungen und Aktualisierungstoken des Benutzers, entfernen Sie jede vom Angreifer hinzugefügte MFA-Methode, Posteingangsregel, Weiterleitung oder App-Zustimmung und setzen Sie dann das Passwort zurück.

Weiterführende Links

• Microsoft Learn: Playbook zu Tokendiebstahl
• Glossar: Token-Replay, nicht interaktive Anmeldung, verknüpfbare Kennungen
• Analyse der Entra-ID-Anmeldeprotokolle für die übrigen Anmeldemuster.