Datum: 

Device Code Phishing: Wie Konten ohne Passwortdiebstahl kompromittiert werden

Für die IT-Sicherheit sind technische Schutzmaßnahmen häufig nur in Kombination mit der Sensibilisierung der Mitarbeiterinnen und Mitarbeiter wirksam. Kaum ein Angriffsszenario zeigt dieses Zusammenspiel so deutlich wie Phishing.

Etablierte Mechanismen wie Multi-Faktor-Authentifizierung (MFA) haben klassische Phishing-Ansätze zum Diebstahl von Zugangsdaten deutlich erschwert. Moderne Angriffstechniken setzen jedoch nicht mehr zwingend nur auf den Diebstahl von Zugangsdaten, sondern nutzen legitime Authentifizierungsprozesse, um Zugriff auf Benutzerkonten zu erlangen.

Parallel dazu entwickeln sich Phishing-Kampagnen zunehmend weiter. Mittels Automatisierung durch Phishing-Frameworks sowie dem Einsatz von künstlicher Intelligenz (KI) können Angriffe heute mit deutlich geringerem technischem Aufwand durchgeführt werden. Zusammen mit dem etablierten Markt für sogenannte Phishing-as-a-Service-Angebote sinkt damit auch die Einstiegshürde für Angreifer.

Ein besonders anschauliches Beispiel hierfür ist das Device-Code-Phishing, bei dem Angreifer die legitime Authentifizierungsmethode Device-Code-Flow von modernen Authentifizierungsdiensten wie Microsoft Entra ID1 im Microsoft-Cloud-Umfeld ausnutzen.

Grundlegender Ablauf des Device-Code-Flows

Der sogenannte Device-Code-Flow ist eine Authentifizierungsmethode, die ursprünglich für Geräte entwickelt wurde, die selbst keine Möglichkeit bieten, eine Browser-basierte Anmeldung durchzuführen – beispielsweise Konferenzsysteme, Smart-TVs oder IoT-Geräte. Um die Ausnutzung des Device-Code-Flows als Angriffstechnik besser verstehen zu können, lohnt sich zunächst ein Blick auf dessen regulären Workflow anhand eines alltäglichen Beispiels (Abbildung 1): 

Herr Meier möchte auf seinem Smart-TV die fiktive Streaming-App „Fuchs Film“ nutzen. Hierfür muss er sein Gerät zunächst verifizieren, damit dieses die „Fuchs Film“ App nutzen darf (1). Zu diesem Zweck wird beim Start der Anwendung im Hintergrund ein Authentifizierungsprozess (Device-Code-Flow) angestoßen. Dabei wird eine Gerätesitzung initialisiert und ein sogenannter User-Code sowie ein dazugehöriger Device-Code erzeugt. Der Device-Code verbleibt auf dem Gerät und wird im Hintergrund zur Zuordnung der Sitzung verwendet, während der User-Code für die Eingabe durch den Benutzer bestimmt ist und auf dem TV angezeigt wird. Damit Herr Meier weiß, wo er sich anmelden muss, wird zusätzlich ein Link zur Anmeldewebseite bereitgestellt, der optional auch mithilfe eines QR-Codes geöffnet werden kann (2). Für die Anmeldung scannt Herr Meier den angezeigten QR-Code mit seinem Smartphone und wird auf die entsprechende Anmeldeseite weitergeleitet. Hier gibt er den zuvor dargestellten sechsstelligen User-Code ein (3). Anschließend authentifiziert er sich sowohl mit seinen gewohnten Zugangsdaten (Benutzername und Passwort) (4) als auch mit dem zweiten Faktor im Rahmen der Multi-Faktor-Authentifizierung (5). Nach erfolgreicher Anmeldung wird die zuvor gestartete Gerätesitzung bestätigt und das Gerät erhält Zugriff auf den Dienst (Fuchs Film). Herr Meier kann nun die Filme auf seinem TV ansehen, ohne eine erneute Anmeldung durchführen zu müssen (6).

Abbildung 1: Regulärer Authentifizierung über die Device-Code-Flow Methode
Zum Vergrößern bitte anklicken

Genau dieser legitime Authentifizierungsprozess bildet jedoch die Grundlage für einen zunehmend beobachteten Missbrauch: das sogenannte Device-Code-Phishing.

Dabei nutzen Angreifer den gezeigten Ablauf gezielt aus, um Benutzer zur Freigabe einer von ihnen kontrollierten Sitzung zu bewegen. Besonders im Umfeld von Microsoft Entra ID wird diese Technik aktuell vermehrt in Phishing-Kampagnen beobachtet.

Ablauf eines Device-Code-Phishing-Angriffs in Microsoft Entra ID

Ein typisches Angriffsszenario (grafisch dargestellt in der Abbildung 2) beginnt häufig mit einer scheinbar harmlosen E-Mail. Beispielsweise erhält ein Mitarbeiter aus der Finanzabteilung eine Nachricht, die angeblich vom IT-Support oder einem Partnerunternehmen stammt, mit der Bitte, ein Dokument zu überprüfen oder eine kurzfristige Verifikation der Microsoft-365-Sitzung durchzuführen. Häufig nutzen Angreifer hierfür bereits kompromittierte Konten, um mithilfe der bestehenden Vertrauensverhältnisse die Glaubwürdigkeit der Nachricht zu erhöhen.

Die Nachricht enthält einen Link, der zu einer vom Angreifer kontrollierten Phishing-Seite führt. Wird dieser geöffnet, initiiert der Angreifer im Hintergrund einen Device-Code-Flow innerhalb von Microsoft Entra ID. Dabei wird eine Authentifizierungssitzung für ein von ihm kontrolliertes Gerät erzeugt. Entra ID stellt in diesem Schritt die zwei zentralen Elemente zur Verfügung, die bereits zuvor am Beispiel von Herrn Meier eingeführt wurden: einen Device Code zur Zuordnung der Sitzung sowie einen User-Code, der später durch das Opfer eingegeben werden muss (1).

Dieser User-Code wird dem Opfer auf der Phishing-Seite angezeigt, verbunden mit der Aufforderung, sich über Microsoft Entra ID anzumelden und den Code zu bestätigen (2). Ein auf der Phishing-Seite enthaltener Link führt dann direkt zur offiziellen Microsoft-Anmeldeseite zur Eingabe des Device-Codes (3).

Im nächsten Schritt authentifiziert sich das Opfer über die echte Microsoft-Anmeldeseite. Dabei kommen die üblichen Mechanismen zum Einsatz, einschließlich Multi-Faktor-Authentifizierung (4+5). Nach erfolgreicher Anmeldung validiert Microsoft Entra ID den zuvor eingegebenen User-Code und ordnet die Authentifizierung der vom Angreifer initiierten Authentifizierungssitzung zu. Nach der Zustimmung des Benutzers (6), kann der Angreifer sich anschließend erfolgreich authentifizieren (7).

Für das Opfer wirkt der Vorgang vollständig legitim: Die Anmeldung erfolgt tatsächlich über Microsoft, das Multi-Faktor-Verfahren wird korrekt durchgeführt und es treten keine offensichtlichen Auffälligkeiten auf.

Der entscheidende Unterschied besteht darin, dass der Benutzer nicht seine eigene Sitzung bestätigt, sondern stattdessen die zuvor vom Angreifer initiierte Authentifizierungssitzung autorisiert.

Abbildung 2: Darstellung des Angriffsverlauf zur Ausnutzung des Device-Code-Flows
Zum Vergrößern bitte anklicken

Was macht diesen Angriff gefährlich?

Die wesentliche Gefahr, die von Device-Code-Phishing-Angriffen ausgeht, liegt vor allem darin, dass keine Zugangsdaten im klassischen Sinne kompromittiert werden. Der Benutzer gibt weder sein Passwort noch einen MFA-Code an den Angreifer weiter. Stattdessen autorisiert er im Rahmen eines legitimen Microsoft-Anmeldeprozesses eine Sitzung, die vom Angreifer initiiert wurde.

Für die Erkennung ist dieser Unterschied entscheidend: Aus Sicht von Microsoft Entra ID handelt es sich um eine erfolgreiche und gültige Anmeldung. 

Die eigentliche Gefahr entsteht dadurch, dass diese erfolgreiche Authentifizierung zur Ausstellung sogenannter Tokens führt, die den weiteren Zugriff auf Cloud-Ressourcen ermöglichen.

Token im Microsoft-Cloud-Kontext verstehen

Nach einer erfolgreichen Anmeldung stellt Microsoft Entra ID in der Regel zwei Arten von Tokens aus – einen Access-Token und einen Refresh-Token.

Der Access-Token dient dem unmittelbaren Zugriff auf den autorisierten Cloud-Dienst. Durch das Mitsenden des Access-Token bei Anfragen an den Dienst können die Daten im Kontext des Benutzers oder des Dienstes abgerufen werden. Wird bspw. Microsoft Office autorisiert, kann ein Angreifer auf Dateien, E-Mails und Teams-Daten des Benutzers zugreifen. Aufgrund der Sensibilität der hierüber erreichbaren Daten begrenzt Microsoft die Gültigkeit von Access-Tokens typischerweise auf etwa 60 bis 90 Minuten.

Der Refresh-Token dient dazu, nach Ablauf des Access-Token automatisch neue Tokens anzufordern, ohne dass der Benutzer erneut interagieren muss. Dadurch kann eine authentifizierte Sitzung über einen längeren Zeitraum aufrechterhalten werden. In der Praxis bedeutet dies, dass ein Angreifer nach erfolgreichem Device Code Phishing nicht nur einen einmaligen Zugriff erhält, sondern über gültige Tokens weiterhin auf Microsoft-Cloud-Dienste zugreifen kann, solange die Sitzung aktiv bleibt.

Was kann ich dagegen unternehmen bzw. wie kann ich mich schützen?

Bei Maßnahmen gegen Device Code Phishing gilt es zwischen reaktiven und präventiven Handlungen zu unterscheiden.

Reaktive Maßnahmen

Wurde bereits ein erfolgreicher Angriff festgestellt, sollten betroffene Konten umgehend gesperrt sowie aktive Sitzungen über Microsoft Entra ID zurückgesetzt werden. Dadurch werden bestehende Refresh-Tokens ungültig gemacht, sodass ein Angreifer keine neuen Access-Tokens mehr anfordern kann. Bereits ausgestellte Access-Tokens bleiben jedoch meist bis zu ihrem Ablauf weiterhin gültig. Daher sollte im Anschluss eine detaillierte Untersuchung der Cloud-Umgebung durchgeführt werden, um mögliche Zugriffe auf Cloud-Ressourcen sowie die Reichweite der kompromittierten Identität nachvollziehen zu können. Hierbei kann bei Bedarf auch unser Incident Response Team unterstützen.

Präventive Maßnahmen

Deutlich wirksamer als eine reine Reaktion auf Sicherheitsvorfälle ist jedoch die präventive Absicherung der Umgebung. Dabei gilt es, wie eingangs erwähnt, eine Kombination aus technischen und organisatorischen Maßnahmen umzusetzen. 

Zu den technischen Maßnahmen zählt insbesondere die Einschränkung von Device-Code-Authentifizierungen über Conditional-Access-Policies in Microsoft Entra ID. Ergänzend sollten weitere Härtungsmaßnahmen nach etablierten Standards, wie den Benchmarks des Center for Internet Security (CIS), umgesetzt werden, um die zugrundeliegende Angriffsfläche deutlich zu reduzieren. Darüber hinaus kann ein kontinuierliches Monitoring der Authentifizierungsereignisse dazu beitragen, Auffälligkeiten frühzeitig zu erkennen und das Detektionsfenster zu verkleinern, um ein rechtzeitiges Eingreifen zu ermöglichen.

Neben den technischen Maßnahmen bleibt die Sensibilisierung der Mitarbeitenden ein zentraler Bestandteil der Abwehrstrategie. Unabhängig davon, ob es sich um Device-Code-, MFA- oder andere Phishing-Varianten handelt, bleibt der entscheidende Faktor in vielen Fällen der Mensch.

Bei der strategischen Planung und Umsetzung geeigneter Schutzmaßnahmen in Microsoft-Cloud-Umgebungen kann unser Technical Security Consulting Team unterstützen.

Im Endeffekt zeigt Device-Code-Phishing, dass nicht nur Zugangsdaten, sondern auch legitime Authentifizierungsprozesse selbst ein ernstzunehmendes Risiko darstellen können.





1 Microsoft Entra ID (früher Azure Active Directory oder Azure AD) ist der cloudbasierte Identitäts- und Zugriffsverwaltungsdienst (IAM) von Microsoft. Er fungiert als zentrales Verzeichnis, über das Benutzerkonten, Geräte und Zugriffsrechte für Microsoft-Dienste (wie Microsoft 365, Azure und Dynamics 365) sowie andere Cloud-Anwendungen sicher verwaltet werden.

Dieser Artikel wurde verfasst von