Früher war Phishing irgendwie einfacher zu erklären. Da hieß es sinngemäß: „Klick nicht auf komische Links, gib dein Passwort nirgendwo ein."
Heute ist die Lage komplexer, denn moderne Phishing-Angriffe zielen immer öfter gar nicht mehr auf das Passwort, sondern auf den legitimen Anmeldeprozess selbst – und auf das, was danach kommt: Tokens.
Device Code Phishing ist längst kein Randphänomen mehr. Laut Push Security ist die Zahl entsprechender Phishing-Seiten 2026 bereits um mehr als das 37-Fache gestiegen.
Wenn wir uns unsere letzten Blogs so ansehen (zu ClickFix, den Axios-Vorfall oder KI als Risikofaktor), zeichnet sich ein klares Muster ab:
Angriffe werden psychologisch eleganter. Sie sehen normal aus, wirken plausibel und nutzen echte Prozesse, echte Marken und echte Plattformen.
Der OAuth 2.0 Device Authorization Grant – oft einfach Device Code Flow genannt – wurde für Geräte gebaut, die keinen richtigen Browser haben oder nur sehr eingeschränkte Eingaben erlauben, etwa Smart-TVs, IoT-Geräte, Drucker oder andere input-beschränkte Geräte.
Statt sich direkt auf dem Gerät anzumelden, öffnet der Nutzer auf einem zweiten Gerät eine Login-Seite und gibt dort einen Code ein.
Das Problem: Angreifer können genau diesen legitimen Ablauf missbrauchen. Sie erzeugen einen echten Device Code, schicken ihn dem Opfer unter einem glaubwürdigen Vorwand und bringen es dazu, ihn auf einer legitimen Login-Seite einzugeben.
Das Opfer denkt also: „Alles normal, ist ja Microsoft.“ Der Angreifer bekommt danach gültige Access- und Refresh-Tokens und kann damit auf Ressourcen zugreifen, ohne das Passwort zu kennen.
Viele klassische Schutzreflexe laufen damit ins Leere, denn der Nutzer tippt sein Passwort nicht auf einer windigen Fake-Seite ein. Er interagiert mit einem echten Identitätsanbieter und durchläuft einen formal korrekten Authentifizierungsprozess.
Das macht die Masche so effektiv aus Sicht der Angreifer.
Die aktuelle Welle kommt nicht aus dem Nichts. Push Security berichtet, dass neue Phishing-as-a-Service-Kits wie EvilTokens die Methode stark verbreitet haben. Push listet inzwischen mindestens elf Kits, die solche Angriffe unterstützen – mit realistisch wirkenden SaaS-Lockvögeln, Anti-Bot-Schutz und Hosting über bekannte Cloud-Plattformen. Das senkt die Einstiegshürde enorm.
Früher brauchte man dafür mehr Know-how, heute reichen schlechte Absichten und ein Telegram-Account.
Microsoft und Proofpoint zeigen außerdem, dass Device Code Phishing längst nicht nur ein theoretisches Risiko ist. Microsoft beschreibt Kampagnen, bei denen Opfer etwa mit angeblichen Teams-Einladungen geködert werden. Proofpoint beobachtete mehrere Bedrohungsakteure – sowohl staatlich als auch finanziell motivierte – die Microsoft-365-Konten über genau diese OAuth-Mechanik übernehmen.
Das Entscheidende: Passwortdiebstahl verliert an Exklusivität. Angreifer müssen nicht mehr unbedingt dein Kennwort abgreifen, wenn sie stattdessen deine Sitzung, deine Zustimmung oder direkt deine Tokens bekommen.
Ein Token-Diebstahl-Angriff funktioniert selbst dann, wenn der Nutzer bereits MFA erfolgreich durchlaufen hat. Denn der gestohlene Token belegt ja, dass die Authentifizierung bereits stattgefunden hat.
Stell dir vor, jemand aus deinem Unternehmen bekommt eine Nachricht zu einem angeblich dringenden Dokument, einer Vertragsfreigabe oder einer Teams-Besprechung. Statt eines klassischen Login-Fakes landet die Person auf einer echten Microsoft-Seite und soll dort einen Code eingeben. Das wirkt zunächst seriöser als die übliche „Ihr Passwort läuft heute um 13:17 Uhr ab“-Mail.
Diese Art von Lockangeboten taucht in den aktuellen Kampagnen auf: Microsoft beschreibt Teams-Meeting-Köder, Push Security nennt unter anderem DocuSign-, Adobe-, SharePoint-, Office-365- und HR-bezogene Themen.
Nach erfolgreicher Eingabe des Codes erhält der Angreifer gültige Tokens und kann auf Mail, Dateien oder weitere Cloud-Dienste zugreifen – solange diese Tokens gültig sind.
Das ist auch der Grund, warum ein reines „Dann setzt halt schnell das Passwort zurück“ nicht reicht. Bei illicit consent grants und tokenbasierten Angriffen weist Microsoft ausdrücklich darauf hin, dass normale Maßnahmen wie Passwort-Reset oder erneute MFA-Abfrage allein nicht wirksam sind, wenn eine externe App bereits autorisiert wurde oder ein gültiger Token noch aktiv ist.
Wenn Passwörter nicht mehr der einzige Dreh- und Angelpunkt sind, verschiebt sich der Fokus in der Verteidigung. Es reicht nicht mehr, nur auf starke Kennwörter, MFA und Security-Awareness zu setzen. Alles weiterhin wichtig – aber eben nicht mehr ausreichend.
Jetzt geht es zusätzlich darum, wer welche Apps autorisieren darf, welche Flows zugelassen sind, wie Tokens geschützt werden und wie verdächtige Consent- oder Sign-in-Ereignisse überwacht werden.
Das ist Token Governance: klare Regeln, saubere Sichtbarkeit und belastbare Prozesse rund um OAuth-Apps, Berechtigungen, Consent, Sessions und Token-Nutzung.
Nicht nur die Haustür abschließen, sondern auch wissen, wer einen Schlüssel bekommen hat, wer einen Ersatzschlüssel besitzt und wie der Zugang genutzt wird.
Microsoft empfiehlt, Device Code Flow wo immer möglich zu blockieren und ihn nur für klar definierte Ausnahmen freizugeben. Über Conditional Access lässt sich das steuern.
Außerdem sollte zunächst geprüft werden, ob und wo der Flow in der eigenen Organisation überhaupt genutzt wird – etwa über Sign-in-Logs oder Richtlinien im Report-only-Modus.
Für viele Unternehmen ist das der erste große Hebel: Nicht aus Gewohnheit alles offen lassen, nur weil es „ja mal praktisch sein könnte“.
User Consent einschränken, nur vertrauenswürdige Apps zulassen, auf verified publishers achten und Berechtigungen regelmäßig auditieren.
Besonders kritisch sind Anwendungen, die Zugriff auf Mailboxen, Dateien oder Kontakte anfordern. Consent Phishing funktioniert so gut, weil der Anbieter legitim wirkt und Nutzer der Freigabe zustimmen, obwohl die App selbst bösartig oder unnötig weitreichend ist.
Für Entscheider heißt das: App-Freigaben sind kein lästiges Admin-Nebenthema, sondern ein zentraler Bestandteil moderner Sicherheitsarchitektur.
Nutzt für die Untersuchung von Token-Diebstahl unter anderem Sign-in- und Audit-Logs, zentrale SIEM-Sichtbarkeit und passende Alarmierungen. Zusätzlich rät Microsoft bei Consent-bezogenen Angriffen, Audit-Logs regelmäßig auf Aktivitäten wie „Consent to application“ zu prüfen – in großen Umgebungen idealerweise wöchentlich.
Wer hier keine Transparenz hat, merkt im Zweifel erst sehr spät, dass gar kein Passwort kompromittiert wurde – aber trotzdem schon jemand gemütlich im Postfach spazieren geht.
Microsoft bietet mit Token Protection eine Conditional-Access-Session-Control, die Replay-Angriffe reduzieren soll, indem bestimmte Sign-in-Session-Tokens an Geräte gebunden werden.
Wird ein solcher gerätegebundener Token gestohlen, kann er nicht ohne Weiteres auf einem anderen Gerät wiederverwendet werden.
Wichtig ist aber auch: Das ist kein Zaubertrick, sondern ein Baustein. Token Protection hilft, ersetzt aber weder saubere Governance noch Monitoring oder Richtlinienhygiene.
Wenn ein Verdacht besteht, müssen Teams heute anders denken als früher. Neben klassischen Schritten braucht es das Prüfen und Entfernen bösartiger App-Berechtigungen, das Nachvollziehen von Consent-Ereignissen, das Eingrenzen des Zeitfensters und die Untersuchung, welche Ressourcen über diese Tokens erreichbar waren.
Wer nur „Password Reset für alle“ drückt und dann Feierabend macht, hat vielleicht Aktivität gezeigt – aber nicht zwingend das Problem gelöst.
Device Code Phishing ist Teil einer größeren Verschiebung. Angreifer gehen zunehmend dorthin, wo Unternehmen moderner geworden sind: Cloud, Identität, OAuth, API-Zugriffe, appbasierte Freigaben und tokenisierte Sitzungen.
Das Sicherheitsverständnis aus der „Passwort + Virenscanner“-Ära reicht nicht mehr aus.
Identity Security ist heute Session Security. Und Session Security ist ohne Token Governance nicht mehr sauber beherrschbar.
Wer moderne Cloud-Dienste nutzt, muss nicht nur Zugänge schützen, sondern auch die Artefakte, die dabei entstehen: Tokens, Zustimmungen, App-Berechtigungen und Sitzungen.
Device Code Phishing ist mehr als nur eine neue Variante von Phishing. Dafür ist das Thema zu strukturell. Die Angriffe als solche verändern sich: weg vom simplen Passwortklau, hin zur Manipulation legitimer Identitätsprozesse.
Das Passwort sitzt dabei immer öfter nur noch auf der Reservebank – mit Trikot, aber ohne Ballkontakt.
Wer seine Sicherheitsstrategie heute weiterentwickeln will, sollte deshalb drei Dinge tun:
unnötige Auth-Flows schließen
OAuth- und Consent-Governance professionalisieren
und Token-Visibility aufbauen.
So entscheidet sich künftig häufiger, ob ein Phishing-Versuch nur nervig war – oder ob plötzlich jemand mit gültigem Token in deiner Cloud wohnt.