Beim Device-Code-Phishing wird ein legitimer OAuth-2.0-Mechanismus missbraucht, konkret der Device Authorization Grant Flow. Microsoft beschreibt dieses Verfahren als Anmeldemethode für Geräte mit eingeschränkter Oberfläche wie Smart-TVs oder Drucker: Das Gerät zeigt einen kurzen Code an, den der Nutzer in einem Browser auf einem anderen Gerät eingibt, um die Anmeldung abzuschließen. Angreifer nutzen genau diese Trennung aus, starten selbst den Authentifizierungsablauf und schicken den erzeugten Code per Phishing-Köder an das Ziel. Gibt das Opfer den Code ein, autorisiert es unbemerkt die Sitzung des Angreifers.
ZeroBEC zufolge setzte die beobachtete Kampagne auf Phishing-Mails mit Zahlungs- und Shared-Folder-Vorwänden. Die Links führten auf eine legitime, aber kompromittierte kroatische Vermietungs-Website, die als Device-Code-Orchestrator diente und die Microsoft-Device-Code-Abfolge anstieß. Anders als klassische Phishing-Angriffe mit nachgebauten Login-Seiten braucht diese Methode keine gefälschte Passwortseite. Stattdessen wird der Nutzer in einen vertrauenswürdigen, echten Microsoft-Anmeldeprozess gelenkt.
Die Forscher sehen starke Überschneidungen mit Storm-2372, einer von Microsoft im Februar 2025 dokumentierten Kampagne. Dazu zählen Köder im Stil von Messaging- oder Teams-Nachrichten, die Nutzer dazu bringen sollen, einen vom Angreifer bereitgestellten Device Code einzugeben, zusammen mit ihren Zugangsdaten. So kann der Bedrohungsakteur den Token abrufen und das Konto übernehmen. Trotz dieser Ähnlichkeiten geht ZeroBEC davon aus, dass die Akteure Storm-2372-ähnliche Taktiken über eine wiederverwendbare Werkzeugschicht namens DEBULL einsetzen.
Die untersuchte Infrastruktur weist laut ZeroBEC türkischsprachige Entwickler-Markierungen auf, reicht aber nicht für eine eindeutige Zuschreibung. Nach weiterer Analyse handelt es sich bei DEBULL wahrscheinlich um eine Phishing-as-a-Service-Plattform, die für die Phase nach der Authentifizierung GraphSpy oder einen davon abgeleiteten Ablauf für Microsoft 365 und Entra verwendet. ZeroBEC zufolge können Betreiber Seitennamen und Adresspfade festlegen, HTML, CSS und JavaScript direkt bearbeiten und anschließend wählen, wie der Köder veröffentlicht wird. In den eingebetteten Vorlagen fanden die Forscher eine Microsoft-365-Device-Code-Authentifizierungsseite, eine OAuth-Callback-Seite und eine moderne Landingpage. Besonders relevant sei die Microsoft-365-Vorlage, weil sie den konkreten Baustein der Kampagne offenlege: Anzeige des Nutzer-Codes, Kopierfunktion und Link zur Microsoft-Device-Anmeldung.
ZeroBEC fasst die Entwicklung so zusammen: Storm-2372-artige Identitätsangriffe würden inzwischen in wiederverwendbare Broker-Infrastruktur verpackt. DEBULL stelle die kampagnen- und betreiberseitige Schicht bereit, während GraphSpy oder davon abgeleiteter Code wahrscheinlich die Phase nach der Anmeldung übernehme. Der Köder lasse sich austauschen, ohne den Identitäts-Backend-Stack zu verändern.
Parallel dazu berichtet Cisco Talos von einem voll ausgestatteten PhaaS-Bedienpanel namens ARToken, das Infrastruktur, API-Verträge und operative Muster mit der Device-Code-Phishing-Plattform EvilTokens teile und Partnern zur Verfügung gestellt werde. Laut Talos bietet ARToken mehr als 80 API-Endpunkte für Device-Code-Phishing, Persistenz über Primary Refresh Token, E-Mail-Zugriff, BEC-Operationen und SharePoint-Exfiltration über ein React-basiertes Dashboard. Talos-Forscher Michael Kelley bezeichnete die Plattform daher als vollständige BEC-Umgebung und nicht bloß als einfaches Device-Code-Phishing-Kit.
Auch andere Angebote greifen die Methode auf. Proofpoint schrieb im Mai 2026, dass in den meisten aktuellen Angriffen der Code dynamisch erzeugt werde, sobald ein Nutzer auf den ursprünglichen Phishing-Link klickt. Solche Angriffsketten könnten über PhaaS-Angebote wie EvilTokens oder Tycoon gekauft oder von den Angreifern selbst entwickelt werden. eSentire berichtete ebenfalls im Mai 2026, dass Tycoon 2FA seine bestehende PhaaS-Plattform als Auslieferungsrahmen für OAuth-Device-Code-Grant-Phishing umfunktioniert habe. Der Angriff beginne dort mit einer Trustifi-Klick-Tracking-URL in einer Köder-Mail und ende damit, dass das Opfer einem vom Angreifer kontrollierten Gerät über Microsofts legitimen Device-Login-Flow auf microsoft.com/devicelogin unbemerkt OAuth-Token gewähre.