Echter Login. Falscher Auftrag.

Die falsche Frage wäre: Ist die Login-Seite echt?

Bei diesem Angriff kann genau das stimmen. Die Person meldet sich beim echten Identitätsanbieter an und erfüllt möglicherweise auch die Mehrfaktor-Anmeldung. Trotzdem landet der daraus entstehende Zugriff beim Angreifer. Der Fehler liegt im untergeschobenen Auftrag.

Der Device Authorization Grant ist für Geräte mit eingeschränkter Eingabemöglichkeit gedacht. Ein gestarteter Client wartet auf die Bestätigung eines Codes über ein anderes Gerät. Beim Missbrauch startet der Angreifer den Client und bringt die betroffene Person dazu, seinen Code einzugeben. Erfolgreiche Anmeldung und legitimer Zweck fallen dann auseinander.

Was die Bestätigung tatsächlich freigibt.

Die Anmeldung allein beantwortet nicht, ob die Person den betreffenden Client überhaupt verwenden wollte. Eine angebliche Dokumentfreigabe oder Support-Anweisung kann den Zusammenhang verdecken. Eine echte Microsoft-Domain ist daher ein notwendiger Anhaltspunkt für die Herkunft der Seite, aber kein Nachweis für den legitimen Auftrag.

Ich würde in einer Einweisung genau diesen Übergang zeigen: Wer hat den Ablauf gestartet, welche Anwendung wird bestätigt und welcher Zugriff folgt daraus? Das macht den Mechanismus greifbarer als die allgemeine Aufforderung, genauer auf Links zu schauen.

Den Flow dort begrenzen, wo er nicht gebraucht wird.

Microsoft empfiehlt, Device Code Flow nur dort zu erlauben, wo er erforderlich ist. Mit der Bedingung Authentication flows in Conditional Access lassen sich passende Richtlinien aufbauen. Vor dem Erzwingen braucht es einen Überblick über die tatsächliche Nutzung und sauber begründete Ausnahmen. Ein Konferenzraumgerät und ein normales Benutzerkonto können unterschiedliche Anforderungen haben.

Für die Beobachtung reicht die erste Anmeldung nicht immer. Microsoft beschreibt Protocol Tracking über spätere Token-Erneuerungen hinweg. Die Eigenschaft Original transfer method hilft dabei, die Herkunft einer Sitzung nachzuvollziehen, auch wenn der gerade betrachtete Vorgang anders aussieht.

Widerrufen heißt nicht automatisch: überall sofort beendet.

revokeSignInSessions setzt die Gültigkeitsgrenze für Refresh Tokens und bestimmte Browser-Sitzungen zurück. Microsoft weist auf mögliche Verzögerungen hin. Bereits ausgestellte Access Tokens und die Unterstützung von Continuous Access Evaluation müssen bei der Eindämmung gesondert betrachtet werden. Eine einzige Taste mit dem Namen „überall abmelden“ ist kein universeller Wirksamkeitsnachweis.

Bei einem Verdacht würde ich die tatsächlichen Zugriffe, betroffenen Anwendungen und möglichen Freigaben untersuchen, passende Eindämmungsmaßnahmen durchführen und danach kontrollieren, was noch akzeptiert wird. Welche Maßnahme ausreicht, hängt von der konkreten Umgebung ab.

Die Erkenntnis von Maurizio Schmidt: Eine korrekt durchgeführte Anmeldung kann einen falschen Auftrag bestätigen. Genau deshalb sollten Schulung, Richtlinien und Protokollanalyse denselben Ablauf betrachten.