Eine Teams-Einladung landet in meinem Postfach — für ein Meeting, das ich nie angenommen habe. „Bitte bestätige deine Teilnahme unter microsoft.com/devicelogin mit dem Code JK7QH9XW." Die URL ist echt. Der Code ist echt. Wenn ich ihn eintippe, authentifiziert mein Passkey einen vollständig legitimen Login — und das resultierende Access-Token gehört dem Angreifer.
Das ist das Vorgehen von Storm-2372, einer Gruppe, die mit moderater Konfidenz Russland zugeordnet wird und sich seit August 2024 durch Microsoft 365 Tenants arbeitet. Bis März 2026 hat The Hacker News 340+ betroffene Organisationen in fünf Ländern dokumentiert. Die Technik trägt einen Namen, der harmlos klingt: Device Code Phishing.
Wofür der Device Code Flow eigentlich gedacht ist
Der Device Code Flow ist eine Sign-in-Methode für Geräte, die nicht ohne Weiteres ein Passwort abfragen können — Smart-TVs, IoT-Geräte, Command-Line-Tools, das Display im Konferenzraum. Er teilt das Login auf zwei Geräte auf. Das eingeschränkte Gerät startet den Flow und zeigt einen kurzen Code an. Anschließend öffnet der Nutzer microsoft.com/devicelogin auf seinem Telefon oder Laptop, gibt den Code ein und authentifiziert sich dort wie gewohnt. Sobald er den Login bestätigt, erhält das eingeschränkte Gerät im Hintergrund sein Access-Token, und ist angemeldet.
In der Praxis meldet dich so die Azure CLI an, so verbindet sich kubectl mit einem Cluster hinter Entra, so tritt das Konferenzraum-Display einem Teams-Meeting bei. Es ist ein realer, nützlicher Flow.
Die Seite, auf der der Nutzer unter microsoft.com/devicelogin landet. An die Browsersprache lokalisiert
Microsoft druckt direkt auf dieser Seite eine Phishing-Warnung: „Geben Sie keine Codes aus Quellen ein, denen Sie nicht vertrauen." Die Warnung ist ehrlich und benennt das Problem in einem Satz. Im Moment der Zustimmung hat der Flow nichts, worauf er sich verlassen könnte, außer dem eigenen Urteilsvermögen des Nutzers.
Warum FIDO2 hier nicht hilft
Passkeys sind phishing-resistent, weil sie an die exakte Domain der Login-Seite gebunden sind. Das schützt gegen gefälschte Microsoft-Seiten: Ein Passkey signiert schlicht nichts gegen microsoft-login.com. Im Device Code Flow gibt es aber keine gefälschte Domain. Der Nutzer ist tatsächlich auf microsoft.com/devicelogin, der Browser kommuniziert tatsächlich mit Microsoft, MFA wird tatsächlich erfüllt. Das Login ist echt.
Die Schwachstelle liegt nicht im Login selbst. Sie liegt im Schritt danach: in der Zustimmung. Der Nutzer gibt den Code ein in der Annahme, sein eigenes Gerät zu autorisieren. Der Flow hat keine Möglichkeit, ihm zu sagen, dass es anders ist. Und weil die Angreiferin den Flow auf ihrer Maschine gestartet hat, erhält sie den Device Code — was bedeutet, dass das resultierende Token in ihrer Session landet.
Aus Sicht von Entra sieht der Sign-in im Nachhinein einwandfrei aus: erfolgreich, MFA-bestätigt, Passkey-signiert. In den Logs fällt nur die Authentifizierungsmethode deviceCode auf — die in den meisten Tenants nicht überwacht wird, weil sie selten vorkommt.
Was der Angreifer erhält
Ein erfolgreiches Device Code Phishing liefert ein Access-Token, das ungefähr eine Stunde gültig ist, und — viel nützlicher — ein Refresh-Token, das je nach Tenant-Konfiguration bis zu 90 Tage gültig bleiben und gegen neue Tokens mit neuen Berechtigungen ausgetauscht werden kann. Damit hat der Angreifer alles, was das Opfer hat.
Storm-2372 wurde dabei beobachtet, genau das zu tun, was zu erwarten ist: Über die Microsoft Graph API das Postfach des Opfers nach Stichworten wie password, admin, secret, teamviewer, anydesk, ministry, gov zu durchsuchen und die passenden Nachrichten zu exfiltrieren. Lateral Movement erfolgt von dort aus per E-Mail aus dem nun kompromittierten Account an interne Kontakte. Die zweite Welle ist deutlich erfolgreicher, weil der Köder jetzt von einer vertrauenswürdigen Adresse in der eigenen Organisation des Opfers kommt.
Es gibt kein Phishing-Kit, das man fingerprinten könnte, keine bösartige Domain, die man blockieren könnte, keine Lookalike-Infrastruktur, die man abschalten könnte. Aus Sicht der Verteidigung passiert der gesamte Angriff innerhalb von Microsofts eigenem, legitimem Flow. Viele Admins wissen nicht von dieser Schwachstelle und erwarten spätestens bei der Verwendung von Passkeys, dass ohne Zugriff auf diese kein Login möglich ist.
Was tatsächlich hilft
Microsoft hat die Conditional-Access-Bedingung Authentication Flows 2024 allgemein verfügbar gemacht. Eine Policy, die den Device Code Flow blockiert, beendet das Problem für die meisten Tenants — Device Code wird in normalen Office-Workflows nicht verwendet. Legitime Anwendungsfälle (Konferenzraum-Displays, vereinzelte CLI-Tools) lassen sich über User-Exclusions herausnehmen. Seit Februar 2025 gibt es zusätzlich eine Microsoft-managed Policy, die diesen Block für Tenants aktiviert, die Device Code überhaupt nicht nutzen.
Die Policy selbst lässt sich in etwa fünf Minuten einrichten:
- Im Microsoft Entra Admin Center zu Protection > Conditional Access > Policies navigieren.
- New policy klicken und einen Namen vergeben, z.B. Block Device Code Flow.
- Unter Assignments > Users All users einbeziehen. Service-Accounts und Break-Glass-Accounts, die Device Code benötigen, sowie Nutzer mit CLIs, die darauf angewiesen sind, ausschließen.
- Unter Target resources All resources (früher All cloud apps) wählen.
- Unter Conditions > Authentication flows Configure auf Yes setzen und Device code flow auswählen.
- Unter Access controls > Grant Block access wählen.
- Enable policy zunächst auf Report-only setzen. Nach ein paar Tagen die Sign-in-Logs auf blockierte Sign-ins prüfen, die sich als legitim erweisen, betroffene Nutzer in die Exclusion-Liste aufnehmen und die Policy dann auf On schalten.
Microsoft hat eine Schritt-für-Schritt-Anleitung für dasselbe Vorgehen, falls du es mit einem offiziell dokumentierten Klickpfad abgleichen möchtest.
Awareness-Training ist die zweite Linie, nicht die erste. Zwei Jahre nach Beginn dieser Kampagne ist „sag deinen Mitarbeitenden, sie sollen keine Codes eingeben" ein Slogan, kein Control. Geschulte Mitarbeitende klicken trotzdem, wenn der Köder aus dem kompromittierten Postfach einer Kollegin oder eines Kollegen kommt — und die nächste Welle ist bereits KI-generiert und auf den Tenant zugeschnitten.
Die nächste Teams-Einladung in meinem Postfach werde ich lesen im Wissen, dass mein Passkey einen freundlichen Code nicht von einem unfreundlichen unterscheiden kann — und dass Conditional-Access mich trotzdem schützt.
