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

Device-Code-Phishing ist einer dieser Angriffe, die auf den ersten Blick harmloser wirken, als sie sind. Das Opfer landet nicht auf einer plump gefälschten Passwortseite. Es wird nicht zwingend nach einem Passwort gefragt.

Genau das ist der Trick.

Der Angreifer startet im Hintergrund einen legitimen OAuth Device Authorization Flow. Das Opfer wird dazu gebracht, den dazugehörigen Code einzugeben und sich mit dem eigenen Microsoft-Konto zu authentifizieren. Wenn das klappt, erhält nicht das Opfer den Zugriff, sondern die vom Angreifer kontrollierte Session.

Diese Analyse basiert auf einem real beobachteten Fall. Alle Unternehmensnamen, Domains, Codes, Pfade und eindeutigen Werte wurden anonymisiert oder ersetzt. Die Original-E-Mail war nicht mehr aus der Mailbox abrufbar. Verfügbar waren Betreff, Absenderadresse, der enthaltene Link und Screenshots der Redirect- und Landingpage-Kette.

Executive Summary

Im beobachteten Fall begann der Angriff mit einer kurzen englischen E-Mail und einem Google-Redirect-Link. Der Betreff lautete:

Which of these Locations do you want this sent to?

Der sichtbare Kontext wirkte wie eine Zustell- oder Lieferentscheidung. Nach dem Klick führte die Kette über eine Google-Redirect-URL zu einer zwischengeschalteten Lieferseite und anschließend zu einer gefälschten OneDrive-Seite. Dort wurde ein Device Code angezeigt, den der Benutzer kopieren und bei Microsoft eingeben sollte.

Für Verteidiger ist entscheidend, wo die Spuren liegen: nicht nur in E-Mail-Logs, sondern vor allem in Entra ID Sign-in Logs.

Was Device-Code-Phishing ausnutzt

Der OAuth 2.0 Device Authorization Grant ist ein legitimer Standard für Geräte, auf denen normales Tippen schwierig ist. Ein Smart-TV, Drucker, Kiosk, IoT-Gerät oder eine CLI-Anwendung kann dem Benutzer einen Code zeigen und ihn bitten, diesen Code auf einer separaten Login-Seite einzugeben.

Vereinfacht sieht der legitime Ablauf so aus:

1. Ein Gerät oder eine App fordert einen Device Code an.
2. Die App zeigt dem Benutzer einen kurzen Code und eine Verifikationsadresse.
3. Der Benutzer öffnet die Verifikationsadresse auf einem anderen Gerät.
4. Der Benutzer meldet sich beim Identity Provider an und bestätigt den Code.
5. Die ursprüngliche App erhält Tokens und ist angemeldet.

Beim Phishing kontrolliert der Angreifer den ersten Schritt. Er startet die Device-Code-Anfrage selbst und zeigt dem Opfer den dazugehörigen Code auf einer gefälschten Landingpage. Das Opfer erledigt danach den echten Login bei Microsoft. Aus Sicht des Identity Providers hat der Benutzer den Code autorisiert. Aus Sicht des Angreifers ist genau das der Erfolg.

Das macht diese Technik so unangenehm:

• Die finale Anmeldung kann auf einer echten Microsoft-Domain stattfinden.
• MFA wird nicht umgangen, sondern vom Opfer erfolgreich abgeschlossen.
• Der Angreifer erhält OAuth-Tokens statt nur ein Passwort.
• Ein Passwortwechsel alleine reicht nicht.
• Viele klassische URL- oder Credential-Phishing-Erkennungen greifen zu spät, weil die kritische Interaktion bei Microsoft selbst passiert.

Fallstudie: Der beobachtete Angriffspfad

Die ursprüngliche Nachricht konnte nicht mehr vollständig abgerufen werden. Bekannt waren diese Elemente:

Feld	Anonymisierter Wert	Bewertung
Absender	low@attacker[.]com	Domain ersetzt; im Original kein vertrauenswürdiger Absender
Betreff	Which of these Locations do you want this sent to?	Lieferort-Köder
E-Mail-Body	Nicht mehr verfügbar	Einschränkung der Analyse
Enthaltener Link	siehe bereinigten URL-Auszug unten	Google-Redirect als erste sichtbare Tarnschicht

Die beobachtete Redirect-Kette wurde für den Post bereinigt:

https://www.google[.]com/url?q=http://adservice.google[.]com[.]ph/ddm/clk/424929466;226923624;r;u%3Dds%26amp;sv1%3D64195420186%26amp;sv2%3D3261659123742877%26amp;sv3%3D6702577448695742699%26amp;gclid%3DEAIaIQobChMIurHiwbHn8gIVBZ53Ch2TZAIsEAQYASABEgKAL_D_BwE;?//the****z[.]pk/s6/iykvfb0v/

Schritt	Beobachtung	Öffentlicher Beispielwert
1	E-Mail enthält Google-Redirect-URL	https://www.google[.]com/url?q=http://adservice.google[.]com[.]ph/ddm/clk/424929466;226923624;r;...;?//the****z[.]pk/s6/iykvfb0v/
2	Erste Redirect-Station	https://the****z[.]pk/s6/iykvfb0v/
3	Zwischenseite mit Liefer-/Paket-Optik	https://agen***********[.]ro/feed/976235/
4	Finale Device-Code-Landingpage	https://5dgbibkkttqu3ufaccfowqrfunzquj.app***********[.]sbs/2C4F594E-0918-41C6-A9F8-14D7C6CE4471-F1F4BE99-lBEkUprGOULLuLis3iN44X9j0eNPTKOoSNLn289oHdmygmU5TBOOYh-9BO89f1sO648MS8Vj3NFUOTCzRBtt7VtpDWrQe-hTxwQkOKlKbLHv
5	Benutzeraktion	Code kopieren, zu Microsoft wechseln, anmelden

Der Ablauf ist interessant, weil die erste sichtbare URL in der E-Mail auf Google zeigt. URL-Filter, die nur den Hostnamen des initialen Links prüfen, sehen google[.]com – the****z[.]pk ist tief im Redirect-Parameter verschachtelt und bleibt dabei verborgen. Die vollständige Kette über the****z[.]pk zur Zwischenseite und weiter zur Device-Code-Landingpage wird erst nach vollständiger Redirect-Auflösung sichtbar. Genau das ist die Stärke dieses Musters: Viele Filtersysteme prüfen den Link aus der E-Mail, nicht das, wohin er tatsächlich führt.

Die Zwischenseite nutzte eine Zustell-Optik und führte mit einem Button weiter. Zur Redirect-Kette eine Ergänzung: Der initiale E-Mail-Link führte nicht direkt auf diese Seite, sondern zunächst über den Google-Redirect und anschließend über the****z[.]pk/s6/iykvfb0v/. Erst nach diesem zweiten Zwischenschritt landete der Browser hier. Diese mehrstufige Kette hat zwei Aufgaben: Sie bestätigt dem Opfer scheinbar den Kontext des Betreffs, und sie macht das eigentliche Endziel für URL-Scanner schwerer erkennbar – jeder Redirect-Schritt entfernt den finalen Host weiter vom ursprünglichen Link in der E-Mail.

Die finale Landingpage wechselte den Kontext: aus einer Lieferentscheidung wurde plötzlich ein angeblich geteiltes OneDrive-Dokument. Diese Inkonsistenz ist ein wichtiger Hinweis. Der Benutzer sollte einen angezeigten Code kopieren, auf “Continue to Microsoft” klicken und sich anschließend mit dem Microsoft-Konto anmelden.

Warum diese Kette plausibel ist

Der Angriff kombiniert mehrere Muster, die 2025 und 2026 in Device-Code-Phishing-Kampagnen häufiger dokumentiert wurden:

• Redirects über bekannte Dienste, damit der initiale Link weniger verdächtig wirkt.
• Kurzlebige oder dynamisch erzeugte Device Codes, die erst beim Besuch der Landingpage angezeigt werden.
• Gefälschte Microsoft-, OneDrive-, SharePoint-, DocuSign- oder Lieferseiten als sozialer Kontext.
• Sehr lange finale Pfade mit UUID- oder Token-ähnlichen Segmenten.
• Anleitung zum Kopieren und Einfügen des Codes.
• Nachgelagerter Zugriff auf Microsoft 365.

Microsoft beschrieb Device-Code-Phishing bereits in Kampagnen wie Storm-2372 und später in AI-gestützten Angriffen gegen Microsoft 365. Proofpoint, Huntress und Sekoia beobachteten 2026 zudem eine starke Kommoditisierung durch Phishing-as-a-Service-Kits. Die Tendenz ist klar: Angreifer bewegen sich weg von reinem Passwortdiebstahl und hin zu token-zentrierten Identity-Angriffen.

Was nach erfolgreicher Autorisierung passieren kann

Wenn das Opfer den Code autorisiert, kann der Angreifer je nach App, Scopes, Policy und Token-Kontext verschiedene Folgeaktionen durchführen. Typische Ziele sind:

• Zugriff auf Mailbox-Inhalte.
• Suchen nach Rechnungen, Zahlungsvorgängen, laufenden Projekten und internen Kontakten.
• Versand weiterer Phishing-Mails aus einem echten Konto.
• Business Email Compromise.
• Erstellen oder Ändern von Inbox-Regeln.
• Einrichten von Forwarding oder Delegationen.
• Zugriff auf Dateien in OneDrive oder SharePoint, wenn entsprechende Tokens und Berechtigungen vorliegen.

Nicht jeder Device-Code-Phishing-Fall führt automatisch zu all diesen Folgen. Die Liste ist eine grobe Übersicht und muss von Fall zu Fall überprüft werden.

Sichtbare Warnsignale für Benutzer

Die Benutzerperspektive ist wichtig, weil Device-Code-Phishing legitime Teile des Login-Prozesses missbraucht. In diesem Fall gab es mehrere erkennbare Brüche:

• Der Betreff spricht von “Locations” und Versand, die finale Seite spricht von einem geteilten OneDrive-Dokument.
• Die E-Mail startet mit einem Google-Redirect statt direkt mit einem bekannten Anbieter.
• Die Lieferseite und die OneDrive-Seite liegen nicht auf den erwarteten Domains.
• Der Benutzer soll einen Code kopieren, obwohl er selbst kein neues Gerät eingerichtet hat.
• Die Seite erklärt den Code als “verification code”, verschweigt aber, welche App tatsächlich autorisiert wird.
• Der finale Host ist lang, zufällig und nicht vertrauenswürdig.

Eine einfache Awareness-Regel ist deshalb hilfreich:

Gib einen Microsoft Device Code nur ein, wenn du selbst gerade bewusst ein Gerät oder eine vertrauenswürdige App eingerichtet hast. Ein Code aus E-Mail, Chat, PDF, QR-Code oder einer fremden Webseite ist ein Incident-Signal.

Relevante Telemetrie

Für die erste Triage zählt eine klare Kette: Wer bekam die E-Mail, wer klickte, wer erreichte die Code-Seite und wer meldete sich danach über den Device Code Flow an?

Quelle	Worauf achten
E-Mail / URL-Klicks	Empfänger, Klicks auf google[.]com/url, Safe-Links-Rewrites und interne Weiterleitungen.
Proxy / DNS / Browser	Reihenfolge der Hosts: Google-Redirect, erste Redirect-Station, Zwischenseite, finale Device-Code-Seite, danach Microsoft-Login- oder Device-Login-Endpunkte.
Entra ID Sign-in Logs	AuthenticationProtocol, OriginalTransferMethod, AppDisplayName, ClientAppUsed, UserPrincipalName, IPAddress, Location, CorrelationId, ConditionalAccessStatus. Fokus: deviceCode (initiale Anmeldung) oder deviceCodeFlow (Folge-Sessions).
Mailbox / Graph	Nach bestätigtem Login: MailItemsAccessed, auffällige Graph-Zugriffe, neue Inbox Rules, Forwarding, Delegationen oder verdächtiger Mailversand.

Besonders relevant ist die zeitliche Nähe zwischen URL-Klick, Besuch der finalen Code-Seite und Device-Code-Anmeldung desselben Benutzers.

Detection Query

Die folgende Query ist ein Startpunkt. Feldnamen können je nach Tenant, Connector und Datenmodell abweichen. Sie sollte mit lokalen Baselines, Allowlists und bekannten legitimen Device-Code-Anwendungen kombiniert werden. AuthenticationProtocol == "deviceCode" markiert die initiale Device-Code-Anmeldung und wird von Entra ID nur bei erfolgreicher Anmeldung gesetzt; OriginalTransferMethod == "deviceCodeFlow" kennzeichnet Folge-Sessions, die mit zuvor über den Flow ausgestellten Tokens entstehen.

Microsoft Sentinel / KQL: Device-Code-Anmeldungen finden

SigninLogs
| where TimeGenerated > ago(14d)
| extend
    AuthProtocol = tostring(column_ifexists("AuthenticationProtocol", "")),
    TransferMethod = tostring(column_ifexists("OriginalTransferMethod", ""))
| where AuthProtocol has_cs "deviceCode"
   or TransferMethod has_cs "deviceCodeFlow"
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    ClientAppUsed,
    AuthProtocol,
    TransferMethod,
    IPAddress,
    Location,
    UserAgent,
    ConditionalAccessStatus,
    ResultType,
    ResultDescription,
    CorrelationId
| order by TimeGenerated desc

Mögliche Detection-Hinweise

Die folgenden Signale sind keine festen IOCs. Sie können bei Device-Code-Phishing helfen, müssen aber immer im Kontext der jeweiligen Kampagne, Umgebung und Telemetrie bewertet werden.

Typ	Signal	Warum es relevant ist	Confidence
E-Mail-URL	https://www.google[.]com/url?q=... mit verschachtelter externer Ziel-URL	Legitime Redirector-Dienste können den eigentlichen Zielhost im ersten Mail-Link verschleiern.	Medium
Entra ID Sign-in	AuthenticationProtocol enthält deviceCode oder OriginalTransferMethod enthält deviceCodeFlow	Der zentrale Identity-Hinweis auf eine Device-Code-Autorisierung.	High

Triage bei einem Verdachtsfall

Wenn ein Benutzer einen solchen Link geklickt oder einen Device Code eingegeben hat, sollte die Reaktion token-zentriert sein. Ein reiner Passwortreset ist zu wenig.

1. Benutzer identifizieren, die die E-Mail erhalten oder geklickt haben.
2. Entra ID Sign-in Logs auf Device Code Flow, ungewöhnliche Apps und auffällige IPs prüfen.
3. Refresh Tokens und Sign-in-Sessions widerrufen.
4. Passwort ändern, wenn Credential Exposure nicht ausgeschlossen werden kann.
5. MFA-Methoden prüfen, besonders neu hinzugefügte Methoden.
6. Beobachtete URLs und Domains in Mail-Gateway, Proxy, DNS-Filter oder EDR blockieren.

Risiko reduzieren

Die wirksamste Maßnahme ist, den Device Code Flow zu blockieren, wenn er nicht geschäftlich benötigt wird. Microsoft unterstützt dafür Conditional-Access-Kontrollen für Authentifizierungsflüsse. Vor einer harten Blockade sollte ein Tenant im Report-only-Modus prüfen, welche legitimen Workflows betroffen wären.

Praktische Maßnahmen:

• Conditional Access: Device Code Flow blockieren oder streng auf erlaubte Benutzer, Geräte, Standorte und Apps begrenzen.
• Authentication Transfer blockieren, wenn nicht benötigt.
• Benutzer schulen, dass echte Microsoft-Seiten trotzdem Teil eines Angriffs sein können.
• Alerts für Device-Code-Anmeldungen außerhalb bekannter legitimer Use Cases bauen.

Quellen und weiterführende Lektüre

• RFC 8628: OAuth 2.0 Device Authorization Grant
• Microsoft: Storm-2372 conducts device code phishing campaign
• Microsoft: AI-enabled device code phishing campaign
• Microsoft Learn: Block authentication flows with Conditional Access
• Microsoft Learn: Authentication flows in Conditional Access
• Proofpoint: Device Code Phishing Evolution and Identity Takeover
• Huntress: Railway PaaS M365 token replay campaign
• Huntress: Kali365 device code phishing kit
• Sekoia: EvilTokens device-code Phishing-as-a-Service
• FBI IC3: Kali365 public service announcement