Device-Code-Phishing funktioniert, weil sich das Opfer auf einer echten Microsoft-Seite anmeldet. Es gibt also keine gefälschte Anmeldeseite, die auffallen könnte, und keine ähnlich lautende Domain, die sich sperren ließe. Die praktikable Abwehr besteht darin, den Flow für alle abzuschalten, die ihn nicht benötigen. Microsofts eigene Empfehlung lautet, einer unilateralen Sperre des Device Code Flow so nah wie möglich zu kommen, und das gelingt mit einer einzigen Conditional-Access-Richtlinie.
Wofür der Device Code Flow gedacht ist
Der Flow existiert für Geräte, die keinen Browser haben oder sich nur umständlich bedienen lassen. RFC 8628 nennt Smart-TVs, Mediakonsolen, digitale Bilderrahmen und Drucker. Das Gerät zeigt keine Anmeldeseite an. Es fordert den Benutzer auf, auf einem anderen Gerät, etwa einem Smartphone, eine URL aufzurufen und einen kurzen Code einzugeben.
Der Client sendet seine Client-ID an den Authorization Server und erhält einen device_code, einen user_code, eine verification_uri und einen expires_in-Wert zurück. Während sich der Benutzer auf dem zweiten Gerät anmeldet, fragt der Client den Token-Endpoint mit dem device_code per Polling ab, bis er ein Access Token, einen Fehler oder die Anweisung zum Weiterwarten erhält.
In der Microsoft identity platform heißen die Endpoints /devicecode und /token. Laut Microsoft-Dokumentation hat der Benutzer standardmäßig 15 Minuten Zeit für die Anmeldung. Ein Refresh Token wird ausgestellt, wenn der angeforderte Scope offline_access enthielt.
Warum der Flow sich als Phishing eignet
Der Code wird vom Client angefordert. Angemeldet wird aber von demjenigen, der den Code in der Hand hält. Das Protokoll verlangt nicht, dass es sich um dieselbe Person handelt, und RFC 8628 führt „Remote Phishing" als Sicherheitsaspekt auf (Abschnitt 5.4).
Ein Angreifer kann sich deshalb als Gerät ausgeben. Er fordert mit einer client_id einen Code an (und mit einem scope, den der Microsoft-Endpoint verlangt) und schickt den user_code mit einem Vorwand an das Ziel. Das Opfer öffnet die echte Verifizierungsseite, meldet sich an und gibt den Code ein. Der Client des Angreifers, der die ganze Zeit per Polling nachfragt, erhält die Tokens.
Das Passwort gelangt nie auf eine vom Angreifer kontrollierte Seite. Deshalb haben Prüfungen, die auf Domains und URLs setzen, etwa unser Link-Checker, hier nichts zu beanstanden.
Der Angreifer bleibt dennoch auf das Opfer angewiesen. Das Ziel muss sich anmelden und den Code eingeben, bevor expires_in abläuft (standardmäßig 15 Minuten). Sonst scheitert das Polling mit expired_token. Nutzer persönlicher Konten werden zudem aufgefordert, sich erneut anzumelden und den angeforderten Berechtigungen zuzustimmen.
Für Schulungen gibt es einen nützlichen Anhaltspunkt. Microsoft unterstützt verification_uri_complete nicht, das optionale Feld, das den Code direkt in der URL überträgt. Das Muster, das Sie vermitteln sollten, lautet: „Jemand hat mir einen Code geschickt, den ich auf einer Microsoft-Anmeldeseite eingeben soll."
Device-Code-Anmeldungen erkennen
Microsoft empfiehlt eine Richtlinie, die die bestehende Nutzung des Flows überprüft, und genau das leistet der Report-only-Modus. Legen Sie die unten beschriebene Richtlinie im Report-only-Modus an und werten Sie die Ergebnisse zur Richtlinienauswirkung aus. So sehen Sie, wer und was blockiert worden wäre.
Für die laufende Suche filtern Sie die Entra-Anmeldeprotokolle (Sign-in Logs) nach Device-Code-Anmeldungen und gruppieren sie nach Benutzer und Anwendung. Dies ist eine Empfehlung aus der Praxis; die hier zitierten Microsoft-Seiten dokumentieren sie nicht. Eine Anmeldung von einem Benutzer, der kein Gerät und kein Tool nutzt, das den Flow verwendet, oder von einer Anwendung, die niemand benennen kann, verdient ein Gespräch. Fragen Sie den Benutzer, welche Nachricht er erhalten hat.
Den Flow mit Conditional Access blockieren
Die Klickfolge finden Sie in Microsofts Conditional-Access-Leitfaden. Melden Sie sich mindestens als Conditional Access Administrator an, gehen Sie zu Entra ID > Conditional Access > Policies und legen Sie eine neue Richtlinie an. Schließen Sie alle Benutzer und All resources ein. Setzen Sie unter Conditions > Authentication Flows die Option Configure auf Yes und wählen Sie Device code flow. Wählen Sie unter Grant die Option Block access und setzen Sie Enable policy auf Report-only. Stellen Sie die Richtlinie auf On, sobald Sie die Ergebnisse geprüft haben.
Dieselbe Seite behandelt auch das Blockieren des Authentication Transfer, mit dem Benutzer eine Anmeldung von einem PC auf ein Mobilgerät übertragen können. Dafür gilt dieselbe Bedingung Authentication Flows, entscheiden Sie darüber also in derselben Sitzung.
Microsofts Empfehlung lautet, den Flow nur in gut dokumentierten und abgesicherten Anwendungsfällen zuzulassen, etwa für Legacy-Tools, die sich nicht aktualisieren lassen.
Für alles, was bleiben muss, richten Sie eine eigene Ausschlussgruppe ein, deren Name ihren Zweck erkennen lässt. Halten Sie für jedes Mitglied einen Verantwortlichen und eine Begründung fest und prüfen Sie die Liste regelmäßig, wie Microsoft es rät. Nehmen Sie auch Ihre Notfallzugänge (Break-glass-Konten) von der Richtlinie aus, damit bei einer Fehlkonfiguration kein Lockout entsteht.
Außerdem weist Microsoft darauf hin, dass Aufrufe von Service Principals von Richtlinien, die auf Benutzer begrenzt sind, nicht blockiert werden. Microsoft empfiehlt, Dienstkonten in Skripten oder Code durch Managed Identities zu ersetzen.
Wenn ein Code-Phishing bereits erfolgreich war
Gehen Sie davon aus, dass der Angreifer Tokens besitzt und nicht nur ein Passwort. Mit einem Refresh Token lassen sich neue Access Tokens beschaffen. Widerrufen Sie daher zuerst die Sitzungen des Benutzers und setzen Sie anschließend das Passwort zurück. Dies ist eine Empfehlung aus der Praxis und stammt nicht aus den oben genannten Quellen.
Prüfen Sie als Nächstes die Enterprise Applications und Consent Grants, die mit dem Konto verknüpft sind, und entfernen Sie alle, die Sie nicht kennen. Kontrollieren Sie das Postfach auf Regeln, die der Benutzer nicht selbst angelegt hat, insbesondere Weiterleitungs- oder Löschregeln.
Weiten Sie die Suche über einen einzelnen Benutzer hinaus aus: Wenden Sie den oben beschriebenen Device-Code-Filter auf weitere Konten an und suchen Sie nach derselben Anwendung. Könnte mehr als ein Konto betroffen sein, folgen Sie einem geordneten Incident-Response-Prozess. Unser Incident-Response-Team kann ihn gemeinsam mit Ihnen durchführen, und in unserem Blog finden Sie Beiträge zu Incident Response und Phishing für die Schulungsseite.
Wo Sie anfangen
- Listen Sie alle Geräte, Skripte und Tools auf, die sich möglicherweise per Code anmelden: Drucker, Fernseher, IoT-Geräte, Kommandozeilen-Tools. Fragen Sie bei jedem Verantwortlichen nach, ob dies zutrifft.
- Legen Sie die Conditional-Access-Richtlinie mit ausgewähltem Device code flow an, mit allen Benutzern im Geltungsbereich und ausgeschlossenen Break-glass-Konten, im Report-only-Modus. Entscheiden Sie dabei gleichzeitig über die Bedingung zum Authentication Transfer.
- Werten Sie die Report-only-Ergebnisse und die Device-Code-Anmeldungen in den Protokollen aus. Beheben oder beenden Sie jede legitime Nutzung und überführen Sie den Rest in eine benannte Ausschlussgruppe mit Verantwortlichem.
- Schalten Sie die Richtlinie auf On und tragen Sie die Prüfung der Ausschlussgruppe in den Kalender ein.
- Dokumentieren Sie die Reaktionsschritte (Sitzungen widerrufen, Enterprise Applications und Consent Grants prüfen, Postfachregeln kontrollieren). Sagen Sie Ihren Mitarbeitenden, dass ein Code, den sie nicht selbst angefordert haben und der von einem Gerät stammt, das sie nicht in der Hand halten, ein Phishing-Versuch ist.
