Device Code Phishing: Eine unauffällige Bedrohung mit hoher Wirkung, die Aufmerksamkeit verdient

Einleitung

In der sich stetig wandelnden Bedrohungslandschaft der Cloud tritt nicht jeder Angreifer die Haustür ein. Manche warten einfach darauf, dass Sie selbst einen Seiteneingang öffnen. Einen, der auf Einfachheit, Geschwindigkeit und scheinbar harmlose Interaktionen ausgelegt ist. Einer der am meisten unterschätzten und zugleich zunehmend missbrauchten Mechanismen ist der OAuth 2.0 Device Code Flow.

Ursprünglich eingeführt, um eingabebeschränkte Geräte wie Smart-TVs, Drucker und IoT-Systeme zu unterstützen, hat sich diese Authentifizierungsmethode klammheimlich zu einem hochwertigen Ziel für Angreifer entwickelt. Warum? Weil sie legitime Access Tokens über einen Flow ausstellt, dem es häufig an Sichtbarkeit, Aufsicht und ausreichenden Kontrollmechanismen mangelt.

Wenn Sie für die Verteidigung von Microsoft-Umgebungen verantwortlich sind, ist es Zeit, sich die Risiken, Detection-Patterns und Response-Strategien rund um Device Code Phishing genauer anzusehen.

OAuth Device Code Flow

Bedrohungslage: Wie Angreifer den Device Code Flow missbrauchen

Der OAuth 2.0 Device Authorization Grant (RFC 8628) ermöglicht es einem Gerät, ein Access Token zu erhalten, indem sich der Benutzer über ein separates Gerät authentifiziert. Der Ablauf umfasst typischerweise:

Ein Paar aus device_code und user_code
Eine Login-URL (https://microsoft.com/devicelogin)
Polling des Token-Endpunkts, bis der Benutzer die Authentifizierung abschließt

Dieser legitime Flow wird zum Angriffsvektor, wenn:

Ein Angreifer mit einer eigenen Client-Anwendung einen Device Code anfordert.
Der Angreifer den User Code und die Login-URL per Phishing an das Opfer übermittelt wie etwa über eine gefälschte Teams-Meeting-Einladung. Im ersten Beispiel wird Social Engineering genutzt, um eine gefälschte Teams-Einladung zu verschicken: Der „An Besprechung teilnehmen“-Link leitet auf die Device-Code-Login-Seite um, die ID ist der Device Code. Im zweiten Beispiel wird die Freigabe eines Dokuments imitiert.

3. Das Opfer schließt die Authentifizierung ahnungslos auf der echten Microsoft-Login-Seite ab.
4. Nach erfolgreicher Authentifizierung werden Access Token und Refresh Token an die App des Angreifers ausgestellt — nicht an das Gerät des Opfers.

Sobald der Angreifer die Tokens hat, kann er:

Auf Microsoft Graph API, Outlook, Teams, OneDrive und SharePoint zugreifen
Nach sensiblen Daten suchen (z. B. Anmeldeinformationen, Zugriffslinks)
Posteingangsregeln anlegen, Nachrichten löschen oder Dokumente exfiltrieren
Mithilfe von Primary Refresh Tokens (PRTs) persistente Geräte registrieren

Konkretes Beispiel: Der Bedrohungsakteur Storm-2372 nutzt diese Methode seit 2024 aktiv aus und missbraucht legitime Microsoft-Infrastruktur, um Zugriff auf Organisationen aus Behörden, Energie, Bildung und IT-Dienstleistung zu erlangen.

Technische Sichtbarkeit & Detection (mit KQL)

Die Überwachung von deviceCode-Authentifizierungen erfordert gezieltes Hunting. Im Folgenden finden Sie zentrale Queries und Hinweise, um auffällige Aktivitäten sichtbar zu machen:

1. Erfolgreiche Device-Code-Anmeldungen

SigninLogs 
| where TimeGenerated > ago(7d)
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0 // Successful sign-ins
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress,
Location, DeviceDetail, RiskLevelDuringSignIn, CorrelationId

Zweck: Baseline aufbauen oder vorhandene Nutzung identifizieren.

2. Timechart der Device-Code-Authentifizierungen je App

SigninLogs
| where TimeGenerated > ago(90d)
| where AuthenticationProtocol == "deviceCode"
| summarize count() by bin(TimeGenerated, 1d), AppDisplayName
| render timechart

Zweck: Trendanalyse und App-Monitoring im zeitlichen Verlauf.

3. Top-Benutzer nach App und Ressource

SigninLogs
| where TimeGenerated > ago(90d)
| where AuthenticationProtocol == "deviceCode"
| summarize count() by UserPrincipalName, AppDisplayName, ResourceDisplayName

Zweck: Legitime Nutzung erkennen und Anomalien in Volumen oder Anwendung sichtbar machen.

4. Device-Code-Anmeldungen mit Device-Registration-Service-Events verknüpfen

SigninLogs
| where TimeGenerated > ago(90d)
| where AuthenticationProtocol == "deviceCode"
| where ResourceDisplayName == "Device Registration Service"
| join AADNonInteractiveUserSignInLogs on $left.CorrelationId == $right.CorrelationId
| extend UserAgentNON = UserAgent1
| project UserPrincipalName, AppDisplayName, ClientAppUsed, ResourceDisplayName, UserAgent, UserAgentNON, IncomingTokenType, IncomingTokenType1

Zweck: Geräte-Registrierungen mit potenziell schadhaften Sessions korrelieren.

5. Nicht verwaltete bzw. nicht konforme Geräte

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where AuthenticationProtocol == "deviceCode"
| where isempty(DeviceDetail.deviceId) or DeviceDetail.isManaged == false or
DeviceDetail.isCompliant == false
| project TimeGenerated, UserPrincipalName, AppDisplayName, AppId, IPAddress,
Location, DeviceDetail, RiskLevelDuringSignIn, CorrelationId

Zweck: Erfolgreiche Device-Code-Anmeldungen von potenziell riskanten Geräten finden — möglicherweise PRT-Eskalation?

6. Microsoft Authentication Broker

SigninLogs
| where TimeGenerated > ago(7d)
| where AuthenticationProtocol == "deviceCode"
| where AppId == "29d9ed98-a469-4536-ade2-f981bc1d605e" // Microsoft Authentication Broker
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location,
DeviceDetail, RiskLevelDuringSignIn, ResultType, CorrelationId

Zweck: Mögliche PRT-Diebstahlversuche erkennen.

7. Benutzer-/IP-Kombination

let lookback = 30d;
let timeframe = 1d;
let knownUserIPs = SigninLogs
    | where TimeGenerated between (ago(lookback) .. ago(timeframe))
    | where AuthenticationProtocol == "deviceCode" and ResultType == 0
    | summarize knownIPs = make_set(IPAddress) by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(timeframe)
| where AuthenticationProtocol == "deviceCode" and ResultType == 0
| join kind=leftouter knownUserIPs on UserPrincipalName
| where isnull(knownIPs) or array_index_of(knownIPs, IPAddress) == -1
| project
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    AppId,
    IPAddress,
    Location,
    knownIPs,
    DeviceDetail,
    RiskLevelDuringSignIn,
    ResultType,
    CorrelationId,
    UserAgent,
    IncomingTokenType

Zweck: Erkennen, wenn ein Benutzer den Device Code Flow erstmals erfolgreich von einer bestimmten IP aus nutzt.

8. Phishing-Mail finden

EmailUrlInfo
| where TimeGenerated >= ago(90d)
| where Url has_any ("aka.ms/devicelogin", "microsoft.com/devicelogin", "login.microsoftonline.com/common/oauth2/deviceauth")
| project TimeGenerated, Url, NetworkMessageId, UrlLocation
| join (EmailEvents) on NetworkMessageId
| project
    TimeGenerated,
    Url,
    UrlLocation,
    Subject,
    SenderFromAddress,
    RecipientEmailAddress,
    DeliveryAction,
    DeliveryLocation

Zweck: Prüfen, ob ein Benutzer eine Mail mit einem Link auf die Device-Code-Login-Seite erhalten hat.

Indicators of Attack (IoA)

Achten Sie auf folgende Muster:

AuthenticationProtocol == "deviceCode" von unbekannten oder riskanten IP-Adressen
Anmeldungen von nicht verwalteten oder nicht konformen Geräten
Auffällige App IDs (insbesondere generische Clients wie der Microsoft Authentication Broker)
Mailweiterleitungs- oder Posteingangsregeln, die kurz nach einer Anmeldung erstellt werden
Plötzliches Löschen großer Mail-Mengen
Wiederholtes Login-Verhalten unter Beteiligung des Device Registration Service

Hinweis: Device-Code-Authentifizierungen umgehen häufig die klassische Redirect-URI-Analyse und sind mit Standardregeln nur schwer zu erfassen. Angreifer nutzen genau dieses „reibungsarme“ Design für Persistenz und Tarnung.

Mitigation: Strategien zur Risikoreduktion

Kontrollbereich	Empfehlung
Conditional Access	Device Code Flow auf genehmigte Benutzer und Anwendungen beschränken oder vollständig blockieren.
Token Hygiene	Refresh Tokens für inaktive oder kompromittierte Sessions regelmäßig widerrufen.
App Governance	App IDs, die den Device Code Flow nutzen dürfen, überwachen und nachhalten.
User Training	Benutzer schulen, Anmeldeaufforderungen zu prüfen, unaufgeforderte Meeting-Einladungen zu meiden und Missbrauchsmuster zu erkennen.
Behavioral Analytics	Microsoft Sentinel, UEBA und Defender XDR zur Anomalieerkennung nutzen.

Warnung: Ein vollständiges Blockieren des Flows kann Dienste stören, die darauf angewiesen sind (z. B. bestimmte Drucker oder Compliance-Geräte). Den Rollout sorgfältig testen und phasenweise umsetzen.

Aktions-Checkliste für Defender-Teams

✔	Aufgabe
☐	Nutzung von deviceCode in den letzten 90 Tagen in Sentinel- und Entra-Logs untersuchen.
☐	Mit verdächtigen App IDs und unbekannten User Agents korrelieren.
☐	Device Code Flow per Conditional Access einschränken.
☐	Token-Ausstellung prüfen und automatisierte Token-Revocation-Policies einführen.
☐	Eigene Sentinel-Regeln für anomales Verhalten nach deviceCode-Anmeldungen integrieren.
☐	Das Team über diesen Angriffsvektor und seine Erkennung in Logs aufklären.
☐	Berechtigungen und die Registrierung neuer Geräte regelmäßig überprüfen.
☐	Anwenderinformationen oder eine Schulung bereitstellen, um die Awareness zu erhöhen.

Fazit

Device Code Phishing ist nichts Spekulatives es ist aktiv, wirksam und in der Praxis hinreichend dokumentiert. Anders als klassisches Phishing oder Token-Diebstahl bewegt es sich vollständig innerhalb legitimer Authentifizierungsflüsse und nutzt das Vertrauen aus, das Sie der Microsoft-Infrastruktur ohnehin entgegenbringen.

Genau das macht es so heimtückisch. Mit der richtigen Kombination aus Detection, Conditional Access, Anwender-Awareness und Token-Management lässt sich das Risiko jedoch deutlich reduzieren.

Bleiben wir keine passiven Beobachter. Als Verteidiger liegt es an uns, zu erkennen, anzupassen und zu handeln.

Haben Sie eigene Erkenntnisse oder Fragen? Lassen Sie uns voneinander lernen.

Quellen

• OAuth 2.0 device authorization grant - Microsoft identity platform | Microsoft Learn
• RFC 8628 - OAuth 2.0 Device Authorization Grant
• Device Code Phishing in Google Cloud and Azure | Huntress
• Storm-2372 conducts device code phishing campaign | Microsoft Security Blog
• Phishing for Primary Refresh Tokens and Windows Hello keys - dirkjanm.io
• Introducing a new phishing technique for compromising Office 365 accounts
• How to Detect Malicious OAuth Device Code Phishing
• Multiple Russian Threat Actors Targeting Microsoft Device Code Authentication | Volexity
• The Art of the Device Code Phish – Boku

Zurück zum Blog

Planen Sie Ihren Weg zur Sicherheit mit uns.

Device Code Phishing: Eine unauffällige Bedrohung mit hoher Wirkung, die Aufmerksamkeit verdient

Einleitung

OAuth Device Code Flow

Bedrohungslage: Wie Angreifer den Device Code Flow missbrauchen

Technische Sichtbarkeit & Detection (mit KQL)

Indicators of Attack (IoA)

Mitigation: Strategien zur Risikoreduktion

Aktions-Checkliste für Defender-Teams

Fazit

Quellen

Weitere Blogbeiträge

Device Code Phishing: Eine unauffällige Bedrohung mit hoher Wirkung, die Aufmerksamkeit verdient

Proaktives Schwachstellenmanagement ist der Schlüssel zu einer widerstandsfähigen Organisation

Modernisierung der Identitätsverwaltung