Device-Code-Phishing bezeichnet eine Technik, die den OAuth-Geräteautorisierungsfluss missbraucht, um dem Angreifer dauerhafte Zugriffstokens zu verschaffen. Laut Huntress generiert die Authentifizierung nach einem erfolgreichen Phishing einen Satz Tokens, die am OAuth-Token-Endpunkt liegen und durch Angabe des passenden Gerätecodes abgerufen werden können. Den Code kennt der Angreifer bereits, weil er ihn über die anfängliche cURL-Anfrage an die Geräteanmelde-API selbst erzeugt hat. Allein ist dieser Code wertlos – sobald das Opfer jedoch zur Authentifizierung verleitet wurde, gehören die entstehenden Tokens jedem, der weiß, welcher Gerätecode in der ursprünglichen Anfrage verwendet wurde.
Besonders tückisch ist, dass der Angriff den legitimen Authentifizierungsfluss von Microsoft nutzt und Nutzern damit keinen Anlass zum Misstrauen gibt. Erstmals beobachtet wurde Device-Code-Phishing laut Huntress im Februar 2025 durch Microsoft und Volexity; weitere Wellen dokumentierten anschließend Amazon Threat Intelligence und Proofpoint. Mehrere als Russland-nah eingestufte Gruppen, die unter den Bezeichnungen Storm-2372, APT29, UTA0304, UTA0307 und UNK_AcademicFlare geführt werden, wurden diesen Angriffen zugeschrieben.
In der nun von Huntress entdeckten Kampagne geht der Authentifizierungsmissbrauch von einer kleinen Gruppe von Railway.com-IP-Adressen aus; drei davon stehen für rund 84 Prozent der beobachteten Ereignisse. Ausgangspunkt ist eine Phishing-E-Mail, die schädliche URLs in legitime Weiterleitungsdienste von Sicherheitsanbietern wie Cisco, Trend Micro und Mimecast einbettet, um Spamfilter zu umgehen. Anschließend folgt eine mehrstufige Weiterleitungskette aus kompromittierten Websites, Cloudflare Workers und Vercel.
Die beobachteten Landeseiten fordern das Opfer auf, zum legitimen Microsoft-Endpunkt für die Geräteanmeldung zu wechseln und einen bereitgestellten Code einzugeben, angeblich um Dateien lesen zu können. Ungewöhnlich daran: Der Code wird direkt auf der Seite angezeigt, sobald das Opfer eintrifft – vermutlich über eine Automatik zur Codeerzeugung. Normalerweise muss der Angreifer den Code erst selbst erstellen und übermitteln. Eine Schaltfläche “Continue to Microsoft” öffnet zudem ein Pop-up mit dem echten Microsoft-Authentifizierungsendpunkt (microsoft[.]com/devicelogin).
Nahezu jede Phishing-Seite war auf einer Cloudflare-workers[.]dev-Instanz gehostet, womit die Angreifer das Vertrauen in diesen Dienst ausnutzen, um Webinhaltsfilter zu umgehen. Auffällig ist auch die Vielfalt der Methoden: Köder mit Bauausschreibungen, generierte Landeseiten, vorgetäuschte DocuSign-Nachrichten, Voicemail-Benachrichtigungen und der Missbrauch von Microsoft-Forms-Seiten treffen denselben Opferkreis über dieselbe Railway-Infrastruktur. Zur Abwehr rät Huntress, die Anmeldeprotokolle auf Railway-IP-Logins zu durchsuchen, alle Refresh-Tokens betroffener Nutzer zu widerrufen und Authentifizierungsversuche aus der Railway-Infrastruktur nach Möglichkeit zu blockieren.
Huntress führt die Railway-Angriffe auf die neue Phishing-as-a-Service-Plattform EvilTokens zurück, die kürzlich auf Telegram debütierte. Neben Werkzeugen zum Versenden von Phishing-Mails und zum Umgehen von Spamfiltern bietet das EvilTokens-Dashboard offene Weiterleitungslinks zu verwundbaren Domains; das Team betreibt nach Unternehmensangaben zudem einen rund um die Uhr erreichbaren Support.
Zeitgleich warnte Unit 42 von Palo Alto Networks vor einer ähnlichen Kampagne, deren früheste Beobachtung auf den 18. Februar 2026 zurückgeht. Die dortigen Phishing-Seiten setzen Anti-Bot- und Anti-Analyse-Techniken ein, exfiltrieren beim Laden der Seite Browser-Cookies und deaktivieren Rechtsklick, Textauswahl sowie Drag-Operationen. Zudem blockieren sie Tastenkürzel für Entwicklerwerkzeuge (F12, Strg+Umschalt+I/C/J) und die Quelltextansicht (Strg+U) und lösen über eine Heuristik zur Fenstergröße eine Endlosschleife im Debugger aus, sobald geöffnete Entwicklerwerkzeuge erkannt werden.