Device-Code-Phishing: Wenn der echte Microsoft-Login zur Falle wird

Was ist ein Device-Code-Login?

Microsoft nutzt, ähnlich wie andere Software-as-a-Service-Anbieter wie zum Beispiel Google, einen vereinfachten Login für Geräte ohne Tastatur. Das Ziel ist, dass Du Dich auf Deinem Fernseher ganz einfach mit Deinem Konto anmelden kannst.

Hierfür wird ein neunstelliger Code generiert, den Du innerhalb der nächsten 15 Minuten auf microsoft.com/devicelogin eingeben musst. Im Hintergrund wurde die Anfrage bereits vorab autorisiert: Microsoft weiß also schon, dass sich jemand mit diesem Code einloggen möchte, und sobald Du den Code eingibst, weiß Microsoft auch, wer das ist. Dabei generiert Microsoft verschiedene technische Tokens, mit denen sich in diesem Beispiel Dein Fernseher gegenüber Microsoft authentifizieren kann.

Wie läuft ein Device-Code-Phishing-Angriff ab?

Beim Device-Code-Phishing beginnt der Angriffsablauf häufig mit einer Phishing-Mail. Oft bekommst Du eine Einladung zu einem Office-Dokument, Word oder PowerPoint sind hier sehr beliebt. Wie so ein Phishing-Versuch grundsätzlich aufgebaut ist, zeigen wir am Beispiel einer echten Phishing-Mail in unserem Artikel Was ist ein Sicherheitsvorfall?.

Wie ausgereift und aktuell solche Angriffe inzwischen sind, zeigt eine Analyse des Sicherheitsanbieters Huntress vom Juni 2026. Die Forscher deckten dabei ein komplettes Phishing-as-a-Service-Kit namens Kali365 (auch als Octopi365 oder Freedom365 bekannt) auf, das exakt die hier beschriebene Masche nutzt: gefälschte Seiten für OneDrive, SharePoint, Teams und weitere Microsoft-Dienste, die zum echten Device-Code-Login führen. Die US-Bundespolizei FBI warnte im Mai 2026 in einer eigenen Mitteilung vor diesem Kit. Besonders alarmierend: Laut Huntress kann der Zugriff des Angreifers bestehen bleiben, selbst wenn das Opfer im Nachhinein sein Passwort ändert oder MFA nutzt, in einem dokumentierten Fall gelang die Übernahme innerhalb von nur 42 Sekunden nach Eingabe des Codes. Mehr Details liefert der Huntress-Blogartikel.

In diesem Beispiel versucht der Angreifer, Dich unter dem Vorwand eines PDF-Downloads zum Klick auf einen Link zu bewegen. Dieser führt allerdings nicht auf ein PDF, sondern auf die Domain ***.workers.dev.

Workers.dev: Wie ein legitimer Service für Angriffe missbraucht wird

Selbstverständlich können auch andere Webseiten oder SaaS-Dienste missbraucht werden. Stand Juli 2026 wird insbesondere Workers.dev hierfür genutzt.

Workers.dev ist ein Service von Cloudflare für Serverless-Anwendungen. Er wird insbesondere von Entwicklern geschätzt, zum Beispiel für Testzwecke. Das Problem: Auch Angreifer können hier einfach und kostenfrei ihre Phishing-Seiten hosten.

In dieser Angriffswelle wird Workers.dev genutzt, um das Web-Frontend zu hosten.

In diesem Beispiel ist der Köder eine angebliche Rechnung Invoice&BL-2026.pdf. Um sie herunterzuladen, muss auf "View Document" geklickt werden. Statt einer Rechnung werden wir stattdessen zu microsoft.com/devicelogin weitergeleitet.

microsoft.com/devicelogin: Phishing mit echtem Login

Wir sollen auf dieser Seite den auf Workers.dev angezeigten Code eingeben. Wichtig zu verstehen bei diesem Angriff ist, dass der eigentliche Login auf einer legitimen Webseite stattfindet. Genauer gesagt findet gar kein Login statt, denn der Angriff funktioniert über eine bereits bestehende Sitzung. Sind wir also schon in unserem Microsoft-Konto angemeldet, reicht es, den angezeigten Code einzutragen. Sobald auf "Weiter" geklickt wird, erhält der Angreifer vollen Zugriff auf unser M365-Konto. Es erfolgt keine erneute Abfrage von Passwort oder MFA. Spätestens jetzt handelt es sich um einen Notfall, denn diese Token werden häufig aus dem Ausland verwendet.

Angreifer beginnen in der Regel damit, neue Geräte in den Organisationskontext einzubinden, um sich so weiter auszubreiten und Persistenz zu schaffen. Auch das Hinterlegen neuer Multi-Faktor-Geräte ist ein übliches Vorgehen.

Wie kann ich mich vor Device-Code-Phishing schützen?

Das Lesen dieses Artikels ist ein guter Anfang. Wer die Methode kennt, achtet eher auf verdächtige Anzeichen.

Technisch lässt sich der Authentifizierungs-Flow "Device Code Flow" per Conditional Access in Microsoft Entra einschränken. Details dazu findest Du im Microsoft-Support-Artikel.

Über Conditional Access lässt sich zum Beispiel definieren, wer diese Login-Art überhaupt für welche Anwendungen nutzen darf. Wenn ich mich in einem modernen Dienstwagen von Mercedes anmelden möchte, erfolgt der Login bei Microsoft über eine Mercedes-Connect-App. Hier sollte ich entweder festlegen, dass alle das dürfen, oder aber nur Mitarbeitende, die auch tatsächlich einen Dienstwagen von Mercedes haben. Das Gleiche gilt für die Azure Cloud Shell: Auch hier erfolgt der Login via Device Code, allerdings brauche ich diese Funktion vielleicht nur selten und kann sie entweder vorher explizit für mich freigeben lassen oder festlegen, dass nur Admins sie nutzen dürfen.

Was ich KMU konkret empfehlen würde: Workers.dev komplett blockieren

Für die meisten kleinen und mittleren Unternehmen sehe ich kaum einen legitimen geschäftlichen Grund, dass Mitarbeitende auf *.workers.dev-Domains zugreifen müssen. Der Dienst wird fast ausschließlich von Entwicklern genutzt, etwa für Tests und Prototypen. Deshalb würde ich KMU ohne eigene Entwicklungsabteilung dazu raten, den Zugriff auf Workers.dev auf der Firewall oder im DNS-Filter komplett zu sperren. Das lässt sich in den meisten modernen Firewalls oder Web-Filtern mit einer einzigen Regel umsetzen, und Dein IT-Dienstleister oder Systemhaus kann Dir dabei helfen.

Wichtig zu wissen: Das ist kein vollständiger Schutz, sondern eine pragmatische Reduzierung der Angriffsfläche. Angreifer können jederzeit auf eine andere kostenlose Serverless-Plattform ausweichen. Die eigentlich wirksame Maßnahme bleibt, den Device-Code-Flow selbst über Conditional Access einzuschränken, wie weiter oben beschrieben. Das Blockieren von Workers.dev ist eine sinnvolle, schnell umsetzbare Zusatzmaßnahme, aber kein Ersatz dafür.

Was tun, wenn der Angriff bereits erfolgreich war?

War die Anmeldung bereits erfolgreich, reicht es nicht, nur das Passwort zu ändern, wie Du oben gelesen hast, bleibt der Zugriff des Angreifers davon oft unberührt. Jetzt zählen zwei Dinge: Den Angreifer schnellstmöglich aus dem Konto und der Umgebung werfen, und herausfinden, was er in der Zwischenzeit getan hat, etwa ob neue Geräte oder MFA-Methoden hinterlegt wurden, ob sich der Angreifer bereits weiter ausgebreitet hat oder ob Daten abgeflossen sind. Genau dabei unterstützen wir im Rahmen der Incident Response. Wir dämmen den Zugriff ein, entziehen dem Angreifer die aktiven Sitzungen und Tokens, und analysieren, welche Spuren er hinterlassen hat.

Bist Du akut betroffen, erreichst Du uns über den roten Notfall-Button oben rechts.

Wie erkenne ich einen Device-Code-Phishing-Angriff?

Die Methode des Device-Codes wird bei Microsoft in den Anmeldeprotokollen als AuthenticationProtocol angezeigt.

Wenn ich Microsoft Sentinel als zentrale Logging-Instanz nutze, kann ich mit einer Abfrage wie dieser sehen, wer wann und wo sich per Device-Code angemeldet hat, um zum Beispiel im Anschluss meine Conditional-Access-Regeln auf die individuellen Arbeitsweisen im Betrieb einzustellen, ohne jemanden bei der Arbeit zu behindern.

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize Anzahl = count() by Datum = bin(TimeGenerated, 1d), AppDisplayName, UserDisplayName, UserPrincipalName

Falls Du unsicher bist, wie Du solche Alarme und Anmeldeprotokolle für Dein Unternehmen bewertest, unterstützen wir Dich mit unserer Log- und XDR-Analyse.