In vielen Microsoft-365- und Azure-Tenants fällt mir seit einiger Zeit eine Häufung auf. Angreifer verschicken Device-Codes per Phishing-Mail und bitten den Empfänger, den Code auf microsoft.com/devicelogin einzugeben. Wer das tut, öffnet dem Angreifer das eigene Konto, selbst wenn eine starke Authentifizierung aktiviert ist. Aktuelle Phishing-Kampagnen nutzen den Device-Code-Flow ganz bewusst, um genau diese Schutzmechanismen auszuhebeln. Conditional Access kann den Flow zwar blockieren, auf dem Weg dorthin lauern aber einige Stolperfallen.

Der Device-Code-Flow ist ein ideales Werkzeug für Social Engineering

Ursprünglich sollte der Device-Code-Flow Geräten und Tools ohne eigenen Browser eine sichere Anmeldung ermöglichen. Man denke etwa an einen Smart-TV, der auf Microsoft 365 zugreifen soll. Weil der Benutzer den Code selbst eintippen muss, lässt sich der Flow allerdings hervorragend für Social Engineering missbrauchen. Der Angreifer meldet sich mit einer bösartigen App an, bekommt einen Device-Code und bringt den Benutzer dazu, ihn einzugeben. Kurz darauf hält er ein gültiges Token in den Händen. In den Sign-in-Logs taucht dieser Vorgang zwar auf, doch die Einträge gehen oft unter oder werden falsch gedeutet. Wer die technischen Hintergründe nachlesen möchte, findet sie unter https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows.

Conditional Access kann den Device-Code-Flow gezielt sperren

Vor einiger Zeit hat Microsoft Conditional Access um die Bedingung „Authentifizierungsflows“ erweitert, die sich derzeit noch in der Vorschau befindet. Mit ihr lassen sich der Device-Code-Flow und Authentication Transfer gezielt blockieren. Im Assistenten für Conditional-Access-Richtlinien steht die Option unter „Bedingungen > Authentifizierungsflows (Vorschau)“, wo man den Device-Code-Flow ausdrücklich auswählen und sperren kann. Den meisten Organisationen rate ich jedoch, vorher genau hinzuschauen, wo der Flow überhaupt verwendet wird. Einige legitime Szenarien hängen nämlich nach wie vor davon ab, darunter Teams-Rooms-Geräte, bestimmte PowerShell-Module und ältere CLI-Tools. Wer hier zu rigoros vorgeht, legt im schlimmsten Fall produktive Dienste lahm.

Die Anmeldeprotokolle zeigen, wer den Device-Code-Flow wirklich nutzt

Bevor eine blockierende Richtlinie aktiv wird, sollte feststehen, ob und wofür der Device-Code-Flow im Tenant genutzt wird. Im Microsoft Entra Admin Center geht man dazu auf „Anmeldung > Anmeldeprotokolle“ und filtert auf „Authentifizierungsprotokoll = Device code“. Werden die Protokolle über die Diagnoseeinstellung nach Log Analytics exportiert (vorausgesetzt sind eine Azure-Monitor-Lizenz und die Rolle „Log Analytics Reader“ oder höher), genügt dort eine einfache KQL-Abfrage:

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize Anzahl = count() by AppDisplayName, UserPrincipalName

Damit ist schnell zu erkennen, welche Anwendungen und Konten den Flow verwenden. In meinen Projekten stoße ich dabei am häufigsten auf Microsoft Teams Rooms, diverse Monitoring-Tools und hin und wieder auf administrative Skripte. Mit dem Blockieren sollte man erst beginnen, wenn alle legitimen Pfade bekannt sind.

Praxis-Tipp: Conditional-Access-Richtlinien für neue Flows teste ich grundsätzlich zuerst im Berichtsmodus. Dort sieht man sofort, welche Benutzer oder Systeme betroffen wären, und riskiert keine Ausfälle im laufenden Betrieb.

Die Richtlinie sollte zuerst im Berichtsmodus laufen

Angelegt wird die Richtlinie wie gewohnt im Entra Admin Center unter „Schutz > Conditional Access“. Dabei muss die Vorschaufunktion „Authentifizierungsflows“ aktiviert und ausdrücklich auf „Device Code Flow“ gesetzt werden. Zunächst steht die Richtlinie auf „Nur Bericht (Report-only)“, und man beobachtet einige Tage lang, was passiert. Welche Anmeldungen wären blockiert worden, und melden Anwender oder Geräte Fehler? Auf „Erzwingen“ stellt man erst um, wenn sicher ist, dass keine legitime Anwendung hängen bleibt.

In der Praxis hat sich folgender Ablauf bewährt:

  • Sign-in-Logs prüfen und legitime Device-Code-Flows identifizieren
  • Betroffene Anwendungen und Geräte dokumentieren
  • Conditional-Access-Richtlinie mit „Authentifizierungsflows (Vorschau)“ im Report-only-Modus konfigurieren
  • Auswirkungen beobachten (Sign-in-Logs, Support-Tickets)
  • Richtlinie auf „Erzwingen“ umstellen, sobald keine Probleme mehr zu erwarten sind

Das Diagramm zeigt in vereinfachter Form, wie Device-Code-Phishing technisch funktioniert:

flowchart TD
Angreifer["Angreifer fordert Device Code an"]
Nutzer["Nutzer erhält Code per Phishing-Mail"]
Eingabe["Nutzer gibt Code auf microsoft.com/devicelogin ein"]
Token["Token wird an Angreifer ausgegeben"]
Angreifer --> Nutzer --> Eingabe --> Token

Abbildung: Ablauf eines Device-Code-Phishing-Angriffs in der Praxis.

Legitime Ausnahmen brauchen eine eigene Regelung

Völlig verzichten lässt sich auf den Device-Code-Flow 2024 noch nicht überall. Teams Rooms mit älterem Versionsstand, manche spezialisierten Monitoring- oder Deployment-Tools und einzelne Skripte bleiben vorerst darauf angewiesen. Für solche Fälle empfiehlt sich eine gezielte Ausnahme in der Conditional-Access-Richtlinie, die beispielsweise nur für bestimmte Anwendungen oder Gerätegruppen gilt. Daneben lohnt die Prüfung, ob ein Umstieg auf moderne Authentifizierungsflows infrage kommt, etwa Interactive Browser oder Device Authentication mit Zertifikat. Mehr zu Ausnahmen in der Richtlinie beschreibt Microsoft unter https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows.

Blockieren lohnt sich, aber nur mit Augenmaß

Wer die Angriffe der vergangenen Monate verfolgt hat, weiß, dass Device-Code-Phishing längst keine bloße Theorie mehr ist. In den meisten Microsoft-365-Tenants halte ich es für richtig, den Device-Code-Flow zu blockieren, allerdings immer erst nach einer Analyse und mit Ausnahmen für produktive Szenarien. Die neue Bedingung „Authentifizierungsflows“ in Conditional Access bringt hier einen deutlichen Fortschritt, auch wenn sie noch als Vorschau läuft. Setzt man sie gezielt und zunächst im Report-only-Modus ein, wird der Tenant spürbar sicherer, ohne dass das Tagesgeschäft leidet. Weitere Tipps rund um Conditional Access habe ich im Beitrag Conditional Access in Entra ID: Best Practices zusammengestellt.