Device Code Phishing: Wie OAuth Device Flow Entra-ID-Konten kompromittiert

Device Code Phishing missbraucht einen legitimen OAuth Device Authorization Flow, um einen Benutzer zur Autorisierung einer vom Angreifer kontrollierten Sitzung zu bringen. In Microsoft-Entra-ID-Umgebungen kann der Benutzer einen kurzen Code auf der echten Microsoft-Geräteanmeldeseite eingeben, die normale Authentifizierung abschließen, MFA erfüllen und trotzdem dem Angreifer ermöglichen, Tokens für seinen Client zu erhalten.

Diese Unterscheidung ist wichtig. Device Code Phishing ist kein Password Spraying, kein OAuth Consent Phishing, keine MFA Fatigue und keine klassische Credential-Harvesting-Seite. Es ist ein tokenzentrierter Angriffspfad gegen einen gültigen Authentifizierungsflow, der für Geräte mit eingeschränkter Eingabe entwickelt wurde. Verteidiger müssen ihn über Conditional Access, Anmeldeprotokolle, Token-Untersuchung und Aktivität nach der Authentifizierung bewerten.

Teams, die bereits MFA Fatigue, Password Spraying, die Grenzen von MFA allein oder einen Microsoft-Entra-ID-Sicherheitsaudit prüfen, sollten Device Code Phishing separat behandeln. Die Benutzerinteraktion und die resultierende Sitzung sehen nicht wie eine normale gefälschte Login-Seite aus.

Was ist Device Code Phishing?

Device Code Phishing ist eine Social-Engineering-Technik, die den OAuth 2.0 Device Authorization Grant missbraucht. Der Angreifer startet einen Device Code Flow von einem kontrollierten Client, erhält einen User Code und eine Verification URI und bringt das Ziel dazu, diesen Code in einem Browser einzugeben. Wenn das Ziel die Authentifizierung abschließt, kann der Angreifer-Client Tokens für die angeforderte Ressource und die Scopes erhalten.

Der legitime Flow existiert für Geräte, die keinen vollwertigen Browser oder keine komfortable Eingabe haben. Microsoft nennt Szenarien wie Smart-TV, IoT-Gerät oder Drucker. Das Gerät zeigt einen Code an, der Benutzer meldet sich auf einem anderen Gerät an, und der eingeschränkte Client fragt den Token Endpoint ab, bis die Autorisierung erfolgreich ist oder abläuft.

Device Code Phishing dreht dieses Modell um. Das Gerät, das die Autorisierung anfordert, ist kein Firmen-TV oder Drucker vor dem Benutzer. Es ist ein vom Angreifer kontrollierter Client. Die Zielperson wird gebeten, den Code auf einer legitimen Microsoft-Seite einzugeben. Dadurch wirkt der Ablauf vertrauter als eine offensichtliche Phishing-Seite.

Der Begriff MFA-Bypass muss hier präzise verwendet werden. In vielen Fällen wird MFA nicht kryptografisch gebrochen. Der Benutzer kann MFA tatsächlich erfolgreich abschließen. Das Problem ist, dass er die Device-Code-Sitzung des Angreifers autorisiert. Eine erfolgreiche MFA-Prüfung beweist daher nicht, dass die resultierende Sitzung zu einem vertrauenswürdigen Gerät, Standort oder Workflow gehört.

Wie der OAuth Device Code Flow funktioniert

Der OAuth Device Authorization Grant ist in RFC 8628 definiert. Der Client fordert eine Geräteautorisierung beim Authorization Server an und erhält Werte wie device_code, user_code, verification_uri, Ablaufzeit und Polling-Intervall. Der Benutzer besucht die Verification URI und gibt den User Code ein. Währenddessen fragt der Client den Token Endpoint mit dem device_code ab.

Die Microsoft Identity Platform implementiert dieses Muster über den Device Code Flow. Eine erfolgreiche Token-Antwort kann einen Access Token, einen ID Token bei angefordertem openid und einen Refresh Token enthalten, wenn der ursprüngliche Scope offline_access enthielt. In einem Phishing-Szenario ist genau dieses Tokenmaterial das Ziel. Der Angreifer braucht das Kennwort nicht zu kennen, wenn das Opfer den Autorisierungsflow abschließt.

RFC 8628 beschreibt Remote Phishing ausdrücklich. Der Flow kann auf einem Gerät im Besitz des Angreifers gestartet werden, während das Opfer eine Nachricht mit Verification URL und User Code erhält. Der RFC empfiehlt, dem Benutzer klar zu machen, dass er ein Gerät autorisiert, und zu bestätigen, dass sich dieses Gerät in seinem Besitz befindet.

Abgrenzung zu ähnlichen Angriffen

Device Code Phishing liegt nahe an mehreren Identitätsangriffen, funktioniert aber anders.

Diese Unterschiede bestimmen die Abwehr. Ein Tenant kann gute Kennwortkontrollen haben und dennoch exponiert sein, wenn Device Code Flow breit erlaubt ist. Ein Tenant kann MFA erzwingen und trotzdem kompromittiert werden, wenn Benutzer fremde Sitzungen autorisieren. Umgekehrt ersetzt das Blockieren des Flows nicht die Korrektur von Conditional-Access-Lücken oder Identity-Protection-Richtlinien.

Warum Device Code Phishing gegen Entra ID funktioniert

Der Angriff funktioniert, weil das Opfer sein Kennwort nicht auf einer offensichtlichen Angreifer-Domain eingibt. Es kann auf eine von Microsoft gehostete Verifizierungsseite geleitet werden und vertraute Authentifizierungsdialoge sehen. Awareness, die nur gefälschte Domains oder verdächtige Passwortseiten behandelt, deckt dieses Muster nicht ausreichend ab.

Microsofts Untersuchungen zu Kampagnen in 2025 und 2026 beschreiben denselben Kern: Akteure missbrauchen einen legitimen Device-Code-Authentifizierungsflow, bringen das Opfer zur Authentifizierung der Angreifer-Sitzung und erhalten gültige Tokens, ohne das Kennwort direkt zu stehlen. Microsoft beschrieb 2026 außerdem Automatisierung und dynamische Codegenerierung, damit kurzlebige Codes gültig bleiben, wenn der Benutzer mit dem Lure interagiert.

Die Technik ist für Entra ID und Microsoft 365 relevant, weil die resultierenden Tokens je nach App, Ressource und Scopes gegen Exchange Online, Microsoft Graph, SharePoint Online oder Teams verwendet werden können. Das bedeutet nicht, dass jeder Device-Code-Sign-in bösartig ist. Es bedeutet, dass Verteidiger wissen müssen, ob dieser Flow im Tenant legitim verwendet wird, durch welche Apps, von welchen Standorten und unter welchen Conditional-Access-Entscheidungen.

Ein häufiger Fehler ist, MFA-Erfolg als endgültigen Legitimitätsnachweis zu behandeln. Beim Device Code Phishing kann der MFA-Event echt sein. Die Frage lautet, ob der Benutzer den Client autorisieren wollte, der das Token erhält. Die Sign-in-Prüfung muss daher Authentifizierungsprotokoll, App, Ressource, IP-Adresse, Gerätedetails, Conditional-Access-Status, Risikoerkennung, Session-IDs und nachgelagerte Workload-Aktivität betrachten.

Angriffskette

Eine typische Kette sieht so aus:

1. Der Angreifer startet eine Device-Authorization-Anfrage von kontrollierter Infrastruktur oder einem Tool.
2. Die Identitätsplattform gibt User Code, Verification URI, Ablaufzeit und Polling-Intervall zurück.
3. Der Angreifer übermittelt den Code per E-Mail, Chat, Kollaborationseinladung, Dokument-Lure oder anderem Kanal.
4. Das Opfer besucht die Verifizierungsseite, gibt den Code ein, meldet sich an und erfüllt die Authentifizierungsanforderungen.
5. Der Angreifer-Client pollt den Token Endpoint und erhält nach Abschluss der Autorisierung Tokens.
6. Der Angreifer nutzt den Zugriff, um E-Mails zu lesen, Microsoft Graph abzufragen, Tenant-Daten zu enumerieren, Inbox-Regeln zu erstellen, Dateien abzurufen oder weitere Aktionen auszuführen, die Token und Konto erlauben.
7. Der Verteidiger sieht möglicherweise einen erfolgreichen Device-Code-Sign-in, gefolgt von nicht-interaktiver Token-Nutzung und Workload-Aktivität.

Die Kette darf nicht auf ein einzelnes Signal reduziert werden. deviceCode im Authentifizierungsprotokoll ist wichtig, beweist aber allein keine Bösartigkeit. Die Untersuchung wird belastbarer, wenn dieses Ereignis mit ungewohntem Standort, ungewohnter App, Risikoindikatoren, unerwartetem Ressourcenzugriff, Mailregel-Erstellung, Graph-Aktivität oder einem Benutzer ohne normale Device-Code-Nutzung korreliert.

Detection

Legitimen Device-Code-Einsatz baselinen

Detection beginnt mit einer Known-Good-Baseline. Viele Organisationen haben wenig oder keinen legitimen Bedarf für Device Code Flow. Andere nutzen ihn für bestimmte Legacy-Tools, Raumgeräte, Entwickler-Workflows oder Geräteregristrierung. Die erste Frage lautet, ob der Flow überhaupt erwartet wird.

In Microsoft-Entra-Sign-in-Logs, die nach Log Analytics exportiert werden, enthält die Tabelle SigninLogs das Feld AuthenticationProtocol. Microsoft dokumentiert deviceCode als möglichen Wert. Weitere relevante Felder sind OriginalTransferMethod, AppDisplayName, ResourceDisplayName, IPAddress, DeviceDetail, UserAgent, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId und UniqueTokenIdentifier.

Nach deviceCode-Anmeldungen suchen

Eine Basisabfrage inventarisiert erfolgreiche und fehlgeschlagene Device-Code-Nutzung:

SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, ResultType, ResultDescription,
          SessionId, UniqueTokenIdentifier
| order by TimeGenerated desc

Diese Abfrage ist ein Startpunkt, keine vollständige Detection. Prüfen Sie, ob App und Ressource zur Rolle des Benutzers passen. Ein Entwickler, der ein bekanntes CLI aus einem bekannten Netzwerk authentifiziert, ist anders zu bewerten als ein Finanzbenutzer, der plötzlich einen Device Code Flow aus einem neuen Land autorisiert und danach Graph- oder Exchange-Aktivität erzeugt.

Für eine stärkere Regel kann aktuelle Nutzung gegen historische Nutzung verglichen werden:

let lookback = 30d;
let recent = 1d;
let knownUsers = SigninLogs
| where TimeGenerated between (ago(lookback) .. ago(recent))
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| distinct UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| where AuthenticationProtocol == "deviceCode" or OriginalTransferMethod == "deviceCodeFlow"
| where ResultType == 0
| where UserPrincipalName !in (knownUsers)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResourceDisplayName,
          IPAddress, Location, DeviceDetail, UserAgent, ConditionalAccessStatus,
          RiskLevelDuringSignIn, RiskEventTypes_V2, SessionId, UniqueTokenIdentifier

Kontext statt Einzelsignal priorisieren

Priorisieren Sie Ereignisse mit diesen Merkmalen:

• erste beobachtete Device-Code-Nutzung für Benutzer oder Abteilung
• ungewohnte App oder Ressource für die Rolle
• Anmeldung von IP, ASN, Land oder Netzwerk außerhalb des Normalmusters
• RiskEventTypes_V2 mit anonymem IP- oder Threat-Intelligence-Bezug
• erfolgreicher Device Code Flow, gefolgt von nicht-interaktiver Token-Nutzung aus ungewohnter Infrastruktur
• neue Inbox-Regeln, verdächtiger Mailzugriff, ungewöhnliche Graph-, SharePoint- oder Teams-Aktivität
• Geräte-Registrierung oder Join-Aktivität im selben Zeitfenster ohne normalen Onboarding-Kontext

Microsoft-Entra-Linkable-Identifiers machen die Phase nach der Authentifizierung untersuchbar. Starten Sie mit SessionId oder UniqueTokenIdentifier aus dem Sign-in-Log und korrelieren Sie mit Exchange Online, Microsoft Graph, SharePoint Online oder Teams Audit Logs. Microsoft dokumentiert dieses Korrelationsmodell für Aktivitäten einer bestimmten Session oder eines bestimmten Tokens.

Microsoft Defender und Entra ID Protection können stärkere Signale ergänzen. Microsoft dokumentiert Risikoerkennungen wie anonyme IP-Adresse, Microsoft Entra Threat Intelligence, anomalous token und suspicious API traffic. Nutzen Sie diese Signale zur Priorisierung, aber nicht als Ersatz für die Frage, ob der Device Code Flow legitim war.

Remediation und Härtung

Device Code Flow blockieren oder begrenzen

Die direkteste Kontrolle ist, Device Code Flow mit Conditional Access zu beschränken oder zu blockieren. Microsoft empfiehlt, möglichst nahe an einen unilateralen Block zu kommen, vorher bestehende Nutzung zu auditieren und den Flow nur für gut dokumentierte und gesicherte Use Cases zuzulassen. Für Organisationen ohne legitimen Bedarf beschreibt Microsoft ein Conditional-Access-Muster, das die Authentication-Flows-Bedingung nutzt, Device Code Flow auswählt und Zugriff blockiert.

Ein praktischer Härtungspfad:

1. Aktuelle Device-Code-Nutzung in Entra-Sign-in-Logs inventarisieren.
2. Legitime Benutzer, Apps, Ressourcen, Standorte und Geräte-Registrierungsabhängigkeiten identifizieren.
3. Conditional-Access-Policy im Report-only-Modus für Device Code Flow erstellen.
4. Emergency-Access-Konten und dokumentierte legitime Use Cases ausschließen.
5. Policy-Auswirkung und Sign-in-Logs prüfen.
6. Policy nach verstandenem Impact aktivieren.
7. Blockierte Versuche und unerwartete Ausnahmen überwachen.

Kompatibilität vor Enforcement prüfen

Es gibt eine wichtige Kompatibilitätsgrenze. Microsoft weist darauf hin, dass Organisationen, die Device Code Flow gegen den Device Registration Service verwenden und eine Authentication-Flows-Policy auf alle Ressourcen anwenden, den Device Registration Service möglicherweise ausschließen müssen. Microsoft dokumentiert die Client-ID dieser Ressource und erklärt, wie Sign-in-Logs nach Ressource und Device Code Flow gefiltert werden. Blockieren Sie daher nicht blind alle Ressourcen, bevor Abhängigkeiten der Geräte-Registrierung geprüft sind.

Auch Conditional-Access-Grant-Controls müssen präzise interpretiert werden. Microsoft dokumentiert, dass bei Verwendung des Device-Code-OAuth-Flows Grant Controls für verwaltetes Gerät oder Gerätezustand nicht im gleichen Modell unterstützt werden, weil das authentifizierende Gerät seinen Zustand nicht an das Gerät liefern kann, das den Code bereitstellt. Ein Policy-Modell nur auf Basis von compliant device oder hybrid-joined device kann sich daher unerwartet verhalten. Nutzen Sie die Authentication-Flows-Bedingung, um den Flow selbst zu kontrollieren.

Blast Radius nach Autorisierung reduzieren

Ergänzende Kontrollen sind wichtig, weil Device Code Phishing oft nur ein Einstieg in einen größeren Identitätsvorfall ist:

• phishing-resistente Authentifizierung für privilegierte Rollen verwenden, wo unterstützt, ohne anzunehmen, dass Authentication Strength jedes Device-Code-Szenario blockiert
• risikobasierten Conditional Access und Identity Protection nutzen, um riskante Sitzungen zu challengen oder zu blockieren
• privilegierte Konten von Alltagskonten trennen und stehende Rollen reduzieren, wie in Azure privilegierter Zugriff beschrieben
• App-Consent und App-Berechtigungen prüfen, damit Token-Missbrauch weniger Reichweite hat
• Exchange, Graph, SharePoint und Teams nach verdächtigen Sign-ins überwachen
• Safe Links, Anti-Phishing-Kontrollen und Benutzer-Reporting einsetzen, um Lures schneller zu erkennen
• Token Protection dort prüfen, wo Client, Plattform und Workload unterstützt werden

Incident Response nach Device Code Phishing

Sign-in- und Workload-Beweise sichern

Bei einem Verdacht sollte die Antwort auf Token-Containment und Workload-Scope fokussieren, nicht nur auf Kennwort-Reset.

Sichern Sie zuerst Benutzer, App, Ressource, IP, Standort, AuthenticationProtocol, OriginalTransferMethod, Conditional-Access-Ergebnis, Risikodetails, SessionId und UniqueTokenIdentifier. Bewahren Sie die ursprüngliche Phishing-Nachricht mit Headern und URLs auf, verlassen Sie sich aber nicht allein auf URL-Reputation, weil das Opfer auf eine legitime Microsoft-Verifizierungsseite geleitet worden sein kann.

Sitzungen widerrufen

Widerrufen Sie aktive Sitzungen. Microsoft Graph revokeSignInSessions invalidiert Refresh Tokens, die Anwendungen für einen Benutzer ausgestellt wurden, und Browser-Session-Cookies, indem der Gültigkeitszeitpunkt der Benutzer-Sitzung zurückgesetzt wird. Microsoft weist auf eine Verzögerung von einigen Minuten hin und darauf, dass externe Benutzer über ihren Home Tenant anmelden. Bei einem kompromittierten Gastkonto muss der Home-Tenant-Pfad berücksichtigt werden. Gastkonten sollten separat geprüft werden, insbesondere wenn Azure-Gastkonten veraltet oder unkontrolliert sind.

Setzen Sie Kennwörter nur zurück, wenn die Untersuchung es stützt. Device Code Phishing kann Tokens kompromittieren, ohne das Kennwort direkt zu stehlen. Ein Reset kann dennoch nötig sein, wenn Credential Theft, Mailbox-Regeln, MFA-Methodenänderung, verdächtige Geräte-Registrierung oder andere Kompromittierungspfade sichtbar sind. Ein Kennwort-Reset allein reicht nicht, wenn Refresh Tokens und aktive Sitzungen gültig bleiben.

Nachgelagerte Aktivität abgrenzen

Nutzen Sie linkable identifiers, um Exchange Online, Microsoft Graph, SharePoint Online und Teams-Aktivität zur Session oder zum Token zu verfolgen. Suchen Sie nach Mailbox-Regeln, Nachrichtenlese- oder Exportaktivität, Dateidownloads, OAuth-App-Änderungen, Gruppenänderungen, Änderungen an Authentifizierungsmethoden, Geräte-Registrierungen und administrativen Aktionen.

Schließen Sie danach die Kontrolllücke. Wenn Device Code Flow unnötig war, blockieren Sie ihn. Wenn er für einen engen Workflow nötig ist, beschränken Sie ihn auf dokumentierte Benutzer, Apps, Standorte und Ressourcen. Erstellen Sie anschließend Alerts für Nutzung außerhalb dieses Musters.

Validierung nach der Härtung

Prävention validieren

Validierung muss Prävention und Sichtbarkeit beweisen. Prüfen Sie, dass die Conditional-Access-Policy für Authentication Flows aktiviert ist und auf die vorgesehenen Benutzer und Ressourcen wirkt. Testen Sie mit einem unprivilegierten Konto in einem kontrollierten Pfad. Ein blockierter Device Code Flow sollte in Sign-in-Logs mit der entsprechenden Conditional-Access-Entscheidung erscheinen. Emergency-Access-Konten bleiben ausgeschlossen, müssen aber regelmäßig überprüft werden.

Für Kompatibilität prüfen Sie legitime Geräte-Registrierung und Legacy-Tools. Wenn Device Registration Service Device Code Flow verwendet, validieren Sie die dokumentierte Ausnahme und bestätigen Sie, dass nur die beabsichtigte Ressource ausgenommen ist. Erstellen Sie keine breiten Ausnahmen, die die ursprüngliche Exposition wiederherstellen.

Monitoring und Response validieren

Für Detection bestätigen Sie, dass Device-Code-Sign-ins im Entra-Portal und in Log Analytics sichtbar sind. Prüfen Sie, dass AuthenticationProtocol, OriginalTransferMethod, App, Ressource, IP, Gerätedetails, Risiko-Felder, SessionId und UniqueTokenIdentifier Analysten zur Verfügung stehen. Stellen Sie sicher, dass Pivoting von einem Sign-in zu Exchange-, Graph-, SharePoint- und Teams-Auditdaten möglich ist, soweit Lizenzierung und Logging es erlauben.

Für Response führen Sie eine Tabletop-Übung durch. Starten Sie mit einem verdächtigen deviceCode-Sign-in und verlangen Sie, dass der Analyst Benutzer, App, Ressource, Session-ID, Token-Identifier, Workload-Folgeaktivität, Session-Revocation-Pfad und finalen Containment-Nachweis identifiziert. Das trennt eine vorhandene Kontrolle von einer operativ nutzbaren Kontrolle.

Wie EtcSec verwandte Exposition erkennt

EtcSec sollte Device Code Phishing als Identity-Angriffspfad und Posture-Problem behandeln, nicht nur als E-Mail-Problem. Hochwertige Findings sind die Bedingungen, die ein tokenbasiertes Social-Engineering-Ereignis in eine Tenant-Kompromittierung verwandeln.

Relevante Expositionen sind Conditional-Access-Policies ohne Einschränkung des Device Code Flow, fehlende oder schwache risikobasierte Policies, privilegierte Benutzer ohne starke administrative Isolation, zu viele stehende Admin-Rollen, Gastkonten ohne starke Zugriffskontrollen und überprivilegierte App Registrations. Für technische Teams ist die nützliche Ausgabe eine konkrete Liste: wer Device Code Flow nutzen darf, welche Benutzer ausgenommen sind, ob riskante Sign-ins blockiert oder nur geloggt werden, welche privilegierten Konten Cloud-Sitzungen aus niedrig vertrauenswürdigen Kontexten autorisieren könnten und welche Apps oder delegated permissions eine gestohlene Sitzung gefährlicher machen.

Zugehörige Kontrollen

Device Code Phishing ist wirksam, weil es zwischen legitimem Authentifizierungsdesign und Benutzerabsicht liegt. Die belastbare Korrektur ist kein MFA-Slogan. Sie ist eine Tenant-Posture, in der riskante Authentifizierungsflows eingeschränkt sind, verdächtige Device-Code-Sign-ins sichtbar sind, Token-Aktivität verfolgbar ist und privilegierter Zugriff nicht davon abhängt, dass Benutzer unter sozialem Druck immer richtig entscheiden.

Primäre Referenzen

• RFC 8628: OAuth 2.0 Device Authorization Grant
• Microsoft identity platform and OAuth 2.0 device authorization grant flow
• Authentication flows as a condition in Conditional Access
• Block authentication flows with Conditional Access policy
• How to configure grant controls in Microsoft Entra
• Protecting tokens in Microsoft Entra ID
• Azure Monitor Logs reference: SigninLogs
• Track and investigate identity activities with linkable identifiers
• Microsoft Graph: revokeSignInSessions
• Microsoft Security Blog: Storm-2372 conducts device code phishing campaign
• Microsoft Security Blog: Inside an AI-enabled device code phishing campaign
• MITRE ATT&CK T1566.002 Spearphishing Link
• MITRE ATT&CK T1550.001 Application Access Token