Device-Code-Phishing ist 2026 zu einer der am schnellsten wachsenden Bedrohungen geworden. Laut aktuellen Beobachtungen hat sich die Angriffsform innerhalb weniger Monate von einer eher seltenen Technik hin zu einer industriell genutzten Masche entwickelt. Besonders kritisch: Die Vorgehensweise zielt nicht auf das klassische Anmeldeformular, sondern auf die Freigabe- und Autorisierungsschicht danach.
In diesem Beitrag beleuchten wir sechs Gründe, warum Device-Code-Phishing so rasant zunimmt – und was das für Teams bedeutet, die Identitäten, Zugriffe und Token absichern.
1) Device-Code-Phishing umgeht jede MFA-Variante
Der wichtigste Punkt zuerst: Device-Code-Phishing greift den Login-Prozess nicht im eigentlichen Sinn an. Stattdessen missbrauchen Angreifer das, was nach erfolgreicher Anmeldung passiert – die Autorisierungsebene.
In vielen Fällen trifft der Angriff auf Nutzer zu, die bereits in ihrem Konto (z. B. bei Microsoft) angemeldet sind. Die Opfer kopieren dann einen kurzen Code, geben ihn auf der legitimen Geräte-Login-Seite ein, wählen in der Oberfläche das gewünschte Konto aus und klicken anschließend auf „Allow“. Damit ist die entscheidende Freigabe erfolgt.
Weil die Gerätefreigabe getrennt von der Authentifizierungsmechanik betrachtet wird, helfen gängige Schutzmaßnahmen oft nur begrenzt: Passkeys, Hardware-Security-Keys und selbst phishing-resistente MFA-Setups ändern an der grundlegenden Logik des Angriffs wenig. Angreifer trennen Identitätsnachweis und Zugriffsfreigabe gezielt voneinander.
2) Das PhaaS-Ökosystem hat den Angriff standardisiert
Ein weiterer Hebel hinter der starken Verbreitung: Device-Code-Phishing ist nicht mehr nur „Handarbeit“ für spezialisierte Teams. Es ist als Bestandteil im Katalog von Phishing-as-a-Service (PhaaS) angekommen. Damit sinken Einstiegshürden, Parallelisierung steigt, und neue Varianten tauchen schneller auf.
Aktuelle Berichte nennen Beispiele, bei denen bestehende Frameworks Device-Code-Phishing in ihre Funktionen aufgenommen haben oder beides in einer Plattform kombinieren. Auch die Fähigkeiten solcher Kits entwickeln sich weiter: Statt nur Token zu erbeuten, werden zusätzliche Komponenten wie Persistenz, Postfach-Zugriff oder Automatisierung angrenzender Betrugsszenarien zunehmend als „Produktfeatures“ angeboten.
Die Dynamik erinnert an frühere Phishing-Wellen: Eine Technik wandert von Forschung und Spezialfällen hin zu staatlichen Anwendungen und schließlich in kriminelle Produkte. Bei Device-Code-Phishing scheint dieser Weg jedoch ungewöhnlich komprimiert zu sein – was auf die Reife des PhaaS-Markts und die Geschwindigkeit hinweist, mit der neue Funktionen mit Hilfe von KI-gestützter Entwicklung umgesetzt und verteilt werden.
3) Neue Kits entstehen schneller, als Defenders sie katalogisieren
Ein klares Muster: Die Anzahl unterschiedlicher Device-Code-Phishing-Kits steigt. Aktuell werden mehr als 25 verschiedene Kit-Familien in der Wildnis beobachtet. Zum Vergleich: Bei anderen Phishing-Kategorien war das Auftauchen eines neuen AiTM-Kits früher eher ein seltenes Ereignis.
Warum passiert das so schnell? Laut den Beobachtungen ermöglicht AI-assistierte Entwicklung eine deutliche Absenkung der Hürde. Viele Kits weisen strukturelle Ähnlichkeiten auf – etwa bei Layout- oder Code-Architektur – weil sie offenbar aus ähnlichen Eingaben heraus erzeugt wurden. Selbst demonstrative Nachbauten werden als relativ leicht beschrieben.
Was das für Sie bedeutet
IOC-basierte Abwehransätze geraten dabei unter Druck. Wenn neue Varianten jede Woche entstehen, wird das „Nachziehen“ anhand fester Fingerprints oder Domains zu langsam. Entscheidend wird daher, Muster zu erkennen, die zum Verhalten des Angriffs gehören.
4) Nicht nur Microsoft: OAuth-Gerätefreigabe ist plattformübergreifend
Heute wird Device-Code-Phishing in vielen Erkennungen stark mit Microsoft-Umgebungen verknüpft. Doch das ist nicht der Endpunkt. Der Kern beruht auf dem OAuth-2.0 Device-Authorization-Grant, einem Standard, der plattformübergreifend implementiert ist.
Damit wird jede Anwendung potenziell zum Ziel, die diesen Gerätefluss unterstützt. Nation-State-Akteure sollen den Angriff bereits gegen andere Anbieter genutzt haben, darunter gezielte Kampagnen, in denen eine bösartige Anwendung über die Gerätefreigabe in größerem Maßstab missbraucht wurde.
Gerade für Teams, die sich bisher ausschließlich auf Microsoft-spezifische Maßnahmen konzentriert haben, ist das der Wendepunkt: Device-Code-Phishing wirkt über Unternehmensgrenzen und Anbieter hinweg. Beispiele, die im Zusammenhang genannt werden, sind unter anderem GitHub und AWS – dort ist der Gerätefluss im Kontext von Entwickler-Workflows bzw. Authentifizierung für Tools und Tunnel relevant.
5) Teil einer größeren Verschiebung: von Auth zu Autorisierung
Device-Code-Phishing ist nicht isoliert. Es passt in eine breitere Entwicklung: Angreifer verlagern den Fokus weg von der Authentifizierungsschicht, weil dort viele Verteidigungsmaßnahmen stärker ausgebaut wurden. Die Autorisierung und das Zusammenspiel von Zustimmung, Registrierung und Token-Austausch erhielten dagegen vergleichsweise weniger Aufmerksamkeit.
In diesem Kontext werden auch andere OAuth-orientierte Consent- und Freigabeangriffe erwähnt, bei denen Opfer nach erfolgreicher Anmeldung in nachgelagerte Zustimmungsschritte gezogen werden. Wie bei Device-Code-Phishing basiert die Wirksamkeit darauf, dass Sicherheitskontrollen häufig dort ansetzen, wo der Identitätsbeweis stattfindet – und nicht dort, wo die Zugriffsfreigabe endgültig erteilt wird.
Solange diese Lücke bestehen bleibt, dürfte die Angriffsfläche wachsen. Neue Methoden werden entwickelt, während bestehende Kontrollen die falsche Stelle adressieren.
6) Erkennung muss dort stattfinden, wo die Freigabe passiert
Ein oft unterschätzter Punkt ist die „Transportlogik“: Die Phishing-Seite kann über sehr unterschiedliche Kanäle ausgeliefert werden – von E-Mail und Messengern bis hin zu Social Media, Suchergebnissen oder kompromittierten Webseiten. Doch die eigentliche Wirkung entsteht erst, wenn Nutzer den Code auf einer legitimen Anbieter-URL eingeben und die Freigabe erteilen.
Dadurch laufen klassische Schutzansätze (z. B. Proxy-Regeln, URL-Reputation oder E-Mail-Gateways) häufig ins Leere. Denn die entscheidende Interaktion findet auf Infrastruktur statt, die für den Anbieter selbst vertrauenswürdig wirkt.
Warum „nur blockieren“ selten reicht
In Microsoft-Umgebungen wird oft empfohlen, Geräteauthentifizierungsflüsse über Conditional Access einzuschränken. Das kann sinnvoll sein – ist aber nicht immer durchführbar, weil Geräteflüsse legitime Zwecke erfüllen. Größere Organisationen können sich daher häufig nicht leisten, diese Features pauschal abzuschalten, ohne wichtige Entwickler- und CLI-Workflows zu beschädigen.
Und selbst wenn Microsoft vollständig abgesichert würde, bliebe das Problem bestehen, sobald Angriffe auf andere Plattformen zielen, für die vergleichbare Conditional-Access-Steuerungen nicht in gleicher Form existieren oder nicht so granular umgesetzt werden können.
Der Browser als entscheidender Beobachtungspunkt
Die Situation wird dann besonders klar: Der Moment, in dem Opfer den Köder sehen und gleichzeitig die Gerätefreigabe im richtigen Freigabe-Dialog bestätigen, lässt sich am zuverlässigsten im Browser-Kontext beobachten. Genau dort entsteht die „Brücke“ zwischen Phishing-Element und der endgültigen Zustimmung.
Entsprechend werden auch Ansätze beschrieben, die nicht auf konkrete Kit-Fingerprints oder einzelne Domains setzen, sondern auf Verhalten und den Ablauf der Gerätefreigabe. Das hilft besonders dann, wenn neue Kits schnell auftauchen und IOC-Blocklisten kaum Schritt halten.
Praktische Konsequenzen für Sicherheitsteams
Wenn Device-Code-Phishing so schnell skaliert, müssen Verteidigung und Monitoring ebenfalls näher an den eigentlichen Schritt der Freigabe rücken. Je nach Architektur und Risikoappetit lassen sich zum Beispiel folgende Leitideen ableiten:
- Autorisierung genauer prüfen: Achten Sie darauf, wie und wo Zustimmung erteilt wird – nicht nur darauf, wie Anmeldungen stattfinden.
- Conditional Access gezielt nutzen: Wo möglich, lassen sich Gerätefreigaben einschränken. Gleichzeitig sollten Sie legitime Workflows validieren, damit nichts „kaputt-konfiguriert“ wird.
- Plattformübergreifend denken: Device-Code-Phishing ist nicht auf einen Anbieter beschränkt, weil OAuth Device-Authorization überall dort greift, wo es implementiert ist.
- Detektion im Browser-Kontext: Beobachten Sie die Sequenz aus Codeingabe und Freigabedialog. Das liefert eine stabilere Grundlage als reine IOC-Listen.
Zusätzlich lohnt sich ein Abgleich mit Ihrem aktuellen Threat-Model: Wenn Teams bisher primär Authentifizierungssignale abgesichert haben, kann der nächste Angriffsschwerpunkt bereits „dahinter“ liegen.
Fazit
Device-Code-Phishing wächst 2026 so stark, weil es die Schwachstelle in der digitalen Zugriffskette ausnutzt: die Autorisierung nach erfolgreicher Anmeldung. Es umgeht MFA einschließlich moderner Passkey-Ansätze, wird durch PhaaS-Ökosysteme industrialisiert und kommt durch AI-gestützte Entwicklung in vielen Varianten gleichzeitig. Gleichzeitig zeigt der plattformübergreifende OAuth-Gerätefluss, dass sich Schutzmaßnahmen nicht nur auf Microsoft beschränken dürfen.
Wer wirksam reagieren will, sollte vor allem die Freigabe selbst in den Mittelpunkt stellen – und Detektion dort ausbauen, wo der Nutzer zustimmt, etwa im Browser-Kontext.
Quelle: https://thehackernews.com/2026/07/6-reasons-why-device-code-phishing-is.html
