Ein Mitarbeiter öffnet eine E-Mail über eine freigegebene Datei oder eine überfällige Rechnung. Die Nachricht enthält einen Link zu microsoft.com/devicelogin, der offiziellen Microsoft-Seite, sowie einen kurzen Code zur Eingabe. Der Mitarbeiter gibt den Code ein, schließt die eigene Multi-Faktor-Authentifizierung ab und geht zur Tagesordnung über.
An diesem Vorgang wirkt nichts verdächtig, da nichts daran gefälscht ist. Jeder Schritt läuft über die Infrastruktur von Microsoft. Was der Mitarbeiter nicht weiß: Der Code stammt von einem Angreifer, und die Bestätigung gewährt diesem Zugriff auf eine aktive Sitzung, anstatt eine Datei freizugeben.
Was bei Phishing mit Gerätecodes ausgenutzt wird
Die OAuth 2.0-Geräteautorisierung gemäß RFC 8628 wurde für Geräte ohne Tastatur entwickelt: Smart-TVs, Konferenzsysteme oder Befehlszeilentools. Das Gerät zeigt einen Code an. Der Benutzer gibt diesen Code auf einem zweiten Gerät unter microsoft.com/devicelogin ein, um beide zu verknüpfen.
Das Design geht davon aus, dass die Person, die den Code anfordert, und die Person, die ihn bestätigt, identisch sind. Angreifer hebeln diese Annahme aus. Sie fordern den Code selbst an, senden ihn mit einem Vorwand an ein Ziel und warten ab.
Wenn das Ziel den Code eingibt und die eigene Multi-Faktor-Authentifizierung abschließt, landet das resultierende Sitzungstoken beim Angreifer und nicht beim Zielbenutzer.
Eine Kampagne, die sich über fünf Kontinente erstreckte
Mehr als 340 Microsoft 365-Organisationen in den USA, Kanada, Australien, Neuseeland und Deutschland waren betroffen. Forscher entdeckten die Kampagne erstmals am 19. Februar 2026 (The Hacker News, 25. März 2026). Später breitete sie sich auf Organisationen in Nord- und Südamerika, Europa, dem Nahen Osten, Asien und Ozeanien aus.
Am stärksten betroffen waren Organisationen aus den Bereichen Bauwesen, Gemeinnützigkeit, Immobilien, Fertigung, Finanzdienstleistungen, Gesundheitswesen, Recht und Behörden. Forscher führen den Ursprung der Methode auf eine Gruppe namens Storm-2372 zurück. Spätere Wellen stammten von anderen Akteuren, die kommerzielle Phishing-Kits nutzten, wodurch die Technik auch für Angreifer ohne tiefgreifende technische Kenntnisse zugänglich wurde.
Weiterführende Untersuchungen zu dieser Aktivität ergaben ein sechsstufiges Muster, von der Aufklärung bis zur Persistenz. Die Angreifer bestätigten zunächst, welche Konten gültig waren, und versendeten dann Phishing-E-Mails mit Vorwänden wie Rechnungen oder freigegebenen Dateien, teilweise mit generativer KI auf die Rolle des Ziels zugeschnitten. Der Gerätecode wurde erst in dem Moment generiert, als das Opfer klickte, sodass er lange genug gültig blieb, um zu handeln. Die Angreifer prüften wiederholt, ob die Anmeldung erfolgreich war.
Sobald sie Zugriff hatten, richteten sie versteckte Posteingangsregeln ein, registrierten neue Geräte und identifizierten hochwertige Profile innerhalb des Kontos: Finanzen, Geschäftsführung und Administratoren.
Warum die Multi-Faktor-Authentifizierung dies nicht verhindert
Die Multi-Faktor-Authentifizierung funktionierte bei dieser Kampagne genau wie vorgesehen. Das Opfer gab ein Passwort ein (falls erforderlich), bestätigte eine Aufforderung oder gab einen Einmalcode ein, und die Identität wurde bestätigt.
Die MFA versagte technisch nicht. Das Opfer bestätigte lediglich eine Sitzung, die nicht seine eigene war.
Dieser Unterschied ist entscheidend. Eine Sicherheitslücke kann gepatcht werden. Eine falsche Vertrauensannahme muss jedoch bei jedem einzelnen Mitarbeiter korrigiert werden.
Phishing mit Gerätecodes reiht sich in ein bekanntes Muster ein: Vishing-Anrufe, die MFA-Codes in Echtzeit abfingen, oder Überweisungen, die nach erfolgreicher MFA-Prüfung autorisiert wurden. In jedem Fall funktionierte die Technologie korrekt. Die Person, die die Aktion autorisierte, wusste nur nicht, was sie da eigentlich freigab.
Die Lücke in der Schulung
Die meisten Schulungen zum Sicherheitsbewusstsein lehren Mitarbeiter, gefälschte Anmeldeseiten zu erkennen: eine falsche Domain, ein fehlendes Schloss-Symbol, eine URL, die der echten fast gleicht. Phishing mit Gerätecodes weist keines dieser Anzeichen auf.
Die Domain ist echt. Die Seite ist echt.
Die eigentliche Frage ist, warum überhaupt ein Code per E-Mail eingeht. Das ist deutlich schwieriger zu trainieren als ein verdächtiger Link. Es verlangt von Mitarbeitenden, einen Prozess zu unterbrechen, der völlig normal aussieht – basierend auf einer Einschätzung der Absicht statt auf einem technischen Warnsignal. Schulungen, die sich auf Phishing-Indikatoren konzentrieren, greifen hier zu kurz. Verhaltensbasierte Trainings könnten jedoch helfen.
Was das für Sicherheitsteams bedeutet
Technische Kontrollen sind hilfreich. Richtlinien für bedingten Zugriff können den Gerätecode-Flow für Konten blockieren, die ihn nicht benötigen, und die Einschränkung der Geräteregistrierung begrenzt die Möglichkeiten eines Angreifers bei einer gestohlenen Sitzung. Doch keine dieser Kontrollen bringt Mitarbeitenden bei, das Muster zu erkennen, wenn es das nächste Mal dort auftaucht, wo diese Kontrollen nicht greifen.
Sicherheitsteams sollten diese Kontrollen mit Schulungen ergänzen, die Mitarbeitende dazu anhalten, jeden unaufgeforderten Code zu hinterfragen – nicht nur verdächtige Links. Den Flow zu blockieren und das Erkennungsvermögen zu schulen sind zwei verschiedene Aufgaben; ein Programm, das nur eine davon abdeckt, lässt die andere Lücke offen.
Das wirft eine Frage auf, über die man länger nachdenken sollte, statt sie vorschnell zu beantworten: Was wäre nötig, um Mitarbeitende auf einen Angriff vorzubereiten, der echte Infrastruktur nutzt, statt sie nur vorzutäuschen? Jede Simulation eines Ablaufs, der echte Authentifizierungssysteme berührt, müsste strikte Garantien bieten: keine Offenlegung echter Nutzerdaten und der sofortige Widerruf jeglicher Zugriffsrechte nach der Übung. Diese Balance zu finden – realistisch genug, um ein Bewusstsein zu schaffen, und sicher genug, um keine Risiken einzugehen – ist eine schwierigere Designaufgabe als bei einer typischen Phishing-Simulation. Genau hier liegt jedoch die nächste Herausforderung.
Eine Kontrolle, die einen Ablauf blockiert, kann umgangen werden. Ein Mitarbeiter, der das Muster erkennt, nicht.
Gerätecode-Phishing war bei 340 Organisationen nicht deshalb erfolgreich, weil die Multi-Faktor-Authentifizierung schwach war. Es war erfolgreich, weil es Mitarbeitende dazu brachte, einem Prozess zu vertrauen, der tatsächlich von Microsoft stammte und auch so aussah.
Das ist ein schwierigeres Problem als eine gefälschte Anmeldeseite, und es ist die nächste Hürde, die das Human Risk Management nehmen muss. Dies ist das dritte Muster, das wir beobachtet haben, bei dem die MFA genau das tut, wofür sie entwickelt wurde, und das Konto dennoch kompromittiert wird.
Die anderen: Vishing-Anrufe, bei denen MFA-Codes in Echtzeit abgefangen wurden, sowie eine Überweisung in Höhe von 60 Millionen Dollar, die genehmigt wurde, nachdem die MFA alle Prüfungen bestanden hatte.