Das französische Unternehmen Lexfo hat drei aktive Phishingkampagnen gegen Microsoft 365 entdeckt, nachdem den Forschern ein Fehler eines Operators in die Hände gespielt hatte: Dieser hatte auf dem Angriffsserver einen Python-Webserver mit offenem Verzeichnislisting zurückgelassen. Die Kampagnen nutzten zwei grundsätzlich unterschiedliche Methoden zur Umgehung von Multi-Faktor-Authentifizierung (MFA) – Session-Proxys über Evilginx und den Missbrauch des legitimen OAuth Device Code Flow. Entscheidend ist, dass diese beiden Vektoren unterschiedliche Schutzmaßnahmen erfordern: FIDO2-Schlüssel blockieren den ersten, sind aber gegen den zweiten wirkungslos. Organisationen, die Microsoft 365 einsetzen, sollten ihre Conditional-Access-Richtlinien daraufhin prüfen, ob der Device Code Flow blockiert wird.
Wie die Infrastruktur aufgedeckt wurde
Nach Angaben der Forscher von Lexfo wurde Ende April 2026 im Rahmen eines routinemäßigen Internet-Scans ein Server unter der Adresse 185.163.204[.]7 (Budapest) entdeckt, auf dem ein Python-Webserver lief, gestartet mit dem Befehl python3 -m http.server 8080 – derselbe Eintrag fand sich auch in der Datei .bash_history. Das offene Verzeichnislisting enthielt Phishing-Konfigurationen, Protokolle abgefangener Zugangsdaten, Installer von Remote-Monitoring-und-Management-(RMM)-Werkzeugen, kombinierte Passwortlisten, Backup-Archive und Dateien mit Telegram-Sitzungen des Operators. Auf demselben Host liefen außerdem der Proxy Evilginx (adversary-in-the-middle) und die Remote-Access-Konsole SimpleHelp.
Ausgehend von diesem Fund identifizierten die Forscher drei separate Kampagnen, von denen jede ihre eigene Evilginx-Modifikation verwendete, geklont aus öffentlichen Repositories auf GitHub. Nach Angaben von Lexfo war die größte dieser Kampagnen über ein Jahr aktiv, und etwa 94 % der kompromittierten Konten gehörten zu geschäftlichen E-Mail-Postfächern.
Zwei Methoden zur Umgehung von MFA
Adversary-in-the-middle über Evilginx
Die erste Methode ist klassisches Proxying: Eine modifizierte Evilginx-Instanz fängt die Authentifizierungssitzung zwischen Opfer und Microsoft ab und erhält die Session-Cookies, nachdem der Nutzer selbst die MFA durchlaufen hat. Eine der entdeckten Modifikationen (von den Forschern „red-queen“ genannt) enthielt mehrere technische Verbesserungen: Umbenennung der HTML-Attribute crossorigin und integrity zur Umgehung von Subresource-Integrity-Prüfungen, eine URL-Rewrite-Engine in http_proxy.go zur Umgehung von pfadbasierten Erkennungen sowie das Vorbefüllen der E-Mail-Adresse des Opfers, um die Abbruchquote zu senken.
Besonders bemerkenswert ist die Einstellung der TTL (Time To Live) der abgefangenen Microsoft-Session-Cookies auf 31 536 000 Sekunden (ein Jahr). Nach Einschätzung von Lexfo bedeutet dies, dass eine abgefangene Sitzung selbst einen Passwort-Reset überdauern und über Monate aktiv bleiben kann – sofern keine Richtlinie für Continuous Access Evaluation (CAE) greift. Im Repository wurde ein abgefangener Microsoft-365-Cookie mit Gültigkeit bis zum 30. Juni 2027 gefunden. Dort lag auch ein vorkompilierter Binärdatei-Wrapper evilginx2.exe, der es Käufern ermöglicht, den Angriff ohne eigenen Build-Prozess zu starten.
Missbrauch des OAuth Device Code Flow
Die zweite Methode unterscheidet sich grundlegend und stellt eine größere Bedrohung für Organisationen dar, die FIDO2 oder passkeys eingeführt haben. Die dritte Modifikation („black-queen“) fängt überhaupt keine Passwörter ab. Stattdessen wird ein legitimer Mechanismus von Microsoft ausgenutzt – der OAuth Device Code Flow, der für Geräte ohne vollwertige Eingabeschnittstelle gedacht ist.
Der Angriff läuft folgendermaßen ab: Das Backend generiert einen echten Device Code, verpackt ihn in eine Phishing-Seite im Design von Microsoft Authenticator und leitet das Opfer auf die echte Seite microsoft.com/devicelogin weiter. Das Opfer gibt den Code ein, durchläuft die tatsächliche MFA-Authentifizierung auf der echten Microsoft-Website und autorisiert damit die Sitzung des Angreifers. Das Backend pollt den Token-Endpunkt und holt sich den Token genau in dem Moment, in dem die Authentifizierung abgeschlossen wird.
Der entscheidende Punkt: Ein FIDO2-Schlüssel oder passkey hilft hier nicht, weil das Opfer sich gegenüber der echten Microsoft-Infrastruktur authentifiziert. Die Bindung an den Origin (origin binding), die Evilginx stoppt, funktioniert korrekt – denn der Origin gehört in diesem Fall tatsächlich Microsoft. Microsoft hat diese Technik im Februar 2025 dokumentiert, und zwar im Zusammenhang mit der Kampagne Storm-2372, die mit moderater Sicherheit Russland zugeschrieben wurde. Seitdem hat sich die Technik weit über staatliche Operationen hinaus verbreitet.
Nach Angaben von Lexfo sind in den Protokollen des Telegram-Bots dieser Kampagne im Zeitraum von Juni 2025 bis Juli 2026 insgesamt 218 kompromittierte Konten aus einem Dutzend Ländern verzeichnet. Im Commit-Verlauf des Git-Repositories wurde eine Datei mit 97 aktiven Microsoft-Tokens gefunden, die drei Opfern zugeordnet waren – alle mit dem Flag autoRefresh, einige wurden bis zu 25-mal erneuert. Das Framework hielt die Sitzungen automatisch am Leben.
Kontext: Ökosystem und Ausmaß
Alle drei Operatoren nutzten Modifikationen des öffentlich verfügbaren Evilginx und keine Eigenentwicklungen. Die Forscher fanden Hinweise auf den Einsatz von KI bei der Entwicklung von Hilfscode: In zwei Commits eines Operators ist die Mitautorenschaft von Claude-Modellen vermerkt, ein anderer hatte im Repository eine Datei instructions.txt abgelegt – eine wörtliche Mitschrift einer Sitzung mit einem KI-Assistenten, die die Erstellung einer URL-Rewrite-Funktion dokumentiert. Microsoft hat den Einsatz von KI in ähnlichen Kampagnen mit Device Code Phishing im April 2026 gesondert beschrieben.
Im Juni 2026 beschrieb das Unternehmen SOCRadar ein Phishing-as-a-Service-Ökosystem namens The Quarry, das nach ihrer Einschätzung rund 200 Operatoren bediente. Die in dieser Untersuchung entdeckten Werkzeuge tauchten in den Kanälen dieses Ökosystems auf, was auf Verbindungen zum Provider hindeutet, auch wenn eine direkte Mitgliedschaft nicht zweifelsfrei belegt werden kann.
Praktische Empfehlungen
Die zwei Angriffsvektoren erfordern zwei unterschiedliche Verteidigungslinien:
- Gegen Evilginx (AiTM-Proxys): Einführung phishing-resistenter MFA – FIDO2-Schlüssel oder passkeys. Die Bindung der Authentifizierung an die Domain macht Proxying wirkungslos.
- Gegen Device Code Phishing: Blockierung des Device Code Flow über Conditional-Access-Richtlinien überall dort, wo dieser Flow nicht benötigt wird. Ausnahmen sind etwa Teams Rooms-Geräte und einige CLI-Tools. Testen Sie die Richtlinie vor der Einführung im Modus „report-only“.
- IP-Einschränkungen und CAE: Konfigurieren Sie standortbasierte Conditional-Access-Richtlinien und aktivieren Sie Continuous Access Evaluation, damit ein Token, der von einer nicht erlaubten IP verwendet wird, erneut geprüft wird, statt seine gesamte Lebensdauer auszuschöpfen.
Zur Erkennung:
- Überwachen Sie in den Entra-ID-Anmeldeprotokollen die Ausgabe von Refresh Tokens für die Client-ID von Microsoft Office
d3590ed6-52b3-4102-aeff-aad2292ab01c, insbesondere wenn dieser Desktop-Client in der Organisation nicht genutzt wird. Korrelieren Sie diese Einträge mit untypischen Quell-IP-Adressen. - Nutzen Sie das Feld
Original transfer methodin den Anmeldeprotokollen: Eine Sitzung, die über den Device Code Flow initiiert wurde, behält diese Kennzeichnung bei nachfolgenden Token-Erneuerungen bei, selbst wenn das aktuelle Authentifizierungsprotokoll sie nicht explizit ausweist. - Suchen Sie auf Endpunkten nach dem XEOX-Agenten unter dem Pfad
C:\Program Files (x86)\XEOX\xeox-agent_x64.exeund nach geplanten Aufgaben mit der Maske*XEOX*Agent*Watchdog*– dieses RMM-Werkzeug wurde zur Persistenz genutzt.
Indikatoren einer Kompromittierung laut Bericht: IP-Adresse 185.163.204[.]7, Domains picis[.]net und romnor[.]ca. Die Infrastruktur wird rotiert, daher sollten diese IOCs als Mittel zur Lokalisierung und nicht als langfristiger Schutz verstanden werden.
Die zentrale Erkenntnis dieser Untersuchung liegt nicht in den einzelnen Operatoren, sondern in einem systemischen Problem: Eine Organisation, die mit passkeys vollständig gegen AiTM-Phishing geschützt ist, bleibt gegenüber Device Code Phishing verwundbar, solange der entsprechende Authentifizierungsflow nicht blockiert ist. Prüfen Sie, ob eine Conditional-Access-Richtlinie existiert, die den Device Code Flow für alle Benutzer blockiert, die ihn nicht objektiv benötigen – es ist eine einzige Richtlinie, die einen Vektor schließt, dem selbst FIDO2 nichts entgegensetzen kann.
