MFA-Phishing erkennen: AiTM, Token-Diebstahl und wie du ihn siehst

MFA-Phishing erkennen ist die Erkennung, die den gefährlichsten Irrtum vieler Organisationen adressiert: dass MFA vor Phishing schützt. Adversary-in-the-Middle-Angriffe brechen MFA nicht, sie umgehen sie, indem sie die Anmeldung in Echtzeit an die echte Seite weiterreichen und das fertige Sitzungscookie abgreifen. Der Angreifer meldet sich danach mit diesem Cookie an, ohne Passwort und ohne erneute MFA-Abfrage, und ist als der Benutzer im System. AiTM ist damit 2026 die dominierende Technik zur Kontoübernahme in der Cloud. Dieser Beitrag beschreibt, wie der Angriff funktioniert, warum das SOC die Anmeldung selbst kaum erkennt, welche Spuren die Token-Nutzung hinterlässt, eine Erkennungslogik mit Beispielabfragen, und warum die eigentliche Antwort in der Prävention liegt.

Was der Angreifer tut

Der Angreifer betreibt einen Reverse-Proxy, meist mit einem Werkzeug wie Evilginx, Modlishka oder Muraena, oder er kauft die Infrastruktur als Phishing-as-a-Service, etwa Tycoon 2FA oder Greatness. Das Opfer erhält eine Phishing-Mail und klickt auf einen Link, der auf den Proxy zeigt. Der Proxy spiegelt die echte Anmeldeseite, oft die von Microsoft 365, in Echtzeit: Was das Opfer sieht, ist die echte Seite, nur über den Server des Angreifers geleitet. Das Opfer gibt Benutzername und Passwort ein, bestätigt die MFA-Anfrage, und weil die MFA gegenüber der echten Seite abläuft, ist sie gültig. Im Moment des erfolgreichen Logins gibt die echte Seite ein Sitzungscookie aus, und genau dieses Cookie fängt der Proxy aus der Antwort ab. Der Angreifer importiert es in seinen Browser und ist angemeldet. In MITRE ATT&CK ist die Technik T1111 (Multi-Factor Authentication Interception). Wichtig für die Einordnung: AiTM schlägt bestimmte MFA-Arten, nicht MFA als Konzept. OTP-Codes und Push-Bestätigungen lassen sich weiterreichen; phishing-resistente Verfahren mit Ursprungsbindung nicht.

Warum das SOC die Anmeldung selbst kaum sieht

Das Unangenehme an AiTM ist, dass die Anmeldung des Opfers vollkommen normal aussieht: richtiges Passwort, erfolgreiche MFA, ein Anmeldeereignis wie jeden Tag. Die Quelladresse ist die des Proxys, was ein Signal sein kann, aber Angreifer nutzen oft Adressen, die unauffällig wirken, und Evilginx3 kann sogar das Tenant-Branding übernehmen, sodass auch der Benutzer nichts merkt. Microsoft und andere sind sich einig, dass Entra ID und die üblichen Sicherheitsprodukte den direkten Token-Diebstahl nicht verhindern; sie mindern das Risiko danach. Das SOC erkennt AiTM deshalb nicht an der Anmeldung, sondern an dem, was mit dem gestohlenen Token danach geschieht. Genau hier liegt die Erkennung.

Welche Spuren die Token-Nutzung hinterlässt

Das stärkste Einzelsignal ist der Wechsel der IP bei gleichbleibender Sitzung: Wenn ein Token von einer anderen Adresse verwendet wird als der, die es erhalten hat, ist das der Fingerabdruck des Replays. Die Details zu den Anmeldeprotokollen stehen im ausgebauten Abschnitt zu Entra ID in der Referenz zu den Event-IDs.

Erkennungslogik mit Beispielabfragen

Die Abfragen sind in Kusto-Syntax für die Entra-ID-Anmeldeprotokolle geschrieben, wie sie Sentinel und Defender verwenden; die Logik überträgt sich auf jedes SIEM, das die Protokolle aufnimmt.

Ein Konto, viele Nutzer von einer IP. Trifft ein Angreifer mit derselben Proxy-Infrastruktur mehrere Mitarbeiter, meldet sich eine IP an vielen Konten an, ähnlich wie beim Password Spraying, nur mit Erfolg:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == 0
| summarize Konten = dcount(UserPrincipalName), Liste = make_set(UserPrincipalName)
    by IPAddress
| where Konten >= 5
| order by Konten desc

Token einer Sitzung von einer neuen IP. Der Kern: Vergleiche die IP, die eine Sitzung authentifiziert hat, mit der IP, die dieselbe Sitzungs-ID später nutzt. Weicht sie ab, ist das ein Kandidat für Session-Hijacking:

SigninLogs
| where TimeGenerated > ago(1d)
| extend SessionId = tostring(parse_json(AuthenticationProcessingDetails))
| summarize IPs = dcount(IPAddress), IPListe = make_set(IPAddress)
    by UserPrincipalName, tostring(SessionId)
| where IPs > 1

Neue MFA-Methode kurz nach der Anmeldung. Der häufigste Persistenzschritt nach der Übernahme, aus dem Auditprotokoll:

AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName has "security info" or OperationName has "authentication method"
| project TimeGenerated, InitiatedBy, OperationName, TargetResources

Diese Abfragen sind Ausgangspunkte, keine fertigen Alarme; die Feldnamen und Strukturen in den Entra-ID-Protokollen ändern sich, weshalb sie vor dem Produktiveinsatz gegen die eigenen Daten geprüft werden müssen. Fertige, gepflegte Regeln für genau diese Muster liefern die Vorlagen in Sentinel und die Community; der Wert dieses Beitrags ist die Logik dahinter, nicht die exakte Syntax. Wie aus einer solchen Abfrage eine dauerhafte Regel wird, steht im Beitrag zu Sigma-Regeln.

Reaktion: das Token entwerten

Bei AiTM gilt eine Reihenfolge, die der Beitrag zum kompromittierten Konto im Detail beschreibt, mit einer Besonderheit: Ein Passwort-Reset allein reicht nicht, weil der Angreifer kein Passwort braucht, sondern ein gültiges Token hat. Der erste Schritt ist deshalb immer das Widerrufen aller aktiven Sitzungen, das die gestohlenen Cookies ungültig macht; erst danach kommen Passwort, MFA-Methoden, Postfachregeln, App-Berechtigungen und die Auswertung, worauf der Angreifer in der Zwischenzeit zugegriffen hat. Weil das Zeitfenster zwischen Token-Diebstahl und Widerruf entscheidet, wie viel Schaden entsteht, ist die schnelle Erkennung hier direkt Schadensbegrenzung.

Warum die eigentliche Antwort Prävention ist

Erkennung fängt AiTM nach dem Diebstahl; verhindern lässt es sich nur davor, und dafür gibt es zwei wirksame Hebel. Der erste ist phishing-resistente MFA: FIDO2-Sicherheitsschlüssel und Passkeys sind an den Ursprung der echten Seite gebunden, und ein Proxy auf einer fremden Domain kann diese Bindung nicht erfüllen. Das ist derzeit die einzige MFA-Art, die AiTM an der Wurzel stoppt, und die Migration kritischer Konten dorthin ist die wichtigste Einzelmaßnahme. Der zweite Hebel ist Token Protection im Rahmen des bedingten Zugriffs von Entra ID: Sie bindet das Sitzungstoken an das Gerät, dem es ausgestellt wurde, sodass ein von einem anderen Rechner wiedergespieltes Cookie nutzlos ist. Dazu kommen unterstützende Maßnahmen aus dem bedingten Zugriff, die das Risiko nach dem Diebstahl senken, ohne den Diebstahl selbst zu verhindern: Gerätekonformität verlangen, Anmeldungen aus Hosting-Netzen blockieren, kurze Token-Lebensdauern für riskante Sitzungen. Die Erkennung bleibt trotzdem nötig, weil die Migration Zeit braucht und nie jedes Konto erreicht.

Fazit

AiTM-Phishing ist der Beweis, dass MFA allein 2026 keine Garantie mehr ist: Wer nur ein Passwort und einen Code abfragt, lässt sich weiterreichen. Das Blue Team erkennt den Angriff nicht an der sauberen Anmeldung, sondern an der Token-Nutzung danach, vor allem am Wechsel der IP bei gleicher Sitzung und an den typischen nächsten Schritten. Die schnelle Erkennung und das sofortige Widerrufen der Sitzungen begrenzen den Schaden; verhindern lässt sich der Angriff nur durch phishing-resistente MFA und Token Protection. Für ein Blue Team ist AiTM damit der Fall, in dem Erkennung und Prävention zusammen gedacht werden müssen, weil keines von beiden allein reicht.