Device-Code Phishing: Wie Angreifer legitime Dienste missbrauchen, um MFA zu umgehen

Vertrauenswürdige Plattformen dienen als Liefer-Infrastruktur für eine Technik, die klassische Zwei-Faktor-Authentifizierung aushebelt

Die meisten Phishing-Abwehrmaßnahmen beruhen auf einer einfachen Annahme: Der Angreifer braucht Ihr Passwort, und selbst wenn er es bekommt, stoppt ihn in der Regel Ihr zweiter Faktor, etwa eine Authenticator-App, eine Push-Benachrichtigung oder ein Hardware-Key. Eine Technik, die derzeit weit verbreitet ist, bekannt als Device-Code Phishing, hebelt diese Annahme vollständig aus. Sie stiehlt weder ein Passwort noch fängt sie einen Einmalcode ab. Stattdessen bringt sie Sie dazu, eine vollständig angemeldete Session herauszugeben, bei der die MFA bereits erfüllt ist, ohne dass Ihnen je bewusst wird, was Sie autorisiert haben.

Eine Funktion für Smart-TVs, umfunktioniert zum Diebstahl

Die Technik missbraucht einen echten, legitimen Teil des OAuth-2.0-Standards, den sogenannten Device Authorization Grant. Er löst ein alltägliches Problem: Wie meldet man sich auf einem Smart-TV, einer Spielkonsole oder einem Command-Line-Tool bei seinem Microsoft- oder Google-Konto an, wenn es keine bequeme Möglichkeit gibt, ein Passwort einzugeben? Das Gerät zeigt einen kurzen Code und eine URL an. Sie öffnen diese URL auf Ihrem Smartphone oder Laptop, geben den Code ein, melden sich mit Passwort und MFA an, und der Fernseher oder das CLI-Tool auf der anderen Seite erhält Zugriff auf Ihr Konto.

Das ist eine clevere, nützliche Infrastruktur. Genau betrachtet ist es aber auch eine Maschine, die Autorisierung von einem Bildschirm, dem Sie vertrauen, auf ein Gerät überträgt, das Sie nicht sehen können.

So funktioniert der Angriff

Dieser Teil sollte das Security-Team beunruhigen: Der Angreifer muss nichts bauen, das einer gefälschten Login-Seite ähnelt. Er nutzt die echte Login-Seite von Microsoft unter der echten Adresse login.microsoftonline.com, mit gültigem Zertifikat und ganz ohne Spoofing.

Der Angriff läuft in fünf Schritten ab:

1. Das Tool des Angreifers fordert bei Microsoft einen Device Code an. Das ist ein routinemäßiger, nicht authentifizierter API-Aufruf. Microsoft kann in diesem Moment nicht erkennen, ob die Anfrage von einem Smart-TV oder vom Laptop eines Kriminellen stammt. Microsoft gibt einen kurzen alphanumerischen Code zurück (etwa GMY2HJJV8) und startet einen Countdown, in der Regel 15 Minuten.

2. Der Angreifer schickt dem Opfer einen Köder. In beobachteten Kampagnen war das eine E-Mail zu einem „geteilten Dokument“: eine gefälschte SharePoint-Benachrichtigung, eine gefälschte DocuSign-Anfrage, eine Kalendereinladung zu einem Teams-Meeting oder irgendetwas anderes, das plausibel mit „Bestätigen Sie Ihren Zugriff, um fortzufahren“ endet.

‍

3. Das Opfer durchläuft eine Kette vertrauenswürdig wirkender Weiterleitungen. Statt direkt auf eine verdächtige Domain zu verlinken, führt der Köder oft über legitime SaaS-Plattformen, bevor er auf der eigentlichen Seite des Angreifers landet: eine gefälschte SharePoint-Dateikarte als erster Anhang, ein Formular auf Smartsheet, eine auf Amazon S3 abgelegte Datei. Keine dieser Plattformen ist kompromittiert oder beteiligt. Der Angreifer ist einfach ein gewöhnlicher Kunde, der die normalen Self-Service-Tools jedes Dienstes genau so nutzt, wie sie gedacht sind. Jede Station wird gewählt, weil sie bei E-Mail-Filtern und URL-Scannern in Unternehmen einen sauberen Ruf hat, denn diese vertrauen bekannten Plattformen in der Regel mehr als frisch registrierten Domains. Wenn das Opfer schließlich eine Domain erreicht, die tatsächlich verdächtig aussieht, hat es die meisten automatischen Filter bereits passiert.

‍

4. Die Landing Page zeigt den Device Code des Angreifers an und fordert das Opfer auf, ihn auf der echten Microsoft-Seite einzugeben. Das ist der Kern der Täuschung. Das Opfer soll kein Passwort in eine gefälschte Seite eintippen. Es soll einen Code kopieren und auf login.microsoftonline.com einfügen, einer Domain, die der Browser zu Recht als sicher anzeigt, weil sie es ist.

‍

5. Das Opfer meldet sich ganz normal an. Passwort, MFA-Abfrage, alles funktioniert genau so, wie es soll. Die Microsoft-Server sehen einen legitimen, vollständig authentifizierten Login. Das Token aus diesem Login geht jedoch an die Session, die der Angreifer in Schritt eins geöffnet hat, und nicht an das Gerät des Opfers. Das Opfer sieht vielleicht eine allgemeine Meldung wie „Zugriff gewährt“ oder gar nichts. Der Angreifer besitzt nun eine aktive, authentifizierte Session für das Konto des Opfers.

Warum das auch „phishingresistente“ MFA aushebelt

Die meisten MFA-Methoden, also Push-Benachrichtigungen, Codes aus Authenticator-Apps und in manchen Konfigurationen sogar Hardware-Security-Keys, sollen das Login-Formular schützen. Sie prüfen, ob die Person, die das Passwort eingibt, auch einen registrierten zweiten Faktor besitzt. Device-Code Phishing berührt das Login-Formular gar nicht. Die MFA-Abfrage des Opfers ist echt, und das Opfer erfüllt sie korrekt, auf der echten Seite, mit seinem echten Gerät. Die Schwachstelle liegt nicht in der Authentifizierung. Sie liegt darin, dass ein Gerät zu autorisieren und sich selbst zu autorisieren aus Sicht des Opfers genau gleich aussehen.

Genau deshalb beobachtet das Threat-Intelligence-Team von Microsoft diese Technik als aktive Bedrohung (öffentlich in Verbindung gebracht mit dem Akteurscluster Storm-2372). Ausgeliefert wird sie typischerweise über genau die oben beschriebenen Köder rund um geteilte Dokumente und Meeting-Einladungen.

So sieht das in der Praxis aus

Ein kürzlich beobachtetes Beispiel aus der Praxis folgte genau diesem Muster: eine E-Mail, die eine routinemäßige interne Dokumentfreigabe vortäuschte, mit einem PDF-Anhang im Stil einer SharePoint-Dateikarte. Der Button „Dokument öffnen“ führte nicht zu einem Dokument, sondern über zwei separate Stationen zur Reputationswäsche: zuerst ein Formular auf Smartsheet, dann eine auf Amazon S3 abgelegte Datei. Am Ende stand eine Seite mit einem Microsoft Device Code und einem 15-Minuten-Countdown, die Besucher aufforderte, die Verifizierung auf dem echten Microsoft-Login-Portal abzuschließen.

So wehren Sie sich

Weil die Technik klassische Abwehrmaßnahmen gegen Credential Phishing umgeht, sehen auch die Gegenmaßnahmen anders aus:

• Awareness muss konkret sein. „Geben Sie Ihr Passwort nicht auf verdächtigen Seiten ein“ deckt diesen Angriff nicht ab, denn hier wird kein Passwort auf einer verdächtigen Seite eingegeben. Die entscheidende Botschaft ist enger gefasst: Geben Sie niemals einen Device Code oder Bestätigungscode ein, weil eine externe E-Mail, eine Chatnachricht oder ein Link Sie dazu auffordert. Eine legitime Geräteanmeldung starten Sie immer selbst, auf dem Gerät, das Sie autorisieren wollen. Sie ist niemals etwas, das eine Nachricht Sie in ihrem Auftrag abschließen lässt.
• Schränken Sie den Flow an der Quelle ein, wenn möglich. Die meisten Organisationen nutzen den Device Authorization Grant nicht für alltägliche Logins. Mit Conditional-Access-Richtlinien in Microsoft Entra ID lässt sich dieser Flow für Nutzer, die ihn nicht brauchen, einschränken oder ganz deaktivieren. So wird die Technik auf Protokollebene unterbunden, statt sich darauf zu verlassen, dass jede Person den Köder erkennt.
• Achten Sie auf auffällige Token-Ausstellungen, nicht nur auf auffällige Logins. Weil der „Login“ selbst vollkommen legitim ist, muss sich die Erkennung auf das konzentrieren, was danach passiert. Anmeldungen von unbekannten Geräten oder Standorten, die Tokens über den Device Code Flow erhalten, sind ein stärkeres Signal als fehlgeschlagene Logins oder Password-Spray-Muster.
• Begegnen Sie Weiterleitungen über vertrauenswürdige Plattformen mit Skepsis, nicht mit Beruhigung. Ein Link, der über eine bekannte SaaS- oder Cloud-Storage-Domain läuft, ist nicht automatisch sicherer. Immer häufiger ist er ein Zeichen dafür, dass genau das Ziel weiter hinten in der Kette Vorsicht verdient.

Die unbequeme Lehre aus Device-Code Phishing: Die schwächste Stelle in einem Login-Ablauf ist nicht immer das Passwortfeld. Manchmal ist es eine viel ältere Annahme, nämlich dass eine Anfrage, die von der echten Login-Seite kommt, auch eine Anfrage sein muss, die Sie wirklich stellen wollten.

‍