Device Code Phishing: Wenn der Angreifer Ihre M365-Session übernimmT, ganz ohne Passwort

Die meisten Phishing-Schulungen laufen auf denselben Merksatz hinaus: Schau auf die URL. Steht dort nicht `login.microsoftonline.com`, gib nichts ein. Der Rat ist richtig, aber gegen eine Angriffsmethode, die derzeit spürbar zunimmt, hilft er nicht: Device Code Phishing.

Der Grund: Das Opfer landet auf einer echten Microsoft-Seite, tippt sein Passwort in ein echtes Microsoft-Formular und bestätigt eine echte MFA-Anfrage. Trotzdem sitzt am Ende der Angreifer in der Session.

Wofür der Device Code Flow eigentlich gedacht ist

Der OAuth Device Authorization Grant löst ein legitimes Problem: Geräte ohne brauchbare Tastatur oder Browser, Smart-TVs, Konsolen, IoT-Geräte, aber auch Kommandozeilen-Tools wie die Azure CLI, sollen sich anmelden können. Statt eines Login-Formulars zeigt das Gerät einen kurzen Code an. Man öffnet auf dem Handy oder PC `microsoft.com/devicelogin`, gibt den Code ein, meldet sich an und das Gerät erhält seine Token.

Genau dieser Mechanismus lässt sich missbrauchen. Denn nirgends wird geprüft, ob das Gerät, das den Code angefordert hat, auch dem Benutzer gehört, der ihn bestätigt.

Der Ablauf des Angriffs

1. Code anfordern: Der Angreifer ruft mit einer Client-ID den `/devicecode`-Endpunkt von Entra ID auf. Er bekommt einen Benutzercode und die Verifizierungs-URL zurück.

2. Köder verschicken: Der Code wandert in eine Social-Engineering-Nachricht, eine angebliche Teams-Einladung, eine Meldung des IT-Supports, eine Aufforderung zur Aktivierung eines neuen Konferenzraum-Systems. Typisch ist die Formulierung: «Bitte öffnen Sie microsoft.com/devicelogin und geben Sie diesen Code ein.»

3. Opfer authentifiziert sich: Das Opfer folgt der Anleitung, auf der legitimen Microsoft-Seite. Benutzername, Passwort, MFA. Alles korrekt, alles unverdächtig.

4. Token abholen: Parallel pollt der Client des Angreifers den `/token`-Endpunkt. Sobald das Opfer bestätigt hat, erhält er das Access- und das Refresh-Token.

5. Persistenter Zugriff: Mit dem Refresh-Token bleibt der Zugang bestehen, auf Mail, Teams, SharePoint, OneDrive. Ein Passwortwechsel allein beendet die Session nicht zwingend.

Das Perfide daran: Der Angreifer erfährt das Passwort nie. Er braucht es auch nicht.

Warum MFA hier nicht rettet

MFA schützt gegen gestohlene Passwörter. Beim Device Code Phishing wird aber kein Passwort gestohlen, sondern eine vollständig und korrekt authentifizierte Session abgezweigt. Der Benutzer hat den zweiten Faktor selbst bestätigt, für eine Anmeldung, von der er annahm, sie sei seine eigene.

Auch die klassischen Erkennungsmerkmale für Phishing fallen weg: keine getippte Domain, kein Zertifikatsfehler, keine schlecht nachgebaute Login-Maske. Übrig bleibt eine einzige verdächtige Sache, dass jemand einen Code liefert, den man irgendwo eingeben soll. Genau das gehört in die Awareness-Schulung: Codes, die man auf Zuruf irgendwo eingeben soll, sind so heikel wie Passwörter.

Erkennung: Was in den Logs steht

Der entscheidende Anhaltspunkt liegt in den Entra-ID-Anmeldeprotokollen, im Feld `AuthenticationProtocol`. Anmeldungen mit dem Wert `deviceCode` sind grundsätzlich prüfenswert.

Wichtig für die Einordnung: Nicht jede Device-Code-Anmeldung ist ein Angriff. In den meisten Tenants gibt es legitime Fälle, Entwickler und Administratoren, die sich über Azure CLI, Microsoft Graph Command Line Tools, Az PowerShell oder AzCopy anmelden. Interessant wird es, wenn:

- eine unbekannte Drittanbieter-App den Flow nutzt,

- die Anmeldung aus einem ungewohnten Land oder IP-Bereich kommt,

- ein Benutzer betroffen ist, der beruflich keine CLI-Tools verwendet,

- der Fehlercode AADSTS50199 (CmsiInterrupt) unmittelbar von einem Erfolg gefolgt wird,

- danach auffällige Graph-Aktivität auftritt: Massen-Mailbox-Zugriffe, Suchläufe, neu angelegte Posteingangsregeln mit Weiterleitung nach aussen.

Auswertung per PowerShell

Zur Auswertung gibt es zwei fertige Skripte im GitHub-Repo zum Quellartikel:

`Get-DeviceCodePhishingReport.ps1` liest über Microsoft Graph alle Anmeldungen mit `AuthenticationProtocol = deviceCode`, gleicht das Gerät mit Intune ab und schreibt eine CSV sowie einen farbcodierten HTML-Bericht.

- Voraussetzung: Modul `Microsoft.Graph.Authentication`; Berechtigungen `AuditLog.Read.All`, `DeviceManagementManagedDevices.Read.All`, `GroupMember.Read.All`.

- Aufruf: `.\Get-DeviceCodePhishingReport.ps1 -LookbackDays 30`

- Eingrenzen auf eine Gruppe: `-GroupName "Finanzen"`; nur erfolgreiche Anmeldungen: `-SuccessfulOnly`; nur CSV: `-NoHtml`.

- Der Bericht klassifiziert automatisch: LOW für bekannte Microsoft-Werkzeuge, MEDIUM für Service- und Raumkonten, HIGH für unbekannte Apps, letztere zuerst prüfen.

- Zu beachten: Entra ID hält Anmeldeprotokolle nur 30 Tage vor (P1/P2) bzw. 7 Tage in der Gratis-Variante. Wer länger zurückschauen will, braucht einen Export ins SIEM.

`Invoke-DeviceCodeTriage.ps1` sammelt im konkreten Verdachtsfall die Artefakte auf dem Client: `dsregcmd`-Ausgabe, AAD-Eventlog, WAM-Cache und Browserverlauf.

Repository: <https://github.com/Imran76Awan/Daily-Tasks/tree/main/device-code-phishing-microsoft-365-entra>

Ein Hinweis aus der Praxis: Die Skripte stammen aus einem privaten Repository und verlangen weitreichende Graph-Leseberechtigungen. Vor dem produktiven Einsatz gehören sie durchgelesen, wie jedes Skript, das man mit Administratorrechten gegen den eigenen Tenant laufen lässt.

Vorbeugen statt suchen

Die wirksamste Massnahme ist, den Flow gar nicht erst zuzulassen. In Entra ID lässt sich der Device Code Flow über Conditional Access («Authentication flows» → Device code flow blockieren) unterbinden, idealerweise für alle Benutzer, mit einer eng gefassten Ausnahme für die Handvoll Administratoren und Entwickler, die ihn tatsächlich brauchen.

Ergänzend sinnvoll:

- Alarmierung im SIEM auf erfolgreiche `deviceCode`-Anmeldungen ausserhalb der Ausnahmegruppe.

- Im Verdachtsfall nicht nur das Passwort zurücksetzen, sondern die Refresh-Token widerrufen (`Revoke-MgUserSignInSession`) und die Postfachregeln prüfen.

- In der Awareness-Schulung den Fall explizit zeigen: Eine echte Microsoft-Seite ist kein Beweis dafür, dass die Anmeldung einem selbst gehört.

Fazit

Device Code Phishing verschiebt den Angriff von der gefälschten Seite auf den legitimen Prozess. Wer nur nach falschen URLs sucht, sieht ihn nicht. Die gute Nachricht: Der Flow ist in den meisten Organisationen kaum nötig, ein Conditional-Access-Block kostet wenig und schliesst die Lücke weitgehend. Und für die Frage, ob im eigenen Tenant bereits etwas gelaufen ist, genügt eine halbe Stunde mit dem Auswertungsskript.

---

Quelle und ausführliche technische Analyse: [Device Code Phishing in Microsoft 365 / Entra ID endpointweekly.com](https://endpointweekly.com/blog/device-code-phishing-microsoft-365-entra.html)