Ende Juni bis Anfang Juli 2026 wurde eine Phishing-Kampagne über den Mechanismus Device Code Flow beobachtet, die auf Konten von Microsoft 365 abzielte. Nach Angaben von ZeroBEC nutzten die Angreifer Köder in Form von Einladungen zur Zusammenarbeit und leiteten die Opfer auf eine legitime Microsoft-Anmeldeseite, statt auf ein gefälschtes Passwortformular. Parallel dazu hat Cisco Talos mit ARToken ein voll funktionsfähiges Operator-Panel für ähnliche Angriffe offengelegt. Diese Ereignisse deuten auf einen grundlegenden Wandel hin: Die Technik des device code phishing hat sich von einem Einmal-Trick zu einem marktreifen Produkt im Segment „Phishing as a Service“ (PhaaS) entwickelt, das Multi-Faktor-Authentifizierung umgehen und eine vollständige Kontoübernahme ermöglichen kann.
Wie device code phishing funktioniert
Der Angriff basiert auf einem legitimen Mechanismus von OAuth 2.0 – dem Device Authorization Grant. Laut Dokumentation von Microsoft ist dieser Flow für Geräte mit eingeschränkter Benutzeroberfläche gedacht – Smart-TVs, Drucker, IoT-Geräte –, die kein Standard-Loginformular anzeigen können. Der Nutzer erhält auf dem Gerät einen kurzen Code, gibt ihn auf einem anderen Gerät im Browser ein und autorisiert damit die Sitzung.
Die Angreifer missbrauchen genau diese Trennung: Sie initiieren den Autorisierungs-Flow eigenständig, erhalten einen Code und übermitteln ihn dem Opfer per Phishing-E-Mail. Gibt der Nutzer den Code auf der legitimen Seite microsoft.com/devicelogin ein, autorisiert er unbewusst die Sitzung des Angreifers. Wie Forscher von Huntress anmerken, „bricht der Angriff nicht in das System ein, sondern nutzt die Vordertür – ohne Passwort, unter Umgehung von MFA, wobei das Session-Token direkt an den Angreifer übergeben wird“.
Der wesentliche Unterschied zu klassischem Phishing: Es gibt hier keine gefälschten Login-Seiten und kein Abgreifen von Zugangsdaten über Proxys (AitM). Das Opfer interagiert ausschließlich mit der echten Microsoft-Infrastruktur, was den Angriff für Standard-Schutzmechanismen äußerst schwer erkennbar macht.
Evolution der Technik: dynamische Generierung und PhaaS
Nach Angaben von Proofpoint (Mai 2026) wird in den meisten aktuellen Angriffen der Code dynamisch in dem Moment generiert, in dem das Opfer auf den Phishing-Link klickt. Dadurch entfällt die zeitliche Beschränkung der Gültigkeit des Codes: Die E-Mail kann jederzeit geöffnet werden, und die Angriffskette startet dann erneut. Proofpoint stellt außerdem fest, dass Implementierungen von device code phishing über PhaaS-Plattformen wie EvilTokens und Tycoon 2FA verfügbar sind oder von den Operatoren selbst entwickelt werden.
Zusätzlich setzen die Angreifer die Technik des „Sprungs über kompromittierte Konten“ (ATO jumping) ein: Ein kompromittiertes Konto wird genutzt, um Phishing-Links an die Kontakte des Opfers zu verschicken – in Form von Buttons, Hyperlinks, Anhängen oder QR-Codes. Das vervielfacht die Reichweite der Kampagne und erhöht das Vertrauen der Empfänger in die E-Mail.
Bezug zu Storm-2372 und Entstehung eines Tool-Ökosystems
Nach Einschätzung von ZeroBEC weist die beobachtete Kampagne erhebliche Überschneidungen mit Aktivitäten auf, die Microsoft im Februar 2025 unter der Kennung Storm-2372 dokumentiert hat. Damals nutzte die Kampagne Köder im Stil von Microsoft Teams, um Device Codes von Opfern zu erhalten. Die Forscher betonen jedoch, dass die Übereinstimmung der Taktiken nicht bedeutet, dass es sich um dieselben Operatoren handelt – vielmehr geht es um die Verbreitung eines bestimmten Sets an Vorgehensweisen (tradecraft), das nun in wiederverwendbare Infrastruktur verpackt wird.
Parallel dazu hat Cisco Talos das Operator-Panel ARToken identifiziert, das nach Angaben der Forscher Infrastruktur und API-Verträge mit der Plattform EvilTokens teilt. Das Panel stellt mehr als 80 API-Endpunkte für device code phishing, das Aufrechterhalten des Zugriffs über Primary Refresh Token (PRT), E-Mail-Funktionen, BEC-Operationen und die Exfiltration von Daten aus SharePoint bereit – alles über ein React-Interface. Ein separates Tool namens ARTBrowser ermöglicht es Operatoren, Microsoft-365-Sitzungen der Opfer außerhalb des Panels einzusehen.
Nach Angaben von Sekoia enthält die Plattform EvilTokens KI-gestützte Funktionen zur Automatisierung von BEC-Operationen: die Analyse Tausender abgefangener E-Mails, das Erkennen finanzieller Korrespondenz und das Generieren betrügerischer Nachrichten. Das zeugt von der Reife des Ökosystems – es geht nicht mehr um einzelne Phishing-Kits, sondern um vollwertige Plattformen für Business-Kompromittierung.
Diese Tendenz bestätigt auch ein Bericht von eSentire: Die Betreiber von Tycoon 2FA, die zuvor auf AitM-Phishing spezialisiert waren, haben ihr Kit auf die Auslieferung von device code phishing über den OAuth-Flow von Microsoft umgerüstet.
Betroffene Produkte und Umfang der Auswirkungen
Gefährdet sind alle Organisationen, die Folgendes einsetzen:
Ein erfolgreicher Angriff kann zur vollständigen Übernahme des Kontos, zum Diebstahl vertraulicher Daten, zu Betrug im Rahmen von BEC, zu lateraler Bewegung innerhalb der Organisation und im Extremfall zur Verteilung von Ransomware führen. Besonders verwundbar sind Organisationen, in denen device code flow auf Mandantenebene ohne zusätzliche Beschränkungen durch Conditional Access erlaubt ist.
Es ist wichtig zu berücksichtigen: Das tatsächliche Ausmaß der Auswirkungen hängt vom Scope der ausgestellten Tokens, den Einstellungen für Conditional Access und den Richtlinien des Mandanten ab. Aussagen über eine „vollständige Umgehung von MFA“ sind nur im Kontext delegierter Authentifizierung korrekt – der Angriff bricht MFA nicht als solche, sondern nutzt einen legitimen Flow, in dem MFA bereits vom Nutzer durchlaufen wurde.
Praktische Empfehlungen
- Begrenzen Sie Device Code Flow. Richten Sie in Microsoft Entra eine Conditional-Access-Richtlinie ein, die den Device Authorization Grant für alle Nutzer blockiert, außer für diejenigen, die ihn wirklich benötigen (Kiosks, IoT-Geräte). Dies ist die wirksamste Maßnahme.
- Richten Sie Monitoring für anomale Anmeldungen ein. Überwachen Sie Authentifizierungsereignisse vom Typ „Device Code“ in den Entra Sign-in Logs. Massige Anfragen nach Device Codes von untypischen IP-Adressen oder für Nutzer, die diesen Flow nicht benötigen, sind ein Hinweis auf eine Kompromittierung.
- Führen Sie Token-Protection-Richtlinien ein. Die Bindung von Tokens an bestimmte Geräte (token binding) in Entra verringert den Wert abgefangener Tokens für den Angreifer erheblich.
- Nehmen Sie eine Überprüfung der OAuth-Zustimmungen vor. Prüfen Sie die Liste der Anwendungen mit delegierten Berechtigungen im Mandanten. Widerrufen Sie verdächtige Zustimmungen, insbesondere solche mit Zugriff auf Mail.Read, Files.Read oder vergleichbare Scopes.
- Schulen Sie die Nutzer. Mitarbeitende müssen wissen, dass legitime Einladungen zur Zusammenarbeit in Microsoft 365 niemals die Eingabe eines device code erfordern. Jede Aufforderung, einen Code auf der Seite microsoft.com/devicelogin einzugeben, die aus einer E-Mail heraus initiiert wird, ist ein Anzeichen für einen Angriff.
- Begrenzen Sie ATO jumping. Konfigurieren Sie Transportregeln in Exchange Online, um Massenversand von kürzlich kompromittierten Konten zu erkennen und verdächtige Nachrichten automatisch in Quarantäne zu verschieben.
Die Entstehung vollwertiger PhaaS-Plattformen rund um device code phishing – ARToken, EvilTokens, der angepasste Tycoon 2FA – bedeutet, dass diese Technik kein exklusives Werkzeug fortgeschrittener Gruppen mehr ist, sondern einem breiten Spektrum von Operatoren zur Verfügung steht. Die zentrale Maßnahme für Verteidiger besteht darin, umgehend zu prüfen, ob device code flow im Microsoft-Entra-Mandanten erlaubt ist, und ihn für alle Nutzer zu blockieren, die ihn nicht für ihre Arbeit benötigen. Organisationen, die diesen Flow nicht einschränken, lassen faktisch eine Tür offen, durch die der Angreifer mit einem legitimen Token eintreten kann.
