Device Code Phishing: Die Bedrohung, die MFA wirkungslos macht

Wenn die Multi-Faktor-Authentifizierung nicht mehr ausreicht, liegt die Erklärung im Device Code Phishing. Die Technik nutzt den Device Authorization Grant von OAuth 2.0 (RFC 8628), um Zugriffstoken einer bereits authentifizierten Sitzung zu stehlen – und überspringt damit jeden zweiten Faktor: Passkeys, Hardware-Token, OTP-Codes. Was 2020 noch eine Randnotiz war, ist heute ein industrielles Phänomen, befeuert durch fertige Kits und zunehmend mithilfe von Sprachmodellen erzeugt.

Wie MFA umgangen wird – selbst mit Passkeys

Der Mechanismus umgeht die Authentifizierungsphase vollständig, indem er das dem Geräteautorisierungsfluss entgegengebrachte Vertrauen ausnutzt. Der Angreifer startet das Device-Code-Verfahren bei einem Dienst (z. B. Microsoft Entra ID) und erhält einen alphanumerischen Code sowie eine Verifizierungs-URL. Anschließend täuscht er das Opfer, sodass es diese URL – eine vollkommen legitime Adresse wie login.microsoftonline.com – besucht und den Code eingibt. Der Nutzer sieht die echte Anmeldeseite des Anbieters, meldet sich mit seinen Zugangsdaten an und schließt die MFA ab, wobei er unwissentlich die OAuth-Einwilligung erteilt. Zu diesem Zeitpunkt erhält der Client des Angreifers die Token (Access- und Refresh-Token), die dauerhaften Zugriff gewähren – ohne dass jemals eine Login-Seite nachgebaut wurde.

Die klassische Abwehr, die auf das Erkennen gefälschter URLs setzt, greift hier nicht. Die gesamte Kette spielt sich auf vertrauenswürdigen Domains ab; das Phishing besteht darin, jemanden zur Eingabe eines Codes zu bewegen, nicht zum Preisgeben eines Passworts.

Die Eskalation: von nation-state zu 7 Millionen Angriffen in vier Wochen

Nach ersten zaghaften Beschreibungen im Jahr 2020 tauchte Device Code Phishing 2024 erstmals bei staatlichen Akteuren auf. Die eigentliche Industrialisierung erfolgte 2025 mit der Kampagne von ShinyHunters gegen Salesforce: über 1.000 kompromittierte Organisationen und 1,5 Milliarden abgeflossene Datensätze. Spätestens da wurde klar, dass die Technik zur Massenwaffe geworden war.

Im Februar 2026 senkte das Kit EvilTokens die Einstiegshürde weiter und machte den Angriff auch für Kriminelle ohne Spezialkenntnisse replizierbar. Im April meldete Microsoft täglich 10 bis 15 neue Kampagnen, und in den vier hektischen Wochen darauf zählte Barracuda 7 Millionen Angriffe. Im Mai integrierte die PhaaS-Plattform Tycoon2FA den Device-Code-Fluss nativ. Heute verfolgt Push Security mehr als 25 Kit-Familien – ein Ökosystem, zu dem auch Kits wie ARToken gehören, das in der Lage ist, Primary Refresh Tokens (PRT) zu erbeuten, um Persistenz, Zugriff auf E-Mails, Exfiltration aus SharePoint und BEC-Automatismen zu ermöglichen.

Das FBI gab eine eigenständige Warnung zum Kit Kali365 heraus – die erste Mitteilung einer US-Bundesbehörde, die einem bestimmten Phishing-as-a-Service-Dienst gewidmet war. Gleichzeitig beschleunigt die KI-gestützte Generierung – das sogenannte „Vibe‑Coding“ – das Entstehen neuer Varianten und macht die Bedrohung immer schwerer eindämmbar.

Nicht mehr nur Login: Der Paradigmenwechsel hin zur Autorisierung

Das Phänomen ist Teil eines breiteren Trends, der das Ziel von der Authentifizierung zur Autorisierung verlagert. Techniken wie ConsentFix, das Ende 2025 auftauchte, zielen direkt auf den Missbrauch der OAuth-Einwilligung ab, und auch das Device Code Phishing operiert auf der Ebene der Rechtevergabe, nicht auf dem Abgreifen von Anmeldedaten. Das Ergebnis ist eine Angriffsklasse, die klassische Intrusion-Detection-Systeme, die auf die Login-Phase ausgerichtet sind, nicht erkennen.

Heute richten sich 99 % der beobachteten Angriffe auf Microsoft-Konten, aber der Device-Code-Fluss wird ebenso von GitHub, AWS und anderen Cloud-Anbietern unterstützt – sie werden damit zu potenziellen Zielen. Die Kompromittierung beschränkt sich nicht auf den Erstzugang; der Diebstahl von PRT erlaubt es, über lange Zeit in der Tenant präsent zu bleiben. Und die Daten zeigen: Der Schaden ist längst real, keine bloße Prognose.

Was eine Organisation tun kann

Da MFA keinen Schutzschild mehr darstellt, muss die Verteidigung auf die Kontrolle der Autorisierung verlagert werden.

• Device Grant einschränken: Den Geräteautorisierungsfluss für alle Anwendungen deaktivieren, die ihn nicht zwingend benötigen. Ist das nicht möglich, Conditional-Access-Richtlinien anwenden, die Anfragen mit Device Code von nicht anerkannten IP-Adressen, Geräten oder Kontexten blockieren.
• OAuth-Einwilligungen überwachen: Jede Berechtigungserteilung an unbekannte Apps genau prüfen, selbst wenn die zugrunde liegende Authentifizierung legitim erscheint. Plattformen wie Microsoft Entra ID ermöglichen Alerting bei neuen Einwilligungen und eine automatische Rücknahme durch die Erkennung von Consent-Phishing.
• Benutzer schulen: Erklären, dass niemals ein Kopplungscode eingegeben werden darf, der per E-Mail, SMS oder Chat eintrifft – auch dann nicht, wenn der Link auf eine vertraute Anmeldeseite führt. Das Vorhandensein von MFA ist keine Sicherheitsgarantie.
• Autorisierung in das SOC integrieren: Erkennungsregeln einführen, die anomale Muster in OAuth-Flows und bei Refresh-Tokens beobachten. Sich allein auf die Authentifizierung zu konzentrieren, macht blind für einen Angriff, der beginnt, wenn der Benutzer bereits eingeloggt ist.

Device Code Phishing ist keine marginale Weiterentwicklung – es ist der Beleg dafür, dass sich das Spielfeld endgültig jenseits des Passworts verlagert hat. Diesen Wandel zu ignorieren bedeutet, die Tür offen zu lassen, nachdem man das Schloss verstärkt hat.