Im Kern greift Device-Code-Phishing nicht den eigentlichen Anmeldeprozess an, sondern die nachgelagerte Autorisierung. Laut Push Security ist das Opfer in vielen Fällen bereits bei seinem Microsoft-Konto angemeldet, wenn es auf die Phishing-Seite gelangt. Dort kopiert es einen kurzen Code, gibt ihn auf der legitimen Microsoft-Seite für Geräteanmeldungen ein, wählt sein Konto aus und bestätigt die Freigabe. Genau darin besteht der Angriff.
Weil dieser Ablauf von der Authentifizierung getrennt ist, greifen klassische Schutzmechanismen an dieser Stelle nicht. Push betont, dass Passkeys, Hardware-Sicherheitsschlüssel und erzwungene phishing-resistente Mehrfaktor-Authentifizierung hier keinen Unterschied machen. Der Grund: Der Angriff nutzt aus, dass Identitätsnachweis und Zugriffsfreigabe für eine Anwendung zwei verschiedene Schritte sind, während viele Sicherheitskontrollen nur den ersten absichern.
Nach Einschätzung von Push ist die Methode inzwischen kein Spezialwerkzeug mehr, sondern Teil des regulären Phishing-as-a-Service-Markts. Das Unternehmen verfolgt nach eigenen Angaben inzwischen mehr als 25 unterschiedliche Device-Code-Phishing-Kits, Tendenz steigend. Tycoon2FA, das Push zuvor als das verbreitetste AiTM-Phishing-Kit im Umlauf eingeordnet hatte, ergänzte Device-Code-Phishing im Mai. Kali365 bietet laut dem Unternehmen sowohl AiTM als auch Device-Code-Phishing in einer Plattform an.
Die Fähigkeiten dieser Kits nehmen ebenfalls zu. Push nennt ARToken als Beispiel: Das Kit werde mit PRT-Persistenz, Postfachzugriff, Automatisierung für betrügerische Geschäftskommunikation und der Exfiltration aus SharePoint als Produktfunktionen für zahlende Betreiber ausgeliefert. Insgesamt sieht Push ein Kommerzialisierungsmuster, das an AiTM-Phishing erinnert: von der Forschungsarbeit über staatlich motivierte Spionage bis hin zur kriminellen Massenware. Bei Device-Code-Phishing habe sich dieser gesamte Weg jedoch innerhalb weniger Monate vollzogen.
Als einen wichtigen Beschleuniger nennt Push KI-gestützte Entwicklung. Viele der beobachteten Kits wiesen ähnliche Strukturen auf, etwa bei Layout und Code-Architektur, weil sie von großen Sprachmodellen auf Basis ähnlicher Eingaben erzeugt worden seien. Push-Forschungschef Luke Jennings habe zur Demonstration ein eigenes Kit erstellt, um zu zeigen, wie niedrig die Einstiegshürde geworden ist.
Derzeit richten sich laut Push 99 Prozent der erkannten Device-Code-Phishing-Angriffe gegen Microsoft. Das werde aber nicht so bleiben. Der OAuth-2.0-Mechanismus zur Geräteautorisierung ist ein plattformübergreifender Standard, sodass jede Anwendung, die ihn implementiert, zum Ziel werden kann. Push verweist darauf, dass staatlich unterstützte Akteure Device-Code-Phishing bereits in gezielten Kampagnen gegen Salesforce eingesetzt haben. Die von ShinyHunters durchgeführte Salesforce-Kampagne nutzte demnach eine bösartige „DataLoader“-Anwendung, kompromittierte mehr als 1.000 Organisationen und führte zu 1,5 Milliarden gestohlenen Datensätzen.
Zu den weiteren möglichen Zielen zählt Push unter anderem GitHub und AWS. Bei GitHub gehört der Gerätecode-Ablauf demnach zum Kern der Authentifizierung für Kommandozeilenwerkzeuge und VS-Code-Tunnel. Device-Code-Phishing sei zwar weniger universell einsetzbar als AiTM, weil nicht jede Anwendung diesen Autorisierungsweg unterstützt. Dafür brauche der Angriff aber keine nachgebaute Login-Seite, umgehe sämtliche MFA-Verfahren einschließlich Passkeys und nutze legitime Anbieter-URLs.
Push ordnet die Entwicklung in einen größeren Trend ein: Angreifer verlagern sich von der Authentifizierungsebene auf Autorisierungsmechanismen. Das Unternehmen verweist dazu auf ConsentFix, eine Ende 2025 entdeckte OAuth-Consent-Phishing-Technik im Browser, die zunächst russischen Akteuren zugeschrieben wurde und inzwischen auch in kriminellen Toolkits auftaucht. Wie Device-Code-Phishing ziele ConsentFix auf die Autorisierung und umgehe Passkeys aus demselben strukturellen Grund.
Verteidigungsmaßnahmen sind nach Darstellung von Push schwierig umzusetzen. Für Microsoft-Umgebungen werde häufig empfohlen, Device-Code-Anmeldeflüsse per Richtlinien für bedingten Zugriff einzuschränken. Das sei sinnvoll, aber nicht immer einfach, weil diese Abläufe legitime Zwecke erfüllen und sich in größeren Organisationen oft nicht ohne Folgen für Entwicklerwerkzeuge, Kommandozeilen-Workflows oder Szenarien mit eingeschränkten Geräten abschalten lassen. Außerdem helfe eine Beschränkung bei Microsoft nicht gegen entsprechende Angriffe auf GitHub, AWS oder andere Plattformen, bei denen vergleichbare Kontrollen möglicherweise fehlen.
Da Phishing-Seiten über E-Mail, Messenger, soziale Netzwerke, Suchergebnisse oder kompromittierte Websites ausgeliefert werden können und die Code-Eingabe auf legitimen Anmelde-URLs erfolgt, sieht Push herkömmliche Netz- und Reputationskontrollen im Nachteil. Neue Kits tauchten wöchentlich auf und wechselten ihre Infrastruktur schneller, als indikatorenbasierte Ansätze mithalten könnten.