Wenn IT-Sicherheitsverantwortliche und Medien an Phishing denken, dann steht traditionell der Diebstahl von Anmeldedaten oder die Verbreitung von Malware im Vordergrund. Doch die Bedrohungslandschaft wandelt sich rapide. Aktuell beobachten Sicherheitsforscher eine Angriffsmethode, die gänzlich ohne das Abgreifen von Passwörtern auskommt: das sogenannte Device Code Phishing. Bei dieser hochgradig gefährlichen Variante werden Nutzer nicht zur Preisgabe ihrer Anmeldedaten verleitet, sondern dazu manipuliert, eine von Hackern kontrollierte Anwendung zu autorisieren. Diese Attacken missbrauchen das tiefe Vertrauen in OAuth-basierte Autorisierungsprozesse und entwickeln sich wegen kommerzialisierter Phishing-as-a-Service-Plattformen zu einer flächendeckenden Bedrohung.

Der legitime OAuth-Device-Code-Flow als unerkanntes Einfallstor

Um die Mechanik dieser Angriffe zu verstehen, muss zunächst der zugrundeliegende, legitime Anwendungsfall betrachtet werden. Das Device Code Phishing missbraucht einen spezifischen OAuth-2.0-Autorisierungsablauf, der ursprünglich für auf Eingaben beschränkte Geräte konzipiert wurde – den sogenannten OAuth 2.0 Device Code Authorization Grant nach RFC8628. Dieser Standard wurde für Smart-TVs, smarte Haushaltsgeräte oder Entertainment-Systeme in Fahrzeugen entwickelt, bei denen die Eingabe langer, komplexer Passwörter unpraktisch ist.

Der Ablauf ermöglicht es einem Nutzer, sich ‘Out-of-Band’ auf einem separaten Gerät wie einem Smartphone anzumelden, um der Zielanwendung den Zugriff auf seine Kontodaten zu gestatten. Dabei fordert die Applikation auf dem Gerät den Zugriff beim Autorisierungs-Server an und erhält einen Geräte-Code, einen Nutzer-Code sowie eine Verifizierungs-URL. Der Nutzer ruft diese URL über sein Smartphone auf, gibt den meist achtstelligen Code ein und autorisiert den Zugriff. Im Hintergrund fragt die Applikation kontinuierlich den Server ab, bis sie nach erfolgreicher Nutzerzustimmung ein Access Token erhält, welches anschließend für API-Aufrufe genutzt werden kann.

Wie funktioniert Device Code Phishing?

Cyber-Kriminelle haben diesen eigentlich auf Komfort ausgelegten Prozess nun für ihre Zwecke missbraucht. Bei einem Device Code Phishing kontrolliert der Hacker die Client-Anwendung von Beginn an. Er registriert entweder eine neue App in einem von ihm kontrollierten Mandanten oder nutzt eine bekannte Client-ID, die dem Autorisierungs-Server des Opfers bereits als vertrauenswürdig gilt.

Die entscheidende Schwachstelle dieses Ablaufs liegt darin, dass die Client-Applikation sich gegenüber dem Autorisierungs-Server oftmals weder authentifizieren noch registrieren muss. Es gibt keine inhärenten Mechanismen, die einen Angreifer daran hindern, eine etablierte Client-ID zu missbrauchen, da diese Parameter typischerweise nicht als Geheimnisse geschützt werden. Der Angreifer übermittelt dem anvisierten Opfer den Nutzer-Code und die Verifizierungs-URL – oft geschickt getarnt über eine präparierte Phishing-Website oder mittels Social Engineering per Telefon. Sobald der authentifizierte Nutzer diese legitime Webseite aufruft und den Code eingibt, erteilt er der Applikation des Angreifers direkten Zugriff auf seine Ressourcen. Der Cyber-Kriminelle muss lediglich den Autorisierungs-Server abfragen und erhält umgehend das begehrte Access Token.

Abbildung: Überblick über das sogenannte Device Code Phishing (Quelle: Okta 2026).

Industrialisierung der Bedrohung durch Phishing-as-a-Service

Die Brisanz dieser Methode zeigt sich in den aktuellen Beobachtungen der Cyber-Sicherheits-Community. Unser Threat Intelligence Team und weitere Analysten haben eindeutige Indikatoren dafür gefunden, dass zahlreiche Hacker ihre Taktik von klassischen Adversary-in-the-Middle-Angriffen (AitM) auf Device Code Phishing umgestellt haben. Der Hauptgrund für diese rasante Verbreitung liegt in der Industrialisierung der Angriffe durch Plattformen wie ,EvilTokens’. Solche Phishing-as-a-Service-Angebote stellen auch technisch weniger versierten Cyber-Kriminellen die komplette Infrastruktur, Lockmittel, Werkzeuge zur Abwehrumgehung und Alarmierungssysteme zur Verfügung. Damit lassen sich diese Kampagnen im großen Stil und mit minimalem Aufwand betreiben.

Warum zentralisierte Architekturen verwundbar sind

Die fatale Effizienz dieser Angriffe – von Experten treffend als ,Dynamit-Phishing’ bezeichnet – resultiert aus der Architektur vieler weit verbreiteter Cloud-Ökosysteme. Die Angreifer konzentrieren sich auf Clients, die von einem gemeinsamen Autorisierungs-Server zugelassen werden, standardmäßig allen Nutzern zugewiesen sind und über eine universell bekannte Client-ID verfügen. Ein Nutzer von EvilTokens kann beispielsweise den Device-Code-Flow initiieren, indem er einen simplen Request an einen gemeinsamen Endpunkt sendet, der für eine unbegrenzte Anzahl an Mandanten eines großen Anbieters gültig ist. Dabei wird standardmäßig eine allgemein bekannte Client-ID, wie etwa die von gängigen Office-Anwendungen, missbraucht. Diese Konstellation erlaubt es, mit einem einzigen Werkzeug eine gigantische Anzahl von Nutzern weltweit anzugreifen.

Im starken Kontrast dazu stehen moderne Identitätsplattformen, die auf einem dezentralen Architekturprinzip beruhen. Wenn jede Organisation über völlig unabhängige Autorisierungs-Server verfügen würde und es keinen universellen Endpunkt für die Identitätsprüfung gäbe, würde dies Angreifer dazu zwingen, für jedes potenzielle Zielunternehmen aufwendige, individuelle Vorbereitungen zu treffen. Dezentrale Identitätsarchitekturen sind zwar nicht an und für sich immun gegen den Missbrauch des Device Code Flows, sie verhindern jedoch dieses massenhafte und automatisierte Ausnutzen effektiv.

Fazit

Device Code Phishing stellt eine ernsthafte und wachsende Gefahr dar, da es legitime und oft unzureichend überwachte Autorisierungsprozesse gegen die Nutzer wendet. Unternehmen müssen daher umgehend reagieren und ihre Zugriffsrichtlinien nachbessern. Als wichtigste Gegenmaßnahme sollte die Nutzung des Device Code Flows standardmäßig blockiert und nur in zwingend notwendigen Ausnahmefällen erlaubt werden. Dies lässt sich in den meisten Umgebungen über bedingte Zugriffsrichtlinien (Conditional Access Policies) umsetzen. In Systemen und Szenarien, in denen der Device Code Flow für eine interne Anwendung unverzichtbar ist, sollten Sicherheitsverantwortliche konsequent auf IP-Allowlisting setzen. Dadurch wird sichergestellt, dass Token nur an Clients vergeben werden, die sich innerhalb definierter, vertrauenswürdiger Netzwerkbereiche befinden, während Anfragen von außerhalb automatisch abgewiesen werden. Flankierend dazu ist eine kontinuierliche Überwachung von Anomalien bei Token-Anfragen und Nutzerfreigaben unerlässlich, um unautorisierte Zugriffe frühzeitig zu identifizieren und die eigene Infrastruktur abzusichern.