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.
Device-Code-Phishing per Conditional Access blockieren
Conditional Access ist ein Feature von Microsoft Entra ID. Dieses ist ab der Lizenz "P1" enthalten. Ohne zusätzliche Kosten ist diese Lizenz beispielsweise in den Lizenzpaketen Business Premium, Microsoft 365 A3 sowie E3 enthalten. In den Paketen A5, E5 und E7 steht sogar das erweiterte Feature-Paket der Lizenz Entra ID "P2" zur Verfügung. In den Paketen Business Basic und Business Standard ist dagegen nur die kostenfreie Version von Entra ID enthalten, hier müsste die Entra-P1-Lizenz zusätzlich lizenziert werden. Stand 07.2026 liegt diese bei 6,10 € pro Nutzer pro Monat. Bei Interesse kann der aktuelle Preis auf der Seite von Microsoft direkt geprüft werden. Hier lohnt es sich ebenfalls zu prüfen, ob das nächsthöhere Paket nicht gleich teuer bei mehr Leistung ist. Beispielsweise liegt der Preisunterschied von Business Standard zu Business Premium (Stand 07.2026) bei 6,93 €. Für einen Aufpreis von 83 Cent bekommst Du zusätzlich zum Beispiel eine erweiterte Power-Automate-Version, Windows Hello for Business als sicherere Anmeldemethode und Intune zur Geräteverwaltung. Teilweise ist es über Systemhäuser und Microsoft-Partner möglich, günstiger als zum Listenpreis an diese Lizenzen zu kommen, daher lohnt sich die Anfrage beim IT-Dienstleister Deines Vertrauens.
Technisch lässt sich der Authentifizierungs-Flow "Device Code Flow" per Conditional Access in Microsoft Entra einschränken.
Im ersten Schritt konfigurieren wir die Zielressourcen, für die unsere neue Conditional-Access-Policy gelten soll. In unserem Beispiel nutzen wir All Resources. Hier können auch Ausnahmen für bestimmte Anwendungen gesetzt werden, etwa wenn Meetingraum-Systeme einen Device-Code-Login verwenden, oder wenn die Mercedes-Firmenfahrzeuge den Login via Device Code nutzen.
Am besten lässt sich vorab mit der KQL-Abfrage am Ende dieses Blogposts prüfen, wo im Unternehmen Device Codes benutzt werden.
Im nächsten Schritt konfigurieren wir die Bedingung, unter der unsere Conditional-Access-Regel greifen soll. Wir wollen Device-Code-Logins blockieren, dafür klicken wir auf Authentication Flows und setzen den Haken bei Device Code Flow.
Wir haben nun definiert, dass unsere Conditional-Access-Policy für alle Ressourcen mit diesem Authentication Flow greifen soll. Damit wir uns selbst nicht aussperren, sollten wir in solchen Policies immer sogenannte "Break-the-Glass"-User ausnehmen. Im besten Fall haben wir einen oder mehrere globale Administratoren, die wir besonders überwachen, aber nicht in solchen Konfigurationen verwenden. Damit können wir bei einer Fehlkonfiguration weiterhin auf unsere Azure-Konfiguration zugreifen. Wenn ein SOC vorhanden ist oder Sentinel verwendet wird, sollte jeder Login und jede Verwendung dieser Break-the-Glass-User einen Alarm auslösen.
Wir haben nun definiert, welche Bedingungen von unserer neuen Conditional-Access-Policy kontrolliert werden sollen und welche User und Gruppen davon ausgeschlossen werden sollen. Wir müssen nun noch konfigurieren, was genau mit diesen Anmeldungen passieren soll. Hier sollten wir Block Access wählen. Der Angriff über Device-Code-Phishing umgeht die Multi-Faktor-Authentifizierung (MFA), daher ist das Blockieren hier die einzige Option.
Solltest Du mehr Details zum Thema Conditional Access und Device Authentication benötigen, kann ich diesen Microsoft-Support-Artikel empfehlen.
Solltest Du Dir die Konfiguration nicht zutrauen oder Unterstützung benötigen, kann Dir Dein Systemhaus oder IT-Partner des Vertrauens in der Regel helfen.
Konkreter Workaround als Schutzmaßnahme: 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.