Storm-2372 nutzt Device-Code-Phishing gegen Microsoft-365-Tenants

In vielen Tenants, die ich betreue, ist die Anmeldung per Gerätecode (Device Code Flow) kaum ein Thema – jedenfalls so lange, bis ein Vorfall durch die Presse geht. Genau das ist jetzt mit der Phishing-Kampagne geschehen, die Microsoft unter dem Namen Storm-2372 beschreibt. Die Angreifer verschicken über Messenger gefälschte Meeting-Einladungen und bringen die Empfänger so dazu, einen Gerätecode auf einer Microsoft-Seite einzugeben. Angemeldet wird dabei kein legitimes Gerät, es geht allein darum, ein Access Token abzugreifen. Spätestens damit ist Device-Code-Phishing in der Praxis angekommen. Die Einzelheiten hat Microsoft im Microsoft Security Blog veröffentlicht. Wichtiger finde ich einen anderen Punkt: Wer den Device Code Flow für Endnutzer gar nicht aktiv einsetzt, ist deshalb noch lange nicht geschützt, weil Standardfreigaben und alte Integrationen häufig noch offen sind.

Angreifer nutzen die Trennung von Gerät und Browser gezielt aus

Das Vorgehen ähnelt sich fast immer. Per Social Engineering, meist über eine Direktnachricht in Microsoft Teams oder WhatsApp, wird die Zielperson aufgefordert, einen angezeigten Gerätecode auf https://microsoft.com/devicelogin einzugeben. Diesen Code hat der Angreifer zuvor über eine OAuth-Flow-Anfrage erzeugt, die auf sein eigenes Konto oder eine kompromittierte App zielt. Weil Gerät und Browser voneinander getrennt sind, glaubt das Opfer, eine ganz normale Anmeldung zu bestätigen. In den Entra-Logs taucht der Vorgang in der Regel als erfolgreiche Anmeldung mit dem Protokoll „Gerätecode“ auf. Bemerkenswert ist, dass der Phishing-Flow selbst keinen klassischen MFA-Prompt auslöst; die Angreifer bekommen ein gültiges Token und arbeiten damit weiter. Die Hintergründe und den Nutzen von Conditional Access in diesem Szenario habe ich bereits ausführlich in Device Code Flow blockieren: Schutz vor Phishing in Entra ID beschrieben.

Vereinfacht sieht ein typischer Angriff so aus:

sequenceDiagram
    Angreifer->>"Opfer": "Fake-Meeting-Einladung mit Gerätecode"
    Opfer->>"https://microsoft.com/devicelogin": "Gerätecode eingeben"
    "Microsoft.com"->>"Entra ID": "Authentifizierung mit Gerätecode"
    "Entra ID"-->>"Microsoft.com": "Token ausstellen"
    "Microsoft.com"->>Angreifer: "Token bereitstellen"

Abbildung: So läuft ein Device-Code-Phishing-Angriff nach dem Muster von Storm-2372 typischerweise ab.

Device-Code-Anmeldungen lassen sich im Entra Admin Center herausfiltern

Zuerst sollte man protokollieren und regelmäßig nachsehen, ob im Tenant überhaupt Device-Code-Anmeldungen vorkommen. Unter Microsoft Entra Admin Center → Überwachung & Status → Anmeldungen lassen sich genau diese Authentifizierungen gezielt anzeigen; dazu stellt man das Protokoll auf „Device code“. So fallen Auffälligkeiten schnell ins Auge, etwa eine plötzliche Häufung oder unbekannte Gerätecode-Anmeldungen von Konten außerhalb der IT. Wer genauer hinsehen möchte, öffnet die Details der einzelnen Anmeldungen und sucht nach Mustern bei Standort, Anwendung oder Uhrzeit. Ohne fortlaufende Überwachung geht es nicht, denn gestohlene Tokens werden oft lange unbemerkt missbraucht. Die wichtigsten Filteroptionen und Felder erklärt Microsoft in der Dokumentation.

Conditional Access sperrt den Device Code Flow mit einer einzigen Einstellung

Am wirksamsten ist es, den Device Code Flow per Conditional Access vollständig zu blockieren. Ausnahmen braucht es nur bei einem echten Anwendungsfall wie Teams Rooms oder bestimmten Kiosk-Geräten. Die passende Einstellung findet sich unter Bedingter Zugriff → Authentifizierungsflows → Gerätecode-Anmeldung blockieren. Allerdings steht sie nicht in jeder Lizenzstufe zur Verfügung, mindestens Entra ID P1 ist nötig. In der Praxis bezieht man alle Benutzergruppen ein und nimmt nur die Service-Accounts oder Geräte aus, die ausdrücklich auf den Flow angewiesen sind. Details und Ausnahmen beschreibt Microsoft in diesem Artikel.

Die Konfiguration der Richtlinie lässt sich anschließend etwa so überprüfen:

# PowerShell: Beispiel zur Policy-Überprüfung (MS Graph PowerShell, Entra ID P1 nötig)
Get-MgConditionalAccessPolicy | Where-Object { $_.Conditions.AuthenticationFlows.DeviceCodeFlow -eq 'block' }

Aus der Praxis: Nach der Einführung der Richtlinie empfehle ich, die Anmeldeprotokolle der letzten Wochen gezielt nach Device-Code-Versuchen zu durchsuchen. Häufig tauchen dabei Integrationen oder Benutzer auf, die niemand mehr auf dem Schirm hatte. Sie müssen dann entweder modernisiert oder ausdrücklich zugelassen werden.

Im Ernstfall müssen die Sitzungen sofort widerrufen werden

Ist es trotz aller Vorsicht zu einem Device-Code-Phishing gekommen, zählt jede Minute. Im Microsoft Entra Admin Center widerruft man die Sitzungen der betroffenen Benutzer über Benutzer auswählen → Sitzungen widerrufen. Außerdem gehört der Sicherheitsvorfall dokumentiert, und die betroffenen Personen sollten gezielt informiert werden. Erfahrungsgemäß fallen viele Angriffe erst durch ungewöhnliche Aktivitäten auf, zum Beispiel durch App-Zugriffe aus weit entfernten Ländern. Wer sich eingehender mit Token-Diebstahl beschäftigen möchte, findet mehr dazu in Token-Diebstahl nach MFA: Schutz in Microsoft 365.

Mit wenigen Maßnahmen schrumpft die Angriffsfläche deutlich

Device-Code-Phishing ist längst eine reale Bedrohung und kein theoretisches Schreckensszenario mehr. Mit wenigen gezielten Maßnahmen lässt sich die Gefahr aber deutlich eindämmen. Wer die technischen Schutzfunktionen nutzt und seine Protokolle regelmäßig auswertet, hat schon viel gewonnen. Werden die Nutzer zusätzlich für Social Engineering sensibilisiert, bleibt die Angriffsfläche im Tenant dauerhaft kleiner. Ich rate dazu, die eigenen Conditional-Access-Richtlinien noch heute zu prüfen. Der Device Code Flow sollte gezielt blockiert und nur dort erlaubt werden, wo er tatsächlich unverzichtbar ist.