Wenn die meisten Menschen an „Phishing“ denken, denken sie in der Regel daran, dass Nutzer:innen dazu verleitet werden, Anmeldedaten preiszugeben oder Malware herunterzuladen.
Eine der am schnellsten wachsenden Angriffsmethoden tut keines von beidem. Stattdessen wird eine zielgerichtete Person dazu verleitet, einen von der Angreiferseite kontrollierten Client zu autorisieren. Diese Angriffe missbrauchen das Vertrauen in OAuth-basierte Autorisierungsabläufe, mit denen einer Anwendung der Zugriff auf Daten in einer anderen Anwendung gewährt wird.
Anfang 2026 nimmt das Phishing mit Gerätecodes stark zu. Dieser Angriff nutzt bekannte Schwachstellen in der Gewährung der Autorisierung per Gerätecode aus – eine Methode, bei der Benutzer:innen einen Client auf einem Gerät autorisieren, indem sie sich auf einem separaten Gerät anmelden. Diese Gewährung sollte die Anmeldung auf Geräten mit eingeschränkten Eingabemöglichkeiten erleichtern – also dort, wo die Eingabe eines Passworts umständlich ist. Wir sehen jedoch auch, dass es für viele andere Anwendungsfälle eingesetzt wird, darunter auch für Anwendungsfälle im Bereich der Belegschaft. Angreifende haben sich diesen Flow nun mit bemerkenswertem Erfolg zu eigen gemacht, um Benutzer:innen dazu zu verleiten, ihre schädlichen Anwendungen zu autorisieren.
Bedrohungsforscher:innen bei Push Security haben seit Jahresbeginn einen 15-fachen Anstieg von Gerätecode-Phishing-Angriffen auf Microsoft 365-Nutzer:innen beobachtet. Forschende von Okta Threat Intelligence und Proofpoint haben nun Anzeichen dafür festgestellt, dass einige Angreifende von AitM-Phishing-Angriffen zu Gerätecode-Phishing-Angriffen übergegangen sind.
Phishing mit Gerätecodes ist in den Mittelpunkt gerückt, da Angriffe durch „Phishing as a Service“-Dienste wie EvilTokens industrialisiert wurden.
EvilTokens bietet wenig qualifizierten Angreifenden die Infrastruktur, Köder, Abwehrmechanismen zur Erkennungsvermeidung sowie Benachrichtigungs- und Nachrichtendienste, um Phishing-Angriffe per Gerätecode im großen Stil und mit minimalem Aufwand aufseiten der Angreifenden gegen die Kundschaft von Microsoft durchzuführen.
In diesem Artikel erklären wir, wofür der Gerätecode-Flow verwendet wird, wie er ausgenutzt wird und welche Bedingungen diese Form des Angriffs zu „Phishing mit Dynamit“ machen.
Die Gewährung der Autorisierung per Gerätecode
Phishing mit Gerätecodes missbraucht einen spezifischen OAuth 2.0-Autorisierungs-Flow, der für Geräte mit beschränktem Input entwickelt wurde – den OAuth 2.0 Device Code Authorization Grant (RFC8628).
Ein Gerät mit beschränktem Input könnte eine Streaming-App auf Ihrem Fernseher, Apps zur Steuerung Ihrer Haushaltsgeräte oder sogar die Entertainment-Systeme in Ihrem Auto sein. In jedem System, in dem die Eingabe eines langen, starken Passworts umständlich ist, ermöglicht der Gerätecode-Flow einer nutzenden Person die Anmeldung über einen externen Kanal auf einem Mobilgerät oder Laptop sowie die Erteilung der Autorisierung (Zustimmung) für den Client, um auf die eigenen Kontodaten zuzugreifen.
Wenn wir zur Veranschaulichung das Beispiel einer Video-Streaming-App heranziehen:
Eine nutzende Person möchte sich bei einer Streaming-App auf ihrem Fernseher anmelden
Der Smartphone-Browser der nutzenden Person dient dabei als externes Gerät für die Autorisierung
Ein Autorisierungsserver vermittelt den Zugriff auf die Back-End-Server des Streaming-Dienstes
Bei einem legitimen Gerätecode-Autorisierungs-Flow:
- Eine nutzende Person versucht, sich über einen Fernseher bei ihrem Konto des Streaming-Dienstes anzumelden.
- Eine App auf dem Fernseher fordert Zugriff von einem Autorisierungsserver an, indem sie eine Client-ID in einer Anfrage an einen bestimmten Endpoint sendet. Der Autorisierungsserver gibt einen Gerätecode, einen Benutzercode und eine Verifizierungs-URI zurück.
- Die App weist die nutzende Person an, die Verifizierungs-URI aufzurufen – entweder als Webadresse oder als QR-Code auf dem Fernsehbildschirm dargestellt – und stellt ihr zudem einen achtstelligen Benutzercode zur Verfügung, den sie auf ihrem Smartphone eingeben muss, um die App zu autorisieren.
- Nach Aufrufen der bereitgestellten Webadresse wird die nutzende Person aufgefordert, den Benutzercode einzugeben und ihre Identität zu bestätigen. Gegebenenfalls wird die nutzende Person gebeten, der App Zugriff auf die auf dem Server gehosteten Ressourcen (Kontodaten im Streaming-Dienst) zu gewähren.
- Im Hintergrund fragt die App den Autorisierungsserver kontinuierlich mit Anfragen ab, die die Client-ID und den Gerätecode enthalten. Die Client-App fragt den Autorisierungsserver im Grunde, ob die nutzende Person sie autorisiert hat. Sobald die nutzende Person zustimmt, beantwortet der Autorisierungsserver eine Abfrage mit einem Access Token. Dieses Access Token kann dann verwendet werden, um API-Aufrufe an den Streaming-Dienst durchzuführen.
Abbildung 1: OAuth 2.0 Gerätecode-Autorisierungs-Flow
All diese Interaktionen finden in wenigen Sekunden statt. Der Flow ist komfortabel und fördert die Nutzung stärkerer Authentifizierungsmethoden (insbesondere im Vergleich zu kurzen Passwörtern und OTPs, die auf Geräten mit beschränktem Input eingegeben werden).
Leider ist der Gerätecode-Flow auch anfällig für Missbrauch bei Social-Engineering-Angriffen.
Phishing mit Gerätecodes
Bei einem Gerätecode-Phishing-Angriff hingegen kontrolliert der Angreifende die Client-App:
- Der Angreifende registriert entweder eine neue App in einem durch den Angreifenden kontrollierten Tenant, oder verwendet eine Client-ID, die vom Autorisierungsserver des anvisierten Benutzenden als vertrauenswürdig eingestuft wird. Anfragen an den Autorisierungsserver werden als gültig behandelt, da der Gerätecode-Autorisierungsablauf nicht erfordert, dass die Client-App authentifiziert oder überhaupt beim Autorisierungsserver registriert ist. Nichts hindert einen Angreifenden daran, eine bekannte Client-ID zu missbrauchen, und Client-IDs werden in der Regel nicht als Secrets geschützt.
- Der Angreifende übermittelt einem anvisierten Benutzenden den Benutzercode und die Verifizierungs-URL über eine Phishing-Website oder telefonisch durch einen Social-Engineering-Anruf. Wenn der authentifizierte Benutzende diese Web-Adresse besucht und den Benutzercode eingibt, gewährt er der App des Angreifenden faktisch Zugriff auf seine Ressourcen. Der Angreifende muss lediglich den Autorisierungsserver abfragen und erhält als Antwort ein Access Token.
Abbildung 2. Phishing mit Gerätecodes
Phishing mit Dynamit
Bei den bisher von uns beobachteten Angriffen haben Angreifende Interesse daran gezeigt, sich als Clients auszugeben, die:
von einem gemeinsamen Autorisierungsserver autorisiert sind
in neuen Tenants (einschließlich kostenloser bzw. Test-Tenants) allen Nutzenden standardmäßig zugewiesen werden
über eine bekannte bzw. gängige Client-ID verfügen, die in jedem Tenant identisch ist
Leider erfüllen Microsoft-Apps diese Kriterien in mehrfacher Hinsicht:
Eine schädliche Person oder Entität, die EvilTokens nutzt, kann einen Gerätecode-Flow starten, indem sie eine POST-Anforderung an denselben gemeinsamen Endpoint sendet, der für alle Microsoft-Kund:innen gilt (/common/oauth2/devicecode).
Diese POST-Anfrage muss eine gültige Client-ID enthalten. Die Client-IDs von First-Party-Apps, die standardmäßig in Microsoft-Tenants verfügbar sind, werden routinemäßig aufgelistet und tabellarisch erfasst, und die ungewöhnlichen Beziehungen zwischen ihnen werden offen diskutiert. Bedrohungsforscher:innen haben festgestellt, dass EvilTokens standardmäßig die bekannte Client-ID von Microsoft Office missbraucht, andere Forscher:innen haben jedoch den Missbrauch weiterer Microsoft-Apps beobachtet.
Das bedeutet, dass ein einziges Tool ausreicht, um fast jede Microsoft-Kundschaft auf der Welt anzugreifen – unabhängig davon, ob ein Jugendlicher eine App auf seiner XBox autorisiert oder ein IT-Manager eine App für ein Fortune-500-Unternehmen freigibt.
Der Vorteil für Angreifende, wenn sich alle Nutzenden über eine einzige Domain (login.microsoft.com) authentifizieren, besteht darin, dass Angriffe sehr einfach in großem Maßstab durchgeführt werden können. Bei einem Gerätecode-Phishing-Angriff auf Microsoft-Kund:innen leiten Angreifende alle anvisierten Nutzer:innen an einen gemeinsamen Endpoint weiter (login.microsoft.com/common/oauth2/v2.0/devicecode). An diesem Endpoint ist jede Person, die Microsoft-Dienste nutzt, ein gültiges Konto – insbesondere dann, wenn Client-IDs verwendet werden, die vielen oder allen Nutzenden standardmäßig zugewiesen sind.
Im Gegensatz dazu wurde die Okta Platform nach dem Prinzip entwickelt, dass jede Organisation über einen oder mehrere eigene, unabhängige und dezentrale Autorisierungsserver verfügt. Es gibt kein Konzept für einen „gemeinsamen“ Endpoint, an dem Nutzer:innen aus verschiedenen Organisationen ihre Identität an einem Ort verifizieren.
Das bedeutet, dass in Okta erstellte Clients zwar nicht immun gegen Gerätecode-Phishing-Angriffe sind, die Architektur von Okta Angreifende jedoch dazu zwingt, bei jedem potenziellen Ziel viel mehr Vorarbeit zu leisten.
Ressourcen
Die ganze Geschichte lesen
Um mehr über den Ansatz von Okta zur Abwehr von Missbrauch des Gerätecode-Flows zu erfahren, können sich die Sicherheitskontakte von Okta-Kund:innen anmelden, um unter security.okta.com eine erweiterte Version dieses Artikels abzurufen.
Empfehlungen
- Erlauben Sie die Nutzung des Gerätecode-Flows nur in Ausnahmefällen. Microsoft-Kunden sollten eine Richtlinie für bedingten Zugriff implementieren, die jeglichen Zugriff über den Gerätecode-Flow blockiert.
Falls der Gerätecode-Flow für eine in Okta erstellte Client-Anwendung als am besten geeignet erachtet wird:
Setzen Sie den IP-Bereich auf eine Positivliste, von dem aus ein Token für einen bestimmten Client ausgestellt werden darf. Dies lässt sich für jeden beliebigen Client unter Anwendungen > Allgemein > Netzwerk-IP konfigurieren. Nach der Konfiguration werden Anfragen nach einem Zugriffstoken von einem von Angreifenden gesteuerten Client außerhalb des freigegebenen IP-Bereichs abgelehnt.
Überwachen Sie das System auf ungewöhnliche Token-Anfragen und Berechtigungserteilungen.
