Device-Code-Phishing ist ein wachsender Bestandteil moderner Angriffe: Das kommerzielle PhaaS-Toolkit Greatness unterstützt nun zusätzlich zur klassischen Credential- und Token-Aneignung auch das Missbrauchen des OAuth 2.0 Device Authorization Grant. Damit lassen sich Multi-Faktor-Authentifizierungen (MFA) umgehen und anschließend Nutzerkonten übernehmen.
Der entscheidende Punkt: Bei diesem Vorgehen wirkt der Login für die betroffene Person auf den ersten Blick „normal“, denn es gibt keine auffällige Phishing-Loginseite, die sich sofort als Fälschung enttarnen lässt. Stattdessen arbeitet der Angriff mit einem kurzen Code und einer plausiblen Begründung, um Token-Anforderungen im Hintergrund auszulösen.
Was Greatness mit Device-Code-Phishing neu ermöglicht
Greatness wird als integriertes Angriffssystem beschrieben. Laut dem Bericht kann der Betreiber über eine zentrale Bedienoberfläche verschiedene Phishing- und OAuth-Abgriffe in Kampagnen kombinieren. Neben AiTM-Funktionen (Adversary-in-the-Middle) nennt der Bericht explizit auch Device-Code-Phishing sowie das Ausnutzen von OAuth-Einwilligungen.
Besonders relevant ist dabei die Weiterentwicklung von reiner Datenernte hin zu einem „Angriffs-Ökosystem“: Statt nur Zugangsdaten zu sammeln, können Angreifer mehrere Schritte miteinander verzahnen – inklusive Token-Diebstahl und Folgemaßnahmen in verschiedenen Zielumgebungen.
Wie der OAuth Device Authorization Grant missbraucht wird
Beim OAuth Device Authorization Grant muss ein Nutzer typischerweise einen Gerätecode eingeben, damit ein Autorisierungsvorgang stattfinden kann. Genau diesen Mechanismus machen Angreifer sich zunutze, um Tokens ohne unmittelbare, sichtbare Benutzerinteraktion „leise“ zu erhalten.
Im Kern entsteht so ein zweistufiges Muster:
- Die Opferaktion löst einen Gerätecode-Flow aus, bei dem die betroffene Person nur einen kurzen Code eingibt.
- Im Hintergrund kann der Angreifer den Prozess fortsetzen und Tokens abziehen.
Das reduziert typische Anzeichen klassischer Phishing-Seiten. Ein zusätzlicher Reiz für Angreifer: Es ist weniger „Bastelarbeit“ erforderlich, um eine gefälschte Loginoberfläche zu bauen oder schnell in den Fokus von Erkennungsmechanismen zu geraten.
Warum Device-Code-Phishing MFA umgeht
MFA basiert häufig darauf, dass ein Angreifer den zweiten Faktor nicht einfach „durchreichen“ kann. Bei Device-Code-Phishing wird jedoch nicht nur versucht, einen Einmal-Login zu erbeuten, sondern der Angriff zielt auf Tokens und die anschließende Nutzung von Kontoressourcen.
Der Bericht beschreibt zudem, dass gestohlene Authentifizierungs-Token nach dem Zugriff sehr zügig wiederverwendet werden können. So entsteht trotz bestehender Kontoschutzmechanismen ein praktisches Problem: Selbst wenn MFA einen unmittelbaren Login abwehrt, kann ein Token-Diebstahl weiterhin Zugriff ermöglichen.
Der Kampagnenbaukasten: Panel, Vorlagen und Umgehungsmechanismen
Greatness ist nicht als einzelne Schadsoftware beschrieben, sondern als Dienst, der über ein Abo-Modell betrieben wird. Der Einstieg erfolgt über einen öffentlichen Telegram-Kanal, über den Abonnements vergeben werden. Dem Bericht zufolge startet der Preis bei 289 US-Dollar pro Monat und liegt damit deutlich über einer früher genannten Einstiegskonfiguration.
Nach dem Erwerb erhalten Kunden Zugriff auf eine Bedienoberfläche mit Funktionen für:
- Kampagnenstatistiken
- Domain-Konfiguration
- CAPTCHA-Auswahl
- „Lure“-Vorlagen für verschiedene Köderformate
Außerdem werden dem Bericht nach mehrere fertige Template-Varianten bereitgestellt, unter anderem für Audio-Login-, Voicemail-, QR-, OneDrive- und Windows-Explorer-Szenarien. Diese Vorlagen enthalten vorgebaute Bestandteile, damit Betreiber nicht bei jeder Kampagne bei Null beginnen müssen.
Damit die Angriffe nicht leicht analysiert werden können, wird im Bericht eine mehrstufige Umleitungs-Kette erwähnt. Diese soll u. a. Anti-Analyse-Mechanismen, User-Agent-Fingerprinting und eine CAPTCHA-Gate-Phase einbauen, bevor der Opferpfad zur eigentlichen Zielstrecke führt – entweder zu einem AiTM-Endpunkt oder zu einem Device-Code-Ziel.
Vom Köder zur Kontrolle: Was nach dem Token-Diebstahl passiert
Nach dem erfolgreichen Durchlaufen der Angriffslogik werden gesammelte Tokens wiederverwendet. Laut der Analyse erfolgen Replay-Vorgänge innerhalb weniger Minuten über entsprechende Proxy-Infrastruktur. Danach folgt typischerweise eine systematische Erkundung der betroffenen Microsoft 365-Ressourcen.
Genannt werden unter anderem:
- Outlook und Teams
- SharePoint und Exchange
- OneDrive
- Kontakte, Kalender
- weitere registrierte Anwendungen über die Microsoft Graph API
Der Bericht beschreibt außerdem, dass Token in einzelnen Fällen über längere Zeiträume weiter genutzt werden können. In einem beobachteten Beispiel war eine AiTM-Proxy-IP mehr als zwei Wochen nach der initialen Phishing-Kampagne noch aktiv, was auf eine anhaltende Wirksamkeit der erbeuteten Berechtigungsartefakte hindeutet.
Bezug zu Lieferanten-„Trust“-Effekten: RingCentral als Beispiel
Besonders auffällig sind Kampagnen, die nicht nur eine Marke imitieren, sondern den Vertrauensmechanismus des Zielsystems ausnutzen. In den beschriebenen Fällen wurden E-Mails mit vermeintlichen Voicemail-Inhalten verbreitet, die RingCentral imitiert und dabei durch Konfigurationseffekte die Zustellung begünstigen.
Der Bericht erklärt, dass die Angriffe den Umstand nutzen können, dass die Zielorganisation den Absender über „Safe Sender“-Regeln als vertrauenswürdig behandelt – selbst wenn SPF, DKIM und DMARC nicht erfolgreich sind. Damit wird die Schwelle für das Erreichen des Postfachs gesenkt.
Zudem wird der Gedanke betont: Wenn ein Dienstanbieter kompromittiert wird und eine Kundenliste offenliegt, steigt die Wahrscheinlichkeit, dass genau diejenigen Organisationen, die zu diesem Anbieter passen, in den Schutzlisten stehen. Für Verteidiger bedeutet das: Hinweise auf Anbieter-Breaches sollten Anlass sein, E-Mail-Ausschluss- und Vertrauensregeln für betroffene Domains zu überprüfen.
Welche Prävention gegen Device-Code-Phishing hilft
Gegen Device-Code-Phishing wird im Bericht ein mehrschichtiger Schutz empfohlen, der sowohl die Authentifizierungsebene als auch das Nutzerverhalten berücksichtigt.
1) Conditional Access und globale Sperren
Eine konkrete Maßnahme ist das Blockieren der betroffenen Authentifizierungsmethode auf globaler Ebene in den Conditional-Access-Policies.
2) Phishing-resistente MFA-Methoden
Da Angreifer sich auf Token und OAuth-Flows stützen können, empfiehlt sich der Umstieg auf MFA-Varianten, die gegen Phishing deutlich robuster sind.
3) Prozessausnahmen nur gezielt und auditierbar
Wenn der Device-Code-Flow in spezialisierten Use Cases zwingend ist, sollten betroffene Nutzer oder Ressourcen explizit aus den Richtlinien ausgenommen werden. Gleichzeitig muss die zulässige Nutzung kontinuierlich geprüft und beendet werden, sobald sie nicht mehr erforderlich ist.
4) Schulung: unerwartete Codes nicht blind akzeptieren
Zusätzlich hilft Sensibilisierung. Mitarbeitende sollten lernen, unerwartete oder ungewöhnliche Codes kritisch zu hinterfragen, statt sie als „automatisch richtig“ anzusehen.
Was Unternehmen jetzt tun sollten
Device-Code-Phishing zeigt, wie schnell sich Phishing-Services weiterentwickeln: Aus einzelnen Betrugsvarianten werden durch integrierte Toolsets zusammenhängende Angriffsketten. Für Unternehmen heißt das, Sicherheitskontrollen nicht nur auf die Oberfläche (E-Mail und Login-Seite) zu beschränken, sondern den gesamten OAuth-/Token-Kontext mitzudenken.
Prüfen Sie deshalb zeitnah:
- Ob die relevante Authentifizierungsmethode in Conditional Access konsequent eingeschränkt ist.
- Welche MFA-Methoden bei Ihnen aktiv sind und ob sie phishing-resistent sind.
- Wie stark Trust-Mechanismen wie Safe Sender und Ausnahmeregeln wirken – insbesondere nach Anbieter-Sicherheitsmeldungen.
Wenn sich Device-Code-Phishing im Alltag lohnt, liegt die Verbesserung nicht in einer einzelnen „Zauberregel“, sondern in sauberer Policy-Gestaltung, konsequentem Audit und klaren Regeln für den Umgang mit Codes und Authentifizierungsanfragen.
Quelle: https://thehackernews.com/2026/08/greatness-phaas-adds-device-code.html
