Device Code, der zweite Login in Entra ID

Eine Mitarbeiterin bekommt eine Mail mit Rechnungsbetreff. Darin stehen ein kurzer Code und der Link microsoft.com/devicelogin. Sie gibt den Code ein und bestätigt MFA, die Anmeldung klappt. Am nächsten Morgen findet sie in ihrem Postfach Weiterleitungsregeln, die sie nie angelegt hat.

MFA hat dabei funktioniert. Entra ID kennt neben dem normalen Login einen zweiten Anmeldeweg, den Device Code Flow. Er ist für Geräte ohne Tastatur gebaut, also Teams-Räume, Digital Signage oder Shared Devices: Die Anmeldung startet auf einem Gerät und wird auf einem anderen bestätigt. Angreifer starten den Flow selbst und schicken dem Opfer nur den Code. Das Opfer meldet sich auf der echten Microsoft-Seite an, und die Tokens landen auf dem Gerät, das den Flow gestartet hat.

Was technisch passiert

Der Device Code Flow ist der OAuth 2.0 Device Authorization Grant aus RFC 8628. Der Ablauf hat drei Schritte:

Der Angreifer schickt einen POST an /oauth2/v2.0/devicecode und gibt dabei eine client_id und einen Scope an. Zurück kommen ein device_code, den er für sich behält, und ein user_code, der ins Phishing geht.
Das Opfer gibt den user_code auf microsoft.com/devicelogin ein und durchläuft die komplette Anmeldung einschließlich MFA.
In der Zwischenzeit fragt der Angreifer /oauth2/v2.0/token mit dem device_code ab. Sobald das Opfer bestätigt hat, erhält er Access Token und Refresh Token.

Drei Details machen den Angriff praktikabel:

Kein eigenes App-Registration nötig. Angreifer verwenden die Client-IDs von First-Party-Public-Clients wie Microsoft Office oder Azure CLI. In der Zustimmungsmaske sieht das Opfer deshalb eine Microsoft-App und kein unbekanntes Tool, und ein Consent-Dialog, der stutzig machen könnte, erscheint oft gar nicht.
Der Code läuft nach rund 15 Minuten ab. Deshalb erzeugen PhaaS-Kits den Code erst in dem Moment, in dem das Opfer die Phishing-Seite öffnet. Ein Code, der statisch in der Mail steht, wäre meist schon verfallen.
Das Refresh Token ist die eigentliche Beute. Mit ihm holt sich der Angreifer auch nach einer Passwortänderung weiter neue Access Tokens, bis jemand die Sessions widerruft. Bei passender Client-ID lässt es sich außerdem für weitere Ressourcen wie Graph, Exchange oder SharePoint einlösen.

Warum MFA hier nicht greift

Microsoft Threat Intelligence hat am 22. September 2026 eine Analyse zu EvilTokens veröffentlicht, einer Phishing-as-a-Service-Plattform für genau diesen Angriff. Microsoft zählt mehr als 12.000 kompromittierte Postfächer in über 10.000 Organisationen. EvilTokens ist ein käufliches Panel mit Token-Verwaltung, jeder mit Budget kann den Angriff also fahren.

MFA stellt fest, dass die richtige Person sich anmeldet. Wer die Sitzung danach bekommt, prüft sie nicht. Aus Sicht von Entra ID war das eine saubere Anmeldung mit starkem zweitem Faktor, und so steht sie auch im Log.

Was Conditional Access am Flow steuert

In Conditional Access gibt es unter Authentication Flows eine eigene Bedingung für den Device Code Flow. So gehen Sie vor:

In den Sign-in-Logs prüfen, wer den Flow heute nutzt. In Log Analytics oder Sentinel reicht dafür eine kurze Abfrage:
```
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode"
| summarize Anmeldungen = count(), Apps = make_set(AppDisplayName), IPs = make_set(IPAddress)
    by UserPrincipalName
| order by Anmeldungen desc
```
Ein Treffer aus einem Teams-Raum ist erwartbar. Ein normaler Mitarbeiter mit Azure CLI als App und einer IP, die nicht zum Unternehmen passt, verdient einen genaueren Blick.
Eine Policy im Modus Report-only anlegen und ein, zwei Wochen laufen lassen.
Auf Block stellen. Ausnahmen nur dokumentiert und eng halten, meist die Resource Accounts der Teams-Geräte, und diese zusätzlich auf bekannte Netze beschränken.

Microsoft Learn empfiehlt denselben Weg: möglichst flächendeckend sperren, Ausnahmen einzeln begründen.

Token Protection hilft zusätzlich. Sie bindet Sitzungs-Tokens an das Gerät, auf dem sie ausgestellt wurden, und verhindert, dass ein gestohlenes Token woanders abgespielt wird. Die Flow-Sperre ersetzt sie aber nicht. Beim Device-Code-Phishing gibt das Opfer die Sitzung des Angreifers selbst frei, das Token entsteht also schon auf dessen Gerät.

Falls es schon passiert ist, reicht ein Passwort-Reset nicht. Die Sessions müssen widerrufen werden (Revoke-MgUserSignInSession), außerdem gehören Posteingangsregeln, neu registrierte Geräte und MFA-Methoden des Kontos geprüft.

Wie sieht das bei Ihnen aus: Gibt es eine Policy, die den Device Code Flow sperrt, und steht sie auf Report-only oder On? Und welche Konten brauchen den Flow wirklich?