In vielen Tenants, die ich mir anschaue, begegnet mir AiTM-Phishing seit dem vergangenen Jahr immer öfter, und zwar keineswegs nur als theoretische Bedrohung. Die Angreifer arbeiten mit ausgefeilten Phishing-Kits, die die Anmeldung bei Microsoft 365 so glaubwürdig nachbauen, dass selbst erfahrene Nutzer nach der Multi-Faktor-Authentifizierung ihre Sitzung an sie verlieren können. Es geht ihnen um den Session-Cookie, mit dem sie auf Postfächer, Daten und administrative Funktionen zugreifen. Sobald sie das Token haben, legen sie oft unmittelbar los. Sie erstellen Inbox-Regeln, die ihre Aktivitäten verbergen, registrieren neue MFA-Methoden und bereiten gezielte BEC-Angriffe (Business Email Compromise) vor.
Ein Phishing-Proxy fängt nach der MFA den Session-Cookie ab
Das Prinzip dahinter ist simpel, wirkt aber erschreckend gut. Das Phishing-Kit sitzt als Proxy zwischen dem Benutzer und der echten Anmeldeseite von Microsoft 365. Jede Eingabe, jeder Klick und jede MFA-Bestätigung erreicht zwar den legitimen Dienst, läuft aber gleichzeitig über die Infrastruktur des Angreifers, der alles mitschneidet. Ist die Anmeldung samt MFA abgeschlossen, zieht er den Session-Cookie aus dem Datenstrom und setzt ihn direkt in seinem eigenen Browser ein. So tritt er als das Opfer auf, ohne das Passwort zu kennen und ohne eine weitere MFA-Bestätigung zu benötigen. Perfide ist vor allem, dass die Täter nach dem Zugriff häufig gleich Regeln anlegen, die eingehende Mails weiterleiten oder verstecken. Damit verschleiern sie ihre nächsten Schritte.
Das folgende Mermaid-Diagramm zeigt den Ablauf in vereinfachter Form:
flowchart TD
User["Benutzer"] --> PhishProxy["Phishing-Proxy"]
PhishProxy --> Real365["Microsoft 365-Anmeldeseite"]
Real365 --> PhishProxy
PhishProxy --> User
PhishProxy -- "Cookie wird gestohlen" --> Attacker["Angreifer-Browser"]
Attacker --> Real365["Microsoft 365-Anmeldeseite"]
Abbildung: So läuft ein AiTM-Phishing-Angriff ab, bei dem nach der MFA die Sitzung gestohlen wird.
In der Praxis ist das oft eine Sache von wenigen Sekunden. So schnell reagiert weder eine klassische Erkennung noch der Benutzer selbst.
Phishing-resistente MFA und Token Protection erschweren den Angriff
Spreche ich Organisationen auf diese Angriffswege an, folgt prompt die Frage, wie man sich wirksam schützt, denn MFA allein genügt offensichtlich nicht mehr. Den größten Unterschied macht hier phishing-resistente MFA, also FIDO2-Sicherheitsschlüssel, Windows Hello for Business oder zertifikatbasierte Authentifizierung. Diese Verfahren verhindern, dass sich ein gestohlener Cookie in einem anderen Kontext erneut verwenden lässt. In Entra ID setzt man das über die Authentifizierungsstärken in Conditional Access durch. In vielen Projekten verlange ich diese Authentifizierungsstärken konsequent, vor allem für privilegierte Rollen und besonders schützenswerte Gruppen, und erlebe, wie die Angriffsfläche dadurch spürbar schrumpft.
Hinzu kommt die Prüfung des Gerätestatus. Wer in Conditional Access ein konformes Gerät oder ein per Microsoft Entra Hybrid Join eingebundenes Gerät voraussetzt, legt die Latte für Angreifer höher, denn über verwaltete Endpunkte verfügen sie in aller Regel nicht. Noch recht neu ist Token Protection für Conditional Access, die sich im März 2024 noch in der Preview befindet. Sie sorgt unter Windows und für bestimmte Apps dafür, dass ein Token nicht auf einem anderen Gerät wiederverwendet werden kann. Details findet ihr in der offiziellen Dokumentation von Microsoft.
Sinnvoll ergänzen lässt sich das durch:
- Sign-in Frequency in Conditional Access für besonders riskante Szenarien
- Richtlinien in Entra ID Protection für risikobasierte Authentifizierung und automatische Sperren
- Continuous Access Evaluation (CAE), damit Änderungen an Sitzungen oder Sperren zeitnah greifen
- Automatic Attack Disruption in Microsoft Defender XDR, die kompromittierte Konten bei erkannten AiTM-Mustern automatisch einfriert (mehr dazu in meinem Beitrag zum Einstieg in Defender XDR)
- die Überwachung verdächtiger Posteingangsregeln und geänderter MFA-Methoden
Praktischer Tipp: In vielen Tenants kontrolliert bislang niemand, ob Inbox-Regeln neu angelegt oder geändert werden. Mit einem einfachen Exchange-Online-Befehl spürt man verdächtige Regeln schnell auf:
Get-InboxRule -Mailbox <user> | Where-Object { $_.RedirectTo || $_.ForwardTo || $_.DeleteMessage }
Vor allem automatische Weiterleitungen und Löschregeln in Benutzerpostfächern gehören grundsätzlich auf den Prüfstand.
Im Ernstfall zählt eine schnelle und vollständige Reaktion
Prävention ist wichtig, doch lückenlos ist kein Schutz. Kommt ein AiTM-Phishing-Angriff trotzdem durch, muss es schnell gehen. Bewährt haben sich in der Praxis folgende Schritte: alle aktiven Sitzungen des kompromittierten Kontos widerrufen, das Kennwort zurücksetzen, verdächtige Regeln und Weiterleitungen im Postfach entfernen und sämtliche neu registrierten MFA-Methoden überprüfen (und gegebenenfalls löschen). Entra ID liefert dafür inzwischen aussagekräftige Audit-Logs, und auch die automatisierte Erkennung in Defender XDR wird laufend besser. Besonders wichtig ist, zeitnah mit dem betroffenen Nutzer zu sprechen, damit sich Folgeschäden wie BEC früh abwenden lassen.
Aus der MFA-Illusion muss eine echte Zero-Trust-Abwehr werden
AiTM-Phishing zeigt für mich beispielhaft, wie schnell sich Angreifer auf neue Schutzmaßnahmen einstellen. Dass ein einmaliger MFA-Code nicht mehr genügt, hat sich in vielen Organisationen inzwischen herumgesprochen, spätestens nach den ersten Vorfällen. Wer sich ernsthaft schützen will, darf MFA nicht bloß einführen. Sie muss phishing-resistent sein und im Sinne moderner Zero-Trust-Prinzipien durchgesetzt werden. Authentifizierungsstärken, Gerätestatus, Token Protection und kontinuierliche Überwachung greifen allmählich ineinander, auch wenn manchen Bausteinen technisch wie organisatorisch (noch) die nötige Reife fehlt. Wer die Sicherheit von Microsoft 365 verantwortet, hat mit AiTM-Phishing auch 2024 eine akute Herausforderung vor sich. Mit den richtigen Maßnahmen ist man ihr aber nicht hilflos ausgeliefert.


