Julia Wolf
Ein achtstelliger Code landet in Ihrem Postfach. Getarnt als Einladung zum nächsten Town-Hall-Meeting, als Hinweis auf eine ausstehende Gehaltsabrechnung oder als dringliche IT-Sicherheitsmitteilung. Sie geben den Code ein – auf einer echten Microsoft-Seite, wohlgemerkt. Kein gefälschtes Login-Formular, keine dubiose Domain. Und trotzdem haben Sie soeben sämtliche E-Mails, SharePoint-Dokumente und Teams-Chats Ihres Unternehmens in fremde Hände gegeben. Device-Code-Phishing ist kein Science-Fiction-Szenario. Es ist Realität. Und es trifft gerade jetzt Unternehmen in einem Ausmaß, das selbst erfahrene Security-Teams kalt erwischt.
Der Begriff klingt technisch, fast harmlos. Device-Code-Phishing. Als würde jemand den Aktivierungscode für einen Smart-TV abgreifen. Das Pikante daran: Genau das ist der Kern des Angriffs – nur dass der Smart-TV in diesem Fall Ihr Microsoft-365-Unternehmensaccount ist, und der „Aktivierungscode“ vollständigen Zugriff auf Ihre Identität im Cloud-Ökosystem verschafft.
Der OAuth 2.0 Device Authorization Grant ist ein legitimer Standard. Entwickelt für Geräte ohne Tastatur – Smart-TVs, Drucker, IoT-Sensoren, Kiosk-Terminals. Das klassische Szenario: Sie wollen Netflix auf dem Fernseher einrichten, tippen einen kurzen Code auf einem anderen Gerät ein, und der Fernseher ist authentifiziert. Kein Passwort, kein komplizierter Login-Flow. Elegant, praktisch, durchdacht.
Angreifer haben diese Eleganz längst für sich entdeckt. Der Device-Code-Phishing-Angriff beginnt technisch sauber: Jemand startet eine echte OAuth-Anfrage gegen Microsofts Endpunkt /oauth2/v2.0/devicecode. Microsoft antwortet mit zwei Codes – einem internen device_code und einem für Menschen lesbaren user_code, beispielsweise „EL4BGRHUZ“. Der Angreifer sendet diesen user_code per Phishing-Mail ans Opfer, mit der Aufforderung, die echte Microsoft-Seite aufzurufen und den Code einzugeben. Während das Opfer das tut, pollt der Angreifer im Hintergrund Microsofts Token-Endpunkt. Sobald das Opfer bestätigt: Access-Token. Refresh-Token. Game over.
Wenig überraschend: Der gesamte Authentifizierungsvorgang findet auf legitimen Microsoft-Infrastrukturen statt. Kein gefälschtes Formular. Keine manipulierte URL. Der Browser zeigt login.microsoftonline.com – vollständig, echt, mit grünem Schloss. Das macht Device-Code-Phishing zu einer der perfidesten Angriffsmethoden, die Security-Teams aktuell zu bewältigen haben.
Schritt eins. Der Angreifer ruft den Device-Authorization-Endpunkt auf – automatisiert, über ein Script oder eines der mittlerweile kursierenden Phishing-as-a-Service-Kits. Microsoft liefert prompt: den user_code mit einer Gültigkeitsdauer von typischerweise 15 Minuten sowie eine Verification-URL, standardmäßig microsoft.com/devicelogin.
Schritt zwei. Die Phishing-Mail landet beim Opfer. Sie ist sorgfältig gestaltet – oft mit dem Corporate Design des eigenen Unternehmens, dem Logo des vermeintlichen Absenders, einer plausiblen Betreffzeile. Klassische Tarnungen: „Ihr Gehaltsnachweis für März steht bereit“, „Bitte bestätigen Sie Ihren Zugang zur Jahresplanung“, „Sicherheitsüberprüfung Ihres Accounts erforderlich“. Der user_code steht prominent in der Mail, dazu die legitime Anleitung, wie man ihn eingibt.
Schritt drei. Das Opfer navigiert zu microsoft.com/devicelogin – einer echten Microsoft-Seite –, gibt den Code ein und meldet sich mit seinen normalen Zugangsdaten an. MFA-Prompt erscheint? Wird vom Opfer selbst bestätigt, denn es glaubt ja an einen legitimen Vorgang. Das Gerät wird als autorisiert markiert.
Schritt vier ist der entscheidende. Parallel pollt der Angreifer den Token-Endpunkt. Millisekunden nach der Bestätigung durch das Opfer treffen Access-Token und Refresh-Token ein. Der Access-Token gewährt sofortigen Zugriff auf Microsoft Graph, Outlook, SharePoint, Teams, OneDrive. Der Refresh-Token – und das ist der wirklich unangenehme Teil – ist langlebig. Er ermöglicht es, immer wieder neue Access-Tokens zu generieren, ohne dass das Opfer nochmals aktiv werden muss. Conditional Access Policies? Oft wirkungslos, denn der Token suggeriert einen legitimen, bereits autorisierten Vorgang.
Plot Twist: Die Multi-Faktor-Authentifizierung schützt hier nicht. Sie wird nicht überwunden, sie wird vom Opfer selbst bestätigt. Das ist keine technische Schwäche der MFA – es ist eine konzeptionelle Lücke in der Art, wie Nutzer den Device-Authorization-Flow verstehen oder eben nicht verstehen.
Zahlen schaffen Kontext. Barracuda meldete Ende April 2026, dass in den vorausgegangenen vier Wochen rund sieben Millionen Device-Code-Phishing-Angriffe registriert wurden – laut Security Today ein Volumen, das auf den gezielten Exploit adaptiver MFA-Mechanismen hindeutet. Sieben Millionen. In vier Wochen. Das ist kein Nischenangriff mehr, das ist industrielle Skalierung.
Device-Code-Phishing trifft primär Nutzer von Microsoft 365 und Entra ID, hat aber längst auf Google Cloud und Azure-Infrastrukturen übergegriffen. Russische Bedrohungsakteure wurden in mehreren gezielten Kampagnen beobachtet, die diese Methode nutzen – mit klarem Fokus auf Unternehmen, Behörden und Organisationen mit wertvollen Datenpools.
Das Wachstum der Angriffszahlen korreliert direkt mit der Verbreitung von Phishing-as-a-Service-Kits. EvilTokens ist eines davon – ein Tool, das Device-Code-Phishing als buchstäblichen Service verkauft: vorkonfigurierte Angriffs-Infrastruktur, Vorlagen für Phishing-Mails, automatisiertes Token-Polling, Verwaltungsoberfläche. Sekoia hat EvilTokens in einer detaillierten Analyse seziert und dabei Indikatoren wie spezifische API-Pfade (/api/device/start) und Antibot-Token identifiziert. Device-Code-Phishing ist also nicht mehr die Domäne hochspezialisierter APT-Gruppen – es ist demokratisiertes Angriffswerkzeug.
Der Clou dabei: Die niedrige technische Einstiegshürde macht OAuth-Sicherheit zu einem Problem, das nicht länger nur für große Konzerne relevant ist. Mittelständische Unternehmen, die Microsoft 365 nutzen und keine dedizierte Security-Abteilung haben, sind besonders exponiert. Device-Code-Phishing trifft genau dort, wo Sicherheitsbewusstsein und technische Schutzmaßnahmen noch Lücken haben.
Herkömmliches Phishing-Awareness-Training setzt auf bekannte Muster: gefälschte Domains, fehlerhafte Grammatik, verdächtige Anhänge, Aufforderung zur Passworteingabe auf dubiosen Seiten. Device-Code-Phishing erfüllt keines dieser Kriterien. Kein einziges.
Die Phishing-Mail muss keine schadhaften Links enthalten. Sie verweist auf microsoft.com/devicelogin – eine Adresse, die jede URL-Prüfung als legitim durchwinkt. Kein Anhang, keine Malware, kein Drive-by-Download. Der Inhalt ist technisch einwandfrei. E-Mail-Sicherheitsgateways, die auf verdächtige URLs oder Dateianhänge filtern, sehen schlicht: nichts Auffälliges.
Auch SEG-Lösungen (Secure Email Gateways) stoßen hier an ihre Grenzen. Sie können den user_code in einer Mail nicht als Angriffssignal werten – der Code ist eine harmlose Zeichenkette. Kein Payload, keine ausführbare Komponente, kein Redirect zu einer Phishing-Site. Der Angriff findet gewissermaßen „außerhalb“ der traditionellen Angriffsinfrastruktur statt, auf legitimem Microsoft-Grund und Boden.
Hinzu kommt das Problem der Glaubwürdigkeit. Wenn ein Nutzer tatsächlich auf microsoft.com/devicelogin navigiert, die vertraute Microsoft-Anmeldeoberfläche sieht und seinen MFA-Prompt wie gewohnt bestätigt, gibt es keinen Moment der Irritation – keinen Punkt, an dem das Gehirn „hier stimmt etwas nicht“ signalisiert. Das Erlebnis ist identisch mit einem legitimen Device-Authorization-Vorgang. Und genau das macht es so gefährlich. Ich würde behaupten, dass diese Angriffsmethode aktuell die höchste Erfolgsrate unter allen Social-Engineering-Vektoren hat – eben weil sie keinen Fehler macht, den ein wachsamer Nutzer erkennen könnte.
OAuth-Sicherheit dreht sich zunehmend um eine unbequeme Wahrheit: Wer Tokens hat, braucht keine Passwörter. Das ist das Fundament moderner Cloud-Architekturen – und gleichzeitig ihre Achillesferse, wenn Tokens in die falschen Hände geraten.
Der Access-Token, den ein Angreifer nach erfolgreichem Device-Code-Phishing erhält, gilt als legitim. Er wurde durch eine vollständige Authentifizierung des Opfers erzeugt, inklusive MFA. Microsoft – oder Google, oder Azure – hat keinen Grund, diesen Token zu misstrauen. Er gibt Zugriff auf die Microsoft Graph API, was im Klartext bedeutet: Outlook-E-Mails lesen, schreiben, weiterleiten; SharePoint-Dokumente abrufen und exfiltrieren; Teams-Nachrichten einsehen; Kontakte und Kalendereinträge abrufen.
Der Refresh-Token ist noch kritischer. Seine Gültigkeitsdauer kann Tage, manchmal Wochen betragen. Solange der Refresh-Token nicht widerrufen wird, kann ein Angreifer kontinuierlich neue Access-Tokens generieren – ohne jede weitere Nutzerinteraktion, ohne neuen MFA-Prompt, ohne dass das Opfer etwas bemerkt. OAuth-Sicherheit wird damit zu einem Moving-Target-Problem: Das ursprüngliche Angriffsfenster von 15 Minuten schließt sich zwar, aber die Persistenz besteht fort.
Elastic Security Labs hat in ihrer Analyse einen besonders brisanten Folgeschritt beschrieben: den Übergang zum Primary Refresh Token (PRT) via Device Registration Service. Wenn ein Angreifer nicht nur Tokens hat, sondern ein Gerät im Azure-AD-Verzeichnis registriert, emuliert er ein „vertrauenswürdiges“ Gerät – mit allen Rechten, die Conditional Access Policies für konforme Geräte vorsehen. Lateral Movement durch das gesamte Cloud-Ökosystem wird dadurch deutlich einfacher. Account-Schutz auf Token-Ebene ist damit keine Option mehr, sondern eine Notwendigkeit.
Device-Code-Phishing wäre halb so gefährlich, wenn seine Durchführung tiefes technisches Know-how erfordern würde. Das tut es nicht mehr. Phishing-as-a-Service-Plattformen wie EvilTokens haben den Angriff in ein Produkt verwandelt – vollständig paketiert, mit Dokumentation, Support und skalierbarer Infrastruktur.
EvilTokens, analysiert von Sekoia, liefert vorkonfigurierte Angriffs-Templates, automatisiertes Token-Polling, Verwaltungsinterfaces und sogar Antidetections-Maßnahmen gegen bekannte Sicherheitsanalyse-Systeme. Die spezifischen API-Pfade, die Sekoia identifiziert hat – darunter /api/device/start und spezielle Header-Werte –, erlauben Security-Teams, diese Kits in Netzwerkprotokollen zu erkennen. Aber nur, wenn sie danach suchen.
Das Phishing-Kit-Ökosystem entwickelt sich dabei parallel zur Verteidigung: Jede neue Erkennungssignatur zieht eine Anpassung des Kits nach sich. EvilTokens ist nicht das einzige Kit dieser Art – es ist das bekannteste. Im Darknet existieren Dutzende ähnlicher Werkzeuge, teils für einmalige Gebühren, teils als monatliches Abo. Device-Code-Phishing ist damit nicht mehr an technische Kompetenz gebunden, sondern nur noch an die Bereitschaft, einen dreistelligen Dollar-Betrag zu investieren.
Für Unternehmen bedeutet das eine drastische Veränderung der Bedrohungslandschaft. Es geht nicht mehr nur um staatliche Akteure oder hochspezialisierte Cybercrime-Gruppen. Device-Code-Phishing ist jetzt das Werkzeug des durchschnittlich versierten Kriminellen – und das bei einem Angriff, der MFA umgeht und OAuth-Sicherheit aushebelt. Brisant ist dabei besonders, dass 8com in ihrer Analyse betont, wie wenig bekannt dieses Angriffsmuster noch bei vielen IT-Verantwortlichen ist – während die Angriffszahlen längst explodiert sind.
Die gute Nachricht zuerst: Device-Code-Phishing hinterlässt Spuren. Die schlechte: Diese Spuren sind nur sichtbar, wenn man aktiv danach sucht und die richtigen Monitoring-Systeme implementiert hat.
Das stärkste Erkennungssignal ist das gleichzeitige Login von mehreren IP-Adressen oder aus ungewöhnlichen Geografien kurz nach einer Device-Code-Autorisierung. Wenn ein Nutzer seinen Code in München eingibt, aber Sekunden später Token-Anfragen aus Amsterdam, Kiew oder einem AWS-Rechenzentrum in Dublin eintreffen – das ist kein normaler Anwendungsfall. SIEM-Systeme sollten auf genau dieses Muster konfiguriert sein.
Weitere Erkennungssignale auf technischer Ebene:
Elastic Security Labs hat spezifische Detection-Rules für Microsoft Entra ID und OAuth-Phishing-Flows entwickelt, die in ELK-Stack-Umgebungen integriert werden können. Wer SIEM-Kapazitäten hat, sollte diese Regeln priorisiert implementieren.
Montag, 08:47 Uhr. Die Buchhalterin eines mittelständischen Maschinenbauers erhält eine Mail, scheinbar von der IT-Abteilung. Betreff: „Sicherheitsüberprüfung Ihres Microsoft-Accounts erforderlich – Handlungsbedarf bis 10:00 Uhr“. Die Mail enthält das Unternehmenslogo, den korrekten Footer mit Impressum und einen Code: „Bitte navigieren Sie zu microsoft.com/devicelogin und geben Sie folgenden Code ein: GJ7NHQPRT“. Der Zeitdruck erzeugt Handlungsimpuls. Sie öffnet die Seite, gibt den Code ein, bestätigt ihren MFA-Prompt via Authenticator-App.
08:49 Uhr: Die Angreifer haben Access- und Refresh-Token. Sie beginnen sofort, Outlook-Mails zu exportieren – insbesondere die Kommunikation mit Lieferanten und Kunden. 72 Stunden später: Eine gefälschte Überweisung über 87.000 Euro auf ein betrügerisches Konto. Business Email Compromise in Reinform, ermöglicht durch Device-Code-Phishing und gestützt auf echte Kontodaten, echte Kommunikationshistorien, echte Schreibstile. Semantisch passt dazu unser Hintergrund Cybersicherheit: Ansätze zur Lösung für eine sicherere digitale Welt.
Ein Projektmanager in einer Rechtsanwaltskanzlei erhält eine Teams-Meeting-Einladung für ein Client-Briefing. Der Absender ist ein bekannter Kontakt – dessen Account war bereits kompromittiert. Die Einladung enthält einen „Sicherheitslink für externe Teilnehmer“ und einen Device-Code für das Meeting-System. Der Projektmanager, geübt im Umgang mit externen Kollaborationstools, gibt den Code ein. Device-Code-Phishing als Kettenreaktion: Ein kompromittierter Account infiziert den nächsten, und der nächsten. Das ist es, was Security-Teams als laterale Ausbreitung via Social Trust bezeichnet – und es funktioniert erschreckend gut.
Freitagmittag – klassisches Timing für Social-Engineering-Angriffe. Eine HR-Mitarbeiterin erhält eine Nachricht, die aussieht wie eine interne Mitteilung des Lohnbuchhaltungssystems: „Ihr Gehaltsnachweis für den laufenden Monat steht bereit. Zur Ansicht authentifizieren Sie sich bitte über den Microsoft-Sicherheitscode: YK3MNRWXP.“ Die Erwartungshaltung (Gehaltsabrechnung kommt regulär zum Monatsende) senkt die Wachsamkeit. OAuth-Sicherheit interessiert in diesem Moment niemanden. Der Code wird eingegeben. Der Angriff ist abgeschlossen, bevor der erste Schluck Kaffee nach der Mittagspause getrunken ist. Semantisch passt dazu unser Hintergrund Digitale Zertifikate: Der unsichtbare Schutzschild für Ihre Online-Sicherheit.
Device-Code-Phishing ist kein unabwendbares Schicksal. Es gibt konkrete, umsetzbare Gegenmaßnahmen – auf technischer, organisatorischer und nutzerbildungsbezogener Ebene. Der Account-Schutz beginnt hier.
Die effektivste technische Maßnahme ist die Deaktivierung des Device-Code-Flows über Conditional Access Policies in Microsoft Entra ID. Das klingt radikal, ist aber für die meisten Unternehmensumgebungen problemlos umsetzbar – denn der Device-Authorization-Grant wird im normalen Arbeitsalltag auf PCs, Laptops und Smartphones schlicht nicht benötigt.
Die Konfiguration erfolgt in Entra ID unter „Conditional Access“ → „Authentication flows“ → Device Code Flow deaktivieren oder auf spezifische, vertrauenswürdige Anwendungen und Geräteklassen beschränken. Wer Smart-TVs, Kiosk-Terminals oder andere Geräte ohne Browser tatsächlich im Unternehmenseinsatz hat, definiert Ausnahmen für genau diese Geräteklassen – nicht pauschal für alle Nutzer.
Zusätzliche technische Maßnahmen für robuste OAuth-Sicherheit:
Technische Maßnahmen greifen nur, wenn organisatorische Prozesse sie flankieren. Für Unternehmens-Account-Schutz bei Device-Code-Phishing sind folgende Punkte essenziell:
Erstens: Klare Kommunikationsrichtlinie für Device-Codes. IT-Abteilungen sollten aktiv kommunizieren, dass sie niemals per E-Mail Device-Codes versenden. Weder für Sicherheitsüberprüfungen, noch für System-Updates, noch für Meeting-Authentifizierungen. Wenn ein Code in der Mail ist, der in eine Microsoft- oder Google-Seite eingegeben werden soll und aus einer nicht persönlich initiierten Situation stammt: Nicht eingeben, IT informieren.
Zweitens: Incident-Response-Plan für Token-Kompromittierung. Was passiert, wenn ein Device-Code-Phishing-Angriff erfolgreich war? Der Plan muss folgende Schritte abdecken: sofortiger Widerruf aller aktiven Token des betroffenen Accounts (via Entra-Admin-Center oder PowerShell), Invalidierung aller aktiven Sessions, Passwort-Reset, Überprüfung der Audit-Logs auf exfiltrierte Daten, Notification betroffener Personen und – falls geschäftliche Kommunikation betroffen – der Kunden und Partner.
Drittens: Regelmäßige Überprüfung aktiver OAuth-App-Konsente. Nutzer haben oft über die Zeit hinweg einer Vielzahl von Apps OAuth-Zugriff gewährt. Diese Liste sollte quartalsweise bereinigt werden. Apps, die keinen aktuellen Geschäftszweck haben, verlieren ihren Zugriff.
Device-Code-Phishing ist ein Angriff auf menschliches Verhalten, nicht auf technische Systeme. Die menschliche Komponente des Account-Schutzes ist daher ebenso wichtig wie technische Maßnahmen – auch wenn sie allein nicht ausreicht.
Awareness-Training muss den Device-Code-Phishing-Angriff explizit thematisieren. Klassische Phishing-Schulungen decken ihn nicht ab. Nutzer müssen verstehen: Eine Mail mit einem Code, den sie auf einer Microsoft- oder Google-Seite eingeben sollen, ohne dass sie selbst einen solchen Prozess gestartet haben, ist ein Angriffsindikator – unabhängig davon, wie legitim die Seite aussieht.
Praktische Übungen sind hier besonders wirkungsvoll. Simulierte Device-Code-Phishing-Angriffe – mit anschließendem Lerneffekt statt Bestrafung – sensibilisieren deutlich effektiver als Folien-Präsentationen. Security-Awareness-Plattformen wie KnowBe4 oder Proofpoint bieten entsprechende Templates bereits an.
Eine einfache Faustregel für Nutzer, die sich merken lässt: Ich initiiere, ich gebe ein. Wenn ich den Prozess nicht selbst gestartet habe, gebe ich nichts ein. So einfach, so klar, so effektiv als erste mentale Schutzbarriere gegen Device-Code-Phishing.
Eine berechtigte rhetorische Frage drängt sich auf: Warum hat Microsoft den Device-Code-Flow nicht längst standardmäßig deaktiviert oder mit zusätzlichen Schutzmechanismen versehen, wenn die Angriffszahlen in Millionenhöhe gehen?
Die Antwort ist komplex. Der Device-Authorization-Grant ist ein RFC-Standard (RFC 8628) – Microsoft implementiert ihn, weil er für legitime Anwendungsfälle gebraucht wird und weil eine Deaktivierung by default viele legitime Unternehmensanwendungen brechen würde. Trotzdem gibt es Bewegung: Microsoft hat in den letzten Monaten die Möglichkeiten für Conditional-Access-basierte Einschränkungen des Device-Code-Flows erweitert und Security-Defaults in neuen Tenants angepasst.
Meiner Einschätzung nach ist das zu wenig, zu spät. Bei sieben Millionen Angriffen in vier Wochen wäre eine stärkere Standardkonfiguration – Device-Code-Flow off by default, mit expliziter Opt-in-Möglichkeit für Unternehmen, die ihn tatsächlich brauchen – das Mindeste, was man erwarten könnte. Aber Plattformbetreiber balancieren immer zwischen Sicherheit und Kompatibilität, zwischen Schutz und Nutzerfreundlichkeit. Diese Abwägung geht nicht immer zugunsten der Sicherheit aus.
Google Cloud und Azure stehen vor denselben Herausforderungen. OAuth 2.0 ist das Fundament moderner Cloud-Authentifizierung – und Device-Code-Phishing ist der Beweis, dass ein gut durchdachter Standard durch ebenso gut durchdachtes Social Engineering ausgehebelt werden kann. OAuth-Sicherheit ist damit nicht nur eine Frage der Implementierung, sondern der gesamten Ökosystem-Verantwortung.
Für Security-Teams, die heute mit der Implementierung beginnen wollen, ist eine priorisierte Vorgehensweise sinnvoll. Device-Code-Phishing erfordert sowohl präventive als auch detektive Maßnahmen.
Noch diese Woche: In Microsoft Entra ID den Device-Code-Flow für alle Nutzer deaktivieren, sofern kein legitimer Geschäftsbedarf besteht. Ausnahmen für spezifische Service-Accounts oder Geräteklassen definieren. Dieser Schritt allein eliminiert das Angriffsfenster für den überwiegenden Teil der Nutzer.
Unified Audit Log in Microsoft 365 muss für alle Nutzer aktiviert sein – das ist in vielen Tenants keine Selbstverständlichkeit, insbesondere bei älteren Konfigurationen oder günstigeren Lizenzmodellen. Ohne Logging keine Detection. Danach: SIEM-Regeln für Device-Code-Authorization-Events, Token-Nutzung von unbekannten IPs und massenhafte Graph-API-Abfragen konfigurieren. Elastic Security Labs stellt dafür kostenlos verfügbare Detection-Rules bereit.
Wie schnell kann Ihr Team im Ernstfall alle aktiven Token eines kompromittierten Accounts widerrufen? Dieser Prozess sollte nicht das erste Mal im Ernstfall durchgeführt werden. Tabletop-Übungen, die einen Device-Code-Phishing-Angriff simulieren und den vollständigen Response-Prozess durchspielen, sind für jedes Unternehmen mit Microsoft-365-Einsatz empfehlenswert.
Welche OAuth-Anwendungen haben in Ihrem Tenant Zugriff auf Nutzerdaten? Die Antwort auf diese Frage sollte jeder IT-Verantwortliche kennen – und regelmäßig aktualisieren. Microsoft Entra ID bietet unter „Enterprise Applications“ eine vollständige Übersicht aller erteilten OAuth-Konsente. Unbekannte oder nicht mehr genutzte Apps: Zugriff entziehen. OAuth-Sicherheit beginnt mit Überblick über den eigenen Anwendungsbestand.
Die folgende Checkliste fasst alle wesentlichen Maßnahmen für einen robusten Account-Schutz gegen Device-Code-Phishing zusammen:
Device-Code-Phishing steht nicht still. Die Angriffstechnik entwickelt sich in mehrere Richtungen gleichzeitig – und wer jetzt nicht reagiert, wird in zwölf Monaten vor einem erheblich komplexeren Problem stehen. Semantisch passt dazu unser Hintergrund Vibe Coding ist unglaublich: ab 2025 kann wirklich Jeder programmieren – danke, künstliche Intelligenz.
Die Integration mit Primary Refresh Tokens und Device Registration Services ist der nächste Eskalationsschritt. Wenn Angreifer nicht nur Access- und Refresh-Tokens haben, sondern ein vollständig registriertes, „vertrauenswürdiges“ virtuelles Gerät im Azure-AD-Verzeichnis, eröffnen sich Möglichkeiten für Lateral Movement, die mit herkömmlichem Token-Monitoring kaum zu erfassen sind. Elastic Security Labs hat diese Entwicklung als aktiven Trend identifiziert – sie ist kein hypothetisches Szenario, sie passiert bereits.
Die Ausweitung auf Non-Microsoft-Plattformen ist ebenso relevant. Google Cloud, Salesforce, Slack und viele andere OAuth-2.0-Implementierungen unterstützen ebenfalls Device-Authorization-Grants. OAuth-Sicherheit ist daher kein Microsoft-exklusives Problem – es ist ein plattformübergreifendes Architekturproblem, das überall dort auftritt, wo OAuth 2.0 mit Device-Code-Flow implementiert ist.
KI-gestützte Personalisierung der Phishing-Mails wird Device-Code-Phishing noch schwerer erkennbar machen. Wenn die Tarnmail nicht mehr generisch, sondern auf den spezifischen Kontext des Opfers zugeschnitten ist – mit echten Projektnamen, echten Kollegennamen, echten Meeting-Themen –, sinkt die Erkennungswahrscheinlichkeit durch den Nutzer gegen null. Diese Personalisierung wird bereits beobachtet, und sie wird zunehmen.
Phishing-as-a-Service-Kits werden ausgereifter, günstiger und zugänglicher. EvilTokens ist heute. In sechs Monaten gibt es EvilTokens 2.0 mit automatischer Opfer-Profilierung, KI-gestützter Mail-Personalisierung und integriertem BEC-Modul für automatisierten Betrug. Die Entwicklungsgeschwindigkeit auf Angreiferseite ist brutal effizient – und sie orientiert sich direkt an den Schutzmaßnahmen, die Unternehmen implementieren.
Device-Code-Phishing ist der prägnante Beweis dafür, dass Angreifer keine technischen Schwachstellen brauchen. Sie brauchen Protokolle, die legitim sind, und Menschen, die keine Chance haben, den Unterschied zu erkennen. OAuth-Sicherheit und Account-Schutz sind damit keine IT-Randthemen mehr – sie sind Kernaufgaben jeder Unternehmens-Sicherheitsstrategie.
Sieben Millionen Angriffe in vier Wochen. Das ist keine Warnung für die Zukunft. Das ist eine Bestandsaufnahme der Gegenwart. Und die Frage, die bleibt: Wie viele davon haben in Ihrem Unternehmen ihre Ziele erreicht – ohne dass jemand es bemerkt hat?
Wer jetzt handelt, deaktiviert heute noch den Device-Code-Flow in Entra ID, prüft das Unified Audit Log und aktualisiert das nächste Awareness-Training. Wer wartet, wartet darauf, dass die nächste Gehaltsabrechnung in der Phishing-Mail landet – und jemand in Ihrem Team den Code eingibt. Ohne schlechtes Gewissen. Auf einer echten Microsoft-Seite. Vollständig authentifiziert per MFA.
Netatwork hat die technischen Hintergründe der Device-Code-Authentifizierung detailliert aufbereitet – ein Pflichtlektüre-Link für alle, die die technische Tiefe dieser Angriffsmethode verstehen wollen, bevor sie die nächste Sicherheitskonfiguration anfassen.
