Gerätecodeangriffe in Azure: Von der Ausnutzung bis zur Erkennung

TL; DR

Was es ist: Gerätecode-Phishing ist eine OAuth-Missbrauchstechnik, bei der Angreifer einen legitimen Gerätecode-Authentifizierungsablauf gegen Microsoft-Gerätecodes initiieren. Entra IDAnschließend wird der Benutzer dazu verleitet, den resultierenden Code auf der echten login.microsoft.com/devicelogin-Seite einzugeben – wodurch der Angreifer ein gültiges Zugriffstoken erhält, ohne jemals ein Passwort abzufangen. 

Warum es darauf ankommt: Innerhalb eines Jahres hat sich die Technologie von staatlichen Akteuren (die mit Russland in Verbindung stehende Hackergruppe STORM-2372, aktiv seit August 2024) zu einem frei verfügbaren Angriffswerkzeug entwickelt. Das von Microsoft im April 2026 vorgestellte EvilTokens PhaaS-Toolkit automatisiert den gesamten Ablauf – es umgeht die 15-minütige Gültigkeitsdauer des Codes und führt alle 24 Stunden 10 bis 15 personalisierte Kampagnen durch. 

Warum es schwer zu erkennen ist: Es gibt keine gefälschte Anmeldeseite, keine Domain mit Tippfehlern, keine Anmeldeinformationen werden abgefangen und es gibt keine Schadsoftware, die gescannt werden könnte. Die einzige beteiligte URL ist login.microsoft.com/devicelogin. Die Multi-Faktor-Authentifizierung (MFA) wird auf dem echten Gerät des Opfers erfolgreich abgeschlossen, sodass alle Signale, nach denen ein E-Mail-Gateway, ein EDR-System oder ein Identitätsschutzprodukt sucht, keine Auffälligkeiten zeigen. 

Wie es sich von AiTM unterscheidet: Bei Adversary-in-the-Middle-Angriffen wird eine gefälschte Anmeldeseite als Proxy verwendet, um Sitzungscookies zu stehlen. Phishing-Angriffe über Gerätecode umgehen den Proxy vollständig – das Opfer authentifiziert sich auf der echten Microsoft-Seite, sodass keine AiTM-Infrastruktur vorhanden ist, die erkannt, blockiert oder abgeschaltet werden könnte. 

Kernerkennungssignal: Eine erfolgreiche Anmeldung, bei der die Authentifizierungsmethode Gerätecode ist, die aufgerufene Ressource ein Microsoft-Client von einem Drittanbieter ist (z. B. Azure CLI, Microsoft Office) und die Anmeldung von einem ungewöhnlichen Standort oder durch eine Entität erfolgt, die sich normalerweise nicht mit Gerätecodes authentifiziert. Nahezu kein legitimer Endbenutzer-Workflow erzeugt dieses Muster; für viele Organisationen ist jeder Treffer eine Untersuchung wert. 

Sofortige Reaktion bei Erkennung: Entziehen Sie dem Benutzer unverzüglich den Zugriff (siehe Microsoft-DokumentationDeaktivieren Sie den kompromittierten Benutzer und entfernen Sie seine Rollenzuweisungen. Beachten Sie, dass das Widerrufen von Aktualisierungstoken bereits ausgestellte Zugriffstoken nicht ungültig macht – diese bleiben bis zu ihrem Ablaufdatum gültig. Suchen Sie nach verdächtigen Aktivitäten, die von der verdächtigen Sitzung ausgehen. Das alleinige Widerrufen von Token reicht nicht aus – der Angreifer könnte bereits dauerhaften Zugriff erlangt haben.

Wichtigste politische Maßnahme: Sperren Sie den Gerätecodefluss über bedingten Zugriff für alle Benutzergruppen, die keinen dokumentierten geschäftlichen Bedarf dafür haben. Microsoft empfiehlt dies mittlerweile selbst. Die meisten Unternehmensbenutzer – einschließlich der meisten Entwickler – authentifizieren sich praktisch nie auf diese Weise. Wenn die Gerätecodeauthentifizierung tatsächlich erforderlich ist, beschränken Sie sie per Geofencing auf vertrauenswürdige Standorte. 

Was Sicherheitsteams über Gerätecode-Phishing wissen müssen

Ein staatlicher Bedrohungsakteur (STORM-2372, mit Verbindungen zu russischen Staatsinteressen) führt seit August 2024 eine Phishing-Kampagne mit Gerätecode durch, die auf Regierungsbehörden, Rüstungsunternehmen, NGOs, Telekommunikations-, Energie- und Gesundheitsorganisationen weltweit abzielt. 

Dies ist keine Schwachstelle, die Microsoft beheben kann – es handelt sich um eine Designeigenschaft des OAuth 2.0-Gerätecodeprotokolls, das von allen großen Identitätsanbietern unterstützt wird. Der Angriff umgeht MFA (Das Opfer führt den Vorgang freiwillig aus), hinterlässt keine verdächtige Infrastruktur, die von Sicherheitstools erkannt werden könnte (die einzige URL ist microsoft.com), und die resultierenden Token bleiben auch nach Passwortzurücksetzungen erhalten. Herkömmliche E-Mail-Gateways, CASBs und URL-Scanner bewerten den Angriffslink als sicher, da er is sicher – es verweist auf die Anmeldeseite von Microsoft. 

Nach der Kompromittierung wurde beobachtet, dass Angreifer innerhalb von 10 Minuten persistente Geräte registrieren, Organisationsstrukturen über Microsoft Graph abbilden, nach hochkarätigen Zielen (Finanz-, Führungs- und Verwaltungsrollen) filtern, versteckte Posteingangsregeln erstellen und Überweisungsdaten sowie Korrespondenz von Führungskräften exfiltrieren – das Rohmaterial für Business Email Compromise und Finanzbetrug. 

Die sofortige organisatorische Maßnahme: Blockieren Sie den Gerätecode-Authentifizierungsablauf über bedingten Zugriff für alle Benutzer, die ihn nicht explizit benötigen, und stellen Sie sicher, dass Ihre Vorfallreaktion Das Playbook umfasst den Widerruf von OAuth-Tokens (nicht nur Passwortzurücksetzungen) und die Bereitstellung von Token-Binding für wichtige Konten. Den vollständigen Entscheidungsrahmen finden Sie in den unten stehenden strategischen Empfehlungen.

Was passiert, wenn die Phishing-URL microsoft.com lautet?

Gerätecode-Phishing ist eine Technik zum Diebstahl von Authentifizierungstoken, die Microsofts Implementierung des OAuth-Gerätecode-Ablaufs ausnutzt. Anders als bei den meisten Phishing-Angriffen leiten Angreifer das Opfer auf eine echte Microsoft-URL – keine gefälschte Domain, keinen Reverse-Proxy und keine Tippfehler-Domain. Das Opfer meldet sich auf der echten Microsoft-Anmeldeseite an, führt die Zwei-Faktor-Authentifizierung (2FA) durch und sieht eine normale Bestätigungsseite. Die Authentifizierungstoken – eine zusätzliche Authentifizierungsmethode, die dem Opfer Berechtigungen verleiht – werden jedoch unbemerkt an den Angreifer auf einem völlig anderen Rechner übermittelt. Kein Diebstahl von Anmeldeinformationen, keine Sitzungsübernahme, keine Angreiferinfrastruktur, die erkannt oder ausgeschaltet werden könnte. Ein legitimer OAuth-Ablauf, der genau das tut, wofür er entwickelt wurde – nur eben für den falschen Akteur. 

Diese Sicherheitslücke wird heute in großem Umfang ausgenutzt – und das, obwohl der zugrundeliegende Fehler im OAuth-Standard selbst liegt. Entra IDDie Implementierung von [Name der Software] macht es so einfach, sie als Waffe einzusetzen. Microsoft schrieb dies einem [Name der Software] zu. laufende Kampagne zu STORM-2372, ein Bedrohungsakteur, der mit mittlerer Wahrscheinlichkeit als mit russischen Staatsinteressen verbunden eingestuft wird. Die Operation zielt seit mindestens August 2024 auf Regierungsbehörden, Rüstungsunternehmen, NGOs, Telekommunikationsanbieter, Energieunternehmen und Gesundheitsorganisationen auf mehreren Kontinenten ab. Im April 2026 dokumentierte Microsoft eine signifikante Eskalation: das Aufkommen von EvilTokens, einem KI-gestützten Phishing-as-a-Service (PhaaS)-Toolkit, das den Missbrauch von Gerätecode durchgängig automatisiert.– Durch die Generierung von Live-Codes auf Abruf, um das 15-minütige Ablauffenster zu umgehen, die Erstellung hochgradig personalisierter Köder mithilfe generativer KI und die Durchführung von 10 bis 15 unterschiedlichen Kampagnen alle 24 Stunden. Die Technik hat sich innerhalb eines Jahres von einer Methode staatlicher Geheimdienste zu einem allgemein verfügbaren Angriffswerkzeug entwickelt.  

In diesem Blogbeitrag erklären wir detailliert, wie dieser Angriff auf Protokollebene funktioniert, und führen eine praktische Simulation mit realen Daten durch. Entra ID Sie erfassen Protokolldateien, stellen KQL-Abfragen bereit, die Sie heute noch in Ihrer eigenen Umgebung ausführen können, und erweitern die Erkennungslogik, die sich aus den durch den Angriff generierten Protokollen ergibt. 

Wie sieht der Gerätecode-Ablauf aus?

Der in RFC 8628 definierte und im August 2019 veröffentlichte OAuth 2.0-Geräteautorisierungs-Grant ist ein Authentifizierungsverfahren für Geräte ohne Browser oder mit eingeschränkten Eingabemöglichkeiten – beispielsweise Smart-TVs, Spielekonsolen, IoT-Sensoren, Digital Signage, Konferenzraumhardware und CLI-Tools wie die Azure CLI oder AWS CloudShell. Anstatt sich direkt auf dem Gerät anzumelden, erhält der Benutzer einen kurzen alphanumerischen Code und eine URL. Er öffnet diese URL auf einem separaten Gerät (in der Regel einem Smartphone oder Laptop), gibt den Code ein und schließt die Authentifizierung dort ab – inklusive einer möglichen MFA-Abfrage. Währenddessen fragt das ursprüngliche Gerät im Hintergrund den Autorisierungsserver ab und erhält nach der Bestätigung durch den Benutzer ein Zugriffstoken. 

Dieser Ablauf wird weitgehend unterstützt: Microsoft Entra IDGoogle, GitHub, Okta und die meisten großen Identitätsanbieter implementieren es, und es ist die Standard-Anmeldemethode für die Azure CLI (`az login`). Obwohl es nicht der gängigste OAuth-Ablauf in alltäglichen Webanwendungen ist, stellt er den Standardmechanismus für Umgebungen ohne grafische Benutzeroberfläche und mit eingeschränkter Eingabe dar und wird aktiv in Unternehmensanwendungen, DevOps-Pipelines und Streaming-Plattformen für Endverbraucher eingesetzt. 

Die Konstruktionsrisiken sind dem Standard inhärent, aber Entra IDDie Implementierung verstärkt diese Effekte – weshalb jedes im Umlauf befindliche Phishing-Kit Microsoft-Produkte ins Visier nimmt. Microsoft selbst empfiehlt daher, den Datenfluss mittels bedingtem Zugriff zu blockieren, wo immer dies nicht explizit erforderlich ist. 

Der entscheidende Konstruktionsfehler: Der Gerätecode ist die einzige Verbindung zwischen dem abfragenden Gerät und dem authentifizierenden Benutzer. Microsoft überprüft nicht, ob das abfragende Gerät tatsächlich das vom Benutzer autorisierte ist. Es werden weder die Geräteidentität noch der Netzwerkstandort oder die Vertrauensstellung geprüft. Wer den Code besitzt und ihn abfragt, erhält die Token. 

Angriffsanalyse

Die Bequemlichkeit, die den Gerätecode-Ablauf so nützlich macht, ist gleichzeitig auch das, was ihn angreifbar macht. Da das Protokoll das abfragende Gerät niemals direkt mit dem authentifizierenden Benutzer verknüpft, kann ein Angreifer, der einen gültigen Gerätecode erlangt, unbemerkt die Zugriffs- und Aktualisierungstoken abgreifen, sobald sich ein Opfer anmeldet. Keine Phishing-Infrastruktur, kein Abfangen von Anmeldeinformationen, keine Umgehung der Zwei-Faktor-Authentifizierung – nur eine legitime Microsoft-Anmeldeseite, die genau das tut, wofür sie entwickelt wurde, im Auftrag des falschen Akteurs. 

Wie Angreifer diesen Datenfluss als Waffe einsetzen

Der Gerätecode-Endpunkt von Microsoft ist von Grund auf offen gestaltet – kein Clientgeheimnis, keine Geräteregistrierung, kein Besitznachweis.

Ein Angreifer sendet einen einzelnen, nicht authentifizierten POST-Request mit einer bekannten Microsoft-Client-ID (z. B. Azure CLI, Microsoft Office oder ein anderer öffentlicher Client von Microsoft – diese IDs sind öffentlich, leicht aufzählbar und für Microsoft unmöglich zu widerrufen, ohne legitime, darauf basierende Tools zu beeinträchtigen) und erhält umgehend einen gültigen Gerätecode. Diese Client-IDs von Microsoft sind ein Geschenk des Angreifers: Sie gelten standardmäßig als vertrauenswürdig, sind für weitreichende Berechtigungen vorab freigegeben und dauerhaft verfügbar. Die Mandanten-ID lässt sich leicht ermitteln, sobald ein Angreifer die Zieldomäne identifiziert hat. 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

Der Angreifer verpackt die Verifizierungs-URL und den Benutzercode in einen überzeugenden Köder – beispielsweise eine Teams-Besprechungseinladung, eine Benachrichtigung über die Freigabe eines Dokuments oder eine IT-Sicherheitswarnung – und versendet diese per E-Mail, Teams, WhatsApp, Signal oder anderen Kanälen. STORM-2372 wurde insbesondere dabei beobachtet, wie er Teams-Besprechungsbenachrichtigungen und WhatsApp-Gruppeneinladungen fälschte. Während das Opfer die E-Mail liest, führt das Skript des Angreifers bereits Abfragen durch. Sobald das Opfer die Authentifizierung abgeschlossen hat, empfängt die Abfrageschleife das vollständige Token-Paar. 

Warum bestehende Sicherheitskontrollen versagen

Das Besondere an Geräte-Code-Phishing ist die Anzahl der herkömmlichen Schutzmechanismen, die es gleichzeitig neutralisiert: 

Aus Sicht der Identitätsplattform von Microsoft handelte es sich um eine völlig legitime Anmeldung. 

• Die Multi-Faktor-Authentifizierung (MFA) wird missbraucht, nicht umgangen. Das Opfer führt die MFA normal durch. Das resultierende Token enthält mfaAuthenticated=true.
• Es gibt keine Angreiferinfrastruktur zu erkennen. Die einzige URL in der Angriffskette ist microsoft.com – sie hat in allen Threat-Intelligence-Feeds eine einwandfreie Reputation und ein gültiges EV-Zertifikat. Ihr E-Mail-Gateway, CASB, URL-Sandbox und Proxy-Safe-Link-Rewriting prüfen sie und geben „sicher“ zurück.
• Aktualisierungstoken bleiben auch nach Passwortzurücksetzungen erhalten. Im Gegensatz zu Session-Cookies (die bei AiTM-Angriffen gestohlen werden) sind OAuth-Aktualisierungstoken für den langfristigen, geräteübergreifenden Zugriff konzipiert. Sie können ohne Benutzerinteraktion oder erneute MFA-Abfrage stillschweigend gegen neue Zugriffstoken ausgetauscht werden. Das Zurücksetzen des Passworts des Opfers widerruft sie nicht – der Angreifer behält den Zugriff, solange die Token nicht explizit widerrufen werden.
• Die forensischen Spuren sind minimal. Die Anmeldeprotokolle zeigen eine erfolgreiche Anmeldung mit Risikostufe = Keine und MFA = Erfolgreich. Es gibt keine mehrfachen fehlgeschlagenen Anmeldeversuche, keine Änderungen der Anmeldeinformationen und keine Erstellung verdächtiger Objekte. Das einzige potenzielle Signal ist eine nicht-interaktive Token-Aktualisierung von einer unerwarteten IP-Adresse – und auch nur dann, wenn Sie dies gezielt überwachen. 

Wichtig: Dies ist kein Adversary-in-the-Middle-Angriff (AiTM). AiTM-Tools wie EvilProxy fangen Sitzungen über einen Reverse-Proxy ab und erfassen Cookies nach der Multi-Faktor-Authentifizierung (MFA). Dies erfordert eine vom Angreifer kontrollierte Infrastruktur – Domains, Zertifikate, aktive Server –, die forensische Spuren hinterlässt. Geräte-Phishing hingegen benötigt lediglich einen einzigen HTTP-POST-Request und eine überzeugende E-Mail. Die so gewonnenen Token sind langlebiger und haben einen größeren Anwendungsbereich als Session-Cookies, und es gibt keinerlei Angreiferinfrastruktur, die untersucht oder ausgeschaltet werden könnte.

Angreiferperspektive: Schritt-für-Schritt-Ablauf

Um die vollständige Angriffskette zu demonstrieren, haben wir sie in einer kontrollierten Laborumgebung mit einem dedizierten Forschungs-Tenant (glich.net) nachgebildet. Die Simulation modelliert einen Angreifer, der unter dem Namen helpdesk@glich.net agiert und den Benutzer roni@glich.net mit einem als Phishing-Lösegeld getarnten Gerätecode angreift. Anfrage zur Überprüfung der Anmeldeinformationen. 

Phase 1: Generierung des Gerätecodes

Der Angreifer sendet einen POST-Request an Entra IDDer Geräteautorisierungsendpunkt von Azure CLI verwendet die öffentliche Client-ID der Azure CLI, empfängt einen Gerätecode und einen Benutzercode und beginnt sofort mit dem Abfragen des Tokenendpunkts. 

Phase 2: Erstellung und Auslieferung des Phishing-Köders

Der Angreifer verpackt den Gerätecode und die URL login.microsoft.com/devicelogin in eine dringend klingende E-Mail – getarnt als Einladung zu einem Teams-Meeting, eine Anfrage zur Überprüfung der Anmeldeinformationen oder eine IT-Sicherheitswarnung. 

Phase 3: Nutzergenehmigung

Der Benutzer erhält die E-Mail und gewährt dem Angreifer Zugriff. 

Sobald das Opfer den Code und die Zugangsdaten in seinem Browser eingibt, ruft die Abfrageschleife die Token ab. 

Phase 4: Nach der Ausbeutung

Mit einem gültigen Zugriffstoken und einem langlebigen Aktualisierungstoken hat der Angreifer den Zugriff auf die Microsoft 365-Umgebung des Opfers authentifiziert – und die Zeit drängt. Analyse vom 2026. April Eine Analyse einer KI-gestützten Phishing-Kampagne mit Gerätecode (eine direkte Weiterentwicklung der erstmals im Februar 2025 gemeldeten STORM-2372-Aktivität) dokumentierte die Vorgehensweise von Angreifern nach der Kompromittierung. Der Ablauf folgt einem einheitlichen Muster: 

Geräteregistrierung für Persistenz 

In einigen Fällen registrierten Angreifer innerhalb von zehn Minuten nach dem ersten Sicherheitsvorfall neue Geräte unter dem kompromittierten Konto, um ein primäres Aktualisierungstoken (PRT) zu generieren. Ein PRT ermöglicht langfristigen, SSO-fähigen Zugriff, der auch nach dem Widerruf einzelner Token erhalten bleibt. Dadurch verschafft er dem Angreifer einen dauerhaften Zugriff, der deutlich schwieriger zu erkennen und zu beheben ist als ein gestohlenes Aktualisierungstoken allein. 

Microsoft Graph Reconnaissance 

Mithilfe der gestohlenen Tokens fragten die Angreifer die Microsoft Graph API ab, um programmgesteuert interne Organisationsstrukturen, Benutzerrollen und Berechtigungszuweisungen abzubilden. Diese automatisierte Aufklärung ermöglichte es ihnen, schnell zu identifizieren, welche kompromittierten Konten Zugriff auf sensible Ressourcen hatten und wo diese gespeichert waren. Privilege-Escalation-Angriffe war möglich. 

Filterung von hochwertigen Zielen 

Anstatt jedes kompromittierte Konto wahllos auszunutzen, filterten die Angreifer die Opfer nach besonders wertvollen Personen – insbesondere nach Personen in Finanz-, Führungs- oder Verwaltungspositionen. Dieser selektive Ansatz konzentrierte die aufwändigsten Maßnahmen nach der Kompromittierung auf Konten mit dem höchsten potenziellen Gewinn. 

Regeln für schädliche E-Mails zur Verhinderung von Persistenz 

Für ausgewählte Ziele erstellten die Angreifer mithilfe der Microsoft Office-Anwendung Posteingangsregeln, um eingehende E-Mails umzuleiten, auszublenden oder zu löschen. Diese Regeln dienten einem doppelten Zweck: dem dauerhaften Zugriff auf die E-Mail-Kommunikation ohne wiederholte Anmeldungen und der Verschleierung der Beweise für die Kompromittierung vor dem Opfer (z. B. durch automatisches Löschen von Sicherheitswarnungen oder Benachrichtigungen zum Zurücksetzen von Passwörtern). 

Gezielte E-Mail-Exfiltration 

Die einschneidendsten Aktivitäten waren Nutzern mit Finanzverantwortung vorbehalten. Die Angreifer durchsuchten E-Mail-Kommunikation eingehend und zielten dabei insbesondere auf Überweisungsdaten, offene Rechnungen und Korrespondenz von Führungskräften ab – das Rohmaterial für Business Email Compromise (BEC) und Finanzbetrug. 

Verzögerte Ausführung zur Umgehung der Erkennung 

Nicht alle Angreifer reagierten sofort. In mehreren beobachteten Fällen warteten sie nach dem ersten Zugriff stundenlang, bevor sie weitere Maßnahmen ergriffen – eine bewusste Ausweichtechnik, um das verdächtige Authentifizierungsereignis von der schädlichen Aktivität in den Protokollen zu trennen und so die zeitliche Korrelation für die Verteidiger zu erschweren. Bis die schädliche Aktivität beginnt, ist das zugrundeliegende Authentifizierungsereignis bereits aus den kurzfristigen Prüfwarteschlangen und Echtzeit-Warnfenstern verschwunden. Verteidiger, die eine verdächtige Anmeldung zum Zeitpunkt T+0 überprüfen, finden möglicherweise keine Folgeaktivitäten und schließen sie als harmlos ein – nur um Stunden später festzustellen, dass der Angreifer mit der Datenexfiltration beginnt, wenn die ursprüngliche Warnung nicht mehr angezeigt wird. Diese bewusste Verzögerung zwischen Zugriff und Aktion macht Phishing-Angriffe auf Gerätecode besonders resistent gegen zeitbasierte Erkennung: Der Sicherheitsvorfall und seine Auswirkungen treten nie im selben Untersuchungszeitraum auf, es sei denn, die Verteidiger korrelieren explizit über längere Zeiträume hinweg. 

Verteidigerperspektive: Worauf wir in den Protokollen achten sollten.

Für Bedrohungsjäger und SOC-Analysten – real Entra ID Protokollaufzeichnungen, die genau zeigen, wonach zu suchen ist. 

Wir haben Entra ID Die durch diesen Ablauf generierten Anmeldeprotokolleinträge. Die Abfrageanfragen des Angreifers – die wiederholten authorization_pending-Antworten – werden überhaupt nicht protokolliert. Nur die erfolgreiche Token-Ausstellung erzeugt Einträge, die auf zwei Registerkarten verteilt sind: 

Eintrag 1: Interaktiv (Browser-/Opferseite)

Das Opfer besuchte microsoft.com/devicelogin und bestätigte den Code. Die Zwei-Faktor-Authentifizierung war durch eine vorherige Sitzungsbestätigung erfüllt – das Opfer bemerkte keinerlei weitere Probleme nach dem Klicken auf „Genehmigen“. 

Eintrag 2: Nicht interaktiv (Abfrage auf Client-/Angreiferseite)

Nebeneinander Vergleich

Das Erkennungsprinzip ist eindeutig: Beide Einträge teilen sich eine Korrelations-ID, aber der User-Agent und möglicherweise die IP-Adresse unterscheiden sich. Der Browsereintrag zeigt Chrome auf einem Mac an, der Abfrageeintrag curl. Bei einem realen Angriff ist dieses Logpaar mit diesen Unterschieden – insbesondere eine geografische Aufteilung, die auf eine möglicherweise unmögliche Reise oder eine verdächtige Quelle hindeutet – das zentrale Signal für die Alarmierung. 

Die Anreicherung der Abfrage-IP-Adresse mit Bedrohungsdaten, IP-Reputationslisten, verdächtigen User-Agent-Werten (wie beispielsweise „curl“ in den Protokollen) und ASN-Metadaten verbessert die Erkennung zusätzlich: Angreiferinfrastrukturen stammen häufig von Hosting-Anbietern, kommerziellen VPNs oder ASNs, die in Ihrer Nutzerpopulation keine legitime Präsenz aufweisen. Eine Abfrage-IP-Adresse, die zu einer als schädlich bekannten ASN aufgelöst wird oder auf einer Blacklist erscheint, ist selbst ohne IP-Diskrepanz zwischen den Verbindungen ein starker Indikator.

Erkennung von Gerätecode-Phishing in Ihrer Umgebung

Für Bedrohungsanalysten: Kopieren Sie KQL-Abfragen für Azure Monitor, Microsoft Sentinel oder ein beliebiges KQL-kompatibles SIEM-System. 

Die folgenden KQL-Abfragen können verwendet werden, um nach Phishing-Aktivitäten mit Gerätecode in Ihrem System zu suchen. Entra ID Anmeldeprotokolle. Diese sind so konzipiert, dass sie direkt in Azure Monitor, Microsoft Sentinel oder jedes KQL-kompatible SIEM-System kopiert und eingefügt werden können. 

Ziel ist es, den Missbrauch von Gerätecode so zeitnah wie möglich nach dem Ereignis (T+0) zu erkennen. Jede der folgenden Abfragen zielt auf ein anderes Signal ab: ungewöhnliche Nutzungsmuster von Gerätecode, IP- oder User-Agent-Inkompatibilitäten zwischen interaktiven und abfragenden Daten sowie die Generierung großer Codemengen, die auf eine aktive Kampagne hindeuten könnten. 

1. Alle Gerätecode-Ablaufereignisse für die Korrelationsanalyse aufzeigen.

Diese Abfrage ruft beide Teile (interaktiv und nicht-interaktiv) jedes Geräte-Code-Flows ab. Sortieren oder verknüpfen Sie die Daten anhand der CorrelationId, um sie nebeneinander zu vergleichen und nach IP- oder User-Agent-Diskrepanzen zu suchen – dem wichtigsten Erkennungssignal. 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. Erkennen von Gerätecodeflüssen mit IP-Adressabweichungen zwischen den Beinen

Diese Abfrage verknüpft die interaktiven und nicht-interaktiven Einträge jedes Gerätecode-Flows anhand der CorrelationId und kennzeichnet Flows, bei denen die IP-Adressen abweichen – ein starkes Indiz dafür, dass der abfragende Client nicht dasselbe Gerät oder denselben Standort wie der authentifizierende Browser verwendet. Für präzisere Warnmeldungen sollte die abfragende IP-Adresse mit ASN-Lookups und Threat-Intelligence-Feeds angereichert werden. So sollten Flows gekennzeichnet werden, deren abfragende IP-Adresse zu einem Hosting-Anbieter, einem kommerziellen VPN oder einem gesperrten Adressbereich gehört, selbst wenn sich die IP-Adressen im selben Land befinden. 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. Überwachung der Generierung von Gerätecode in großem Umfang durch eine einzelne Anwendung

Ein Angreifer, der eine Phishing-Kampagne mit Gerätecode durchführt, generiert innerhalb kurzer Zeit zahlreiche Codes. Diese Abfrage zeigt Anwendungen an, die in den letzten 24 Stunden eine ungewöhnlich hohe Anzahl von Gerätecode-Abläufen über verschiedene Benutzer hinweg aufweisen. 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

Passen Sie die Schwellenwerte und Zeitfenster an die Basiswerte Ihrer Umgebung an. Organisationen, die Gerätecode-Flows legitim verwenden (z. B. für die Azure CLI oder das Onboarding von IoT-Geräten), sollten eine Liste bekanntermaßen gültiger Client-IDs erstellen und diese ausschließen. 

Ein verdächtiges Logpaar wurde gefunden – was nun?

Nicht jeder erfolgreiche Gerätecode-Flow mit einem User-Agent-Mismatch ist böswillig – es gibt legitime Szenarien (z. B. ein Entwickler, der sich auf einem Remote-Server mit `az login` anmeldet und sich von seinem Laptop aus authentifiziert). Untersuchen Sie den Fall, bevor Sie ihn eskalieren. Weist das Logpaar jedoch Merkmale von Missbrauch auf – eine unbekannte Polling-IP, eine ASN des Hosting-Anbieters, ein Benutzer, der den Gerätecode-Flow nicht initiiert hat –, behandeln Sie dies als bestätigten Token-Diebstahl und führen Sie unverzüglich die folgenden Schritte aus: 

1. Alle Aktualisierungstoken sofort widerrufen. 

Entziehen Sie dem Benutzer unverzüglich den Zugriff (siehe Microsofts DokumentationDeaktivieren Sie den kompromittierten Benutzer und entfernen Sie seine Rollenzuweisungen. Dadurch werden alle aktiven Aktualisierungstoken ungültig und der Angreifer kann nicht mehr unbemerkt neue Zugriffstoken erlangen. Führen Sie diese Schritte vor dem Zurücksetzen des Passworts durch – ein alleiniges Zurücksetzen des Passworts widerruft keine OAuth-Aktualisierungstoken. 

2. Beenden Sie aktive Sitzungen 

Das Widerrufen von Aktualisierungstoken führt nicht zur Ungültigkeit bereits ausgestellter Zugriffstoken – diese bleiben bis zu ihrem Ablaufdatum gültig. Wenn Ihr Mandant Continuous Access Evaluation (CAE) verwendet, erzwingen Sie eine erneute Auswertung aller aktiven Sitzungen des Benutzers, um zwischengespeicherte Token zu löschen. Bei Workloads ohne CAE widerrufen Sie die Sitzungen des Benutzers in Entra ID (Benutzer → Sitzungen widerrufen), um alle zwischengespeicherten Token in den Microsoft 365-Diensten ungültig zu machen. 

3. Überprüfung auf Persistenzmechanismen 

Suchen Sie nach neu registrierten Geräten, Posteingangsregeln, OAuth-App-Zustimmungen und allen anderen Aktionen, die in derselben Sitzung durchgeführt wurden. Achten Sie besonders auf Geräteregistrierungen (die primäre Aktualisierungstoken generieren), Posteingangsregeln, die E-Mails weiterleiten, umleiten oder löschen, sowie auf Änderungen der Authentifizierungsmethoden (z. B. eine neue Telefonnummer für die Multi-Faktor-Authentifizierung). Der Token-Widerruf allein reicht nicht aus – der Angreifer könnte bereits dauerhaften Zugriff erlangt haben; entfernen Sie alles, was der Benutzer nicht erkennt. 

4. Enthalten lateraler Bewegung ausnutzen 

Wenn der kompromittierte Benutzer über privilegierte Rollen (Globaler Administrator, Exchange-Administrator usw.) verfügt oder Zugriff auf sensible Ressourcen hat, schränken Sie das Konto während der Untersuchung über bedingten Zugriff ein. Prüfen Sie, ob der Angreifer die gestohlenen Token für den Zugriff auf SharePoint-, Teams- oder Azure-Ressourcen verwendet hat – das einheitliche Überwachungsprotokoll und die Microsoft Graph-Aktivitätsprotokolle zeigen den Umfang des Zugriffs an. 

5. Beweismittel sichern und das SOC benachrichtigen. 

Exportieren Sie die relevanten Anmeldeprotokolleinträge (interaktive und nicht-interaktive, verknüpft über die Korrelations-ID), die letzten Aktivitäten des Benutzers im Audit-Protokoll sowie alle entfernten Posteingangsregeln und Geräteregistrierungen. Diese Daten sind entscheidend für die Bestimmung des Ausmaßes des Vorfalls und für alle nachfolgenden Meldepflichten.

Empfehlungen und Best Practices

Strategische Empfehlungen

Für Führungskräfte und Sicherheitsverantwortliche – die wichtigsten politischen Entscheidungen. 

• Blockieren Sie die Geräte-Code-Authentifizierung für alle Benutzer, die diese nicht explizit benötigen. Diese Änderung der Richtlinie für bedingten Zugriff eliminiert die Angriffsfläche für den Großteil Ihrer Mitarbeiter vollständig.
• Aktualisieren Sie Ihren Notfallplan, um die Widerrufung von OAuth-Token als obligatorischen Schritt neben dem Zurücksetzen von Passwörtern aufzunehmen. Ein Zurücksetzen des Passworts allein widerruft keine Aktualisierungstoken – der Angreifer behält unbegrenzt Zugriff, solange die Token nicht explizit widerrufen werden.
• Priorisieren Sie die Tokenbindung (Tokenschutz) für besonders wichtige Konten – Führungskräfte, Finanzabteilung, Administratoren. Diese Funktion ist allgemein unter Windows verfügbar (Vorschau für iOS/macOS) und bietet den stärksten umfassenden Schutz gegen Token-Replay durch gestohlenen Gerätecode.
• Prüfen Sie, welche Anwendungen in Ihrem Tenant den Gerätecode-Flow aktiviert haben. Viele Organisationen verwenden OAuth-Apps mit Gerätecode-Berechtigungen, die nie absichtlich konfiguriert wurden. Eine Reduzierung der Angriffsfläche ist ein schneller Erfolg.
• Stellen Sie sicher, dass Ihr Sicherheitsteam nicht nur interaktive, sondern auch nicht-interaktive Anmeldeprotokolle überwacht. Die Token-Aktualisierungsaktivitäten des Angreifers erscheinen ausschließlich in nicht-interaktiven Protokollen, die viele SOCs nicht routinemäßig überprüfen.

Taktische Empfehlungen

Für Sicherheitsingenieure und Administratoren – Leitfaden für die Implementierung: 

Den Gerätecodefluss über bedingten Zugriff einschränken oder blockieren

Wenn Ihre Organisation für legitime Anwendungsfälle (CLI-Tools, IoT-Geräte, Konferenzraumhardware) nicht auf die Gerätecodeauthentifizierung angewiesen ist, blockieren Sie den Datenfluss vollständig mithilfe von Richtlinien für bedingten Zugriff. Entra IDErstellen Sie eine Richtlinie, die auf alle Benutzer → Zielressourcen → Alle Ressourcen (ehemals Cloud-Apps) → Bedingungen → Authentifizierungsabläufe → Gerätecode-Ablauf = Blockieren abzielt. Falls einige Teams dies benötigen, beschränken Sie die Zulassungsrichtlinie auf bestimmte Benutzer oder Gruppen und bekannte Geräteplattformen, wobei die folgenden Punkte zu beachten sind: Prinzip des geringsten Privilegs. 

Weisen Sie geeignete Maßnahmen zur Eindämmung des Token-Diebstahls an.

Passwortzurücksetzungen allein widerrufen keine OAuth-Aktualisierungstoken. Ihre Maßnahmen bei einem kompromittierten Konto müssen Folgendes umfassen: (1) Entzug des Benutzerzugriffs und Deaktivierung des Kontos, (2) erneute Überprüfung aller aktiven CAE-Sitzungen (Continuous Access Evaluation) und (3) Überprüfung der OAuth-App-Zustimmungen des Benutzers und Entfernung aller unbekannten Dienstprinzipale. Ohne diese Schritte behält der Angreifer den Zugriff über das Aktualisierungstoken, bis dieses abläuft – standardmäßig bis zu 90 Tage. Entra ID Konfiguration. 

Überwachen Sie nicht-interaktive Anmeldeprotokolle auf geografische Anomalien.

Die nicht-interaktive Anmelde-Registerkarte in Entra ID Hier treten Token-Aktualisierungsereignisse auf. Ein Angreifer, der ein gestohlenes Aktualisierungstoken verwendet, generiert nicht-interaktive Anmeldungen von einer IP-Adresse und einem User-Agent, die sich höchstwahrscheinlich von den Standardeinstellungen des Benutzers unterscheiden. Richten Sie Benachrichtigungen für nicht-interaktive Anmeldungen ein, deren Quell-IP-Adresse sich in einem anderen Land oder ASN befindet als die letzte interaktive Anmeldung des Benutzers. Überprüfen Sie die Quell-IP-Adresse zusätzlich anhand von Bedrohungsdaten und IP-Reputationsdatenbanken. Abfrage- oder Aktualisierungsaktivitäten von IP-Adressen auf Blacklists, bekannten Bulletproof-Hosting-Anbietern oder Residential-Proxy-Netzwerken sind unabhängig vom Standort ein starker Indikator. Diese Kombination aus geografischen und Anomalieerkennung Die reputationsbasierte Filterung ist das früheste und zuverlässigste Signal für den Diebstahl von Gerätecode-Tokens. 

Wie man sich vor Phishing-Angriffen auf Gerätecode schützt

Geräte-Code-Phishing stellt eine grundlegende Veränderung in der Bedrohungslandschaft für Identitätsdiebstahl dar – eine Bedrohung, bei der der Angreifer keine Infrastruktur benötigt, die Multi-Faktor-Authentifizierung (MFA) missbraucht statt umgangen wird und der Zugriff auch nach Passwortzurücksetzungen bestehen bleibt. Der Angriff funktioniert gerade deshalb, weil er legitim wirkt: eine echte Microsoft-Anmeldeseite, eine echte MFA-Abfrage, eine echte Erfolgsmeldung. Die Tokens gelangen nur auf den falschen Rechner. 

Die strategische Antwort ist einfach: Blockieren Sie den Gerätecodefluss, wo er nicht benötigt wird, stellen Sie sicher, dass Ihre Incident-Response-Playbooks die Token-Sperrung beinhalten, und überwachen Sie die nicht-interaktiven Anmeldeprotokolle, die die meisten Unternehmen übersehen. Die detaillierte technische Analyse in diesem Beitrag – von der Protokollanalyse über die Protokollerfassung bis hin zu KQL-Abfragen – bietet Ihrem Sicherheitsteam alles, was es benötigt, um diese Aktivitäten sofort aufzuspüren. 

Da sich OAuth-basierte Identitätsangriffe ständig weiterentwickeln, wird die Kluft zwischen dem, was herkömmliche Perimeter-Tools erfassen können, und den Vorgängen auf der Identitätsebene immer größer. Organisationen, die in Protokollebenen-Sicherheit investieren, sollten daher frühzeitig mit der Entwicklung von Sicherheitslösungen beginnen. Erkennung und ReaktionNicht nur Endpunkt- und Netzwerküberwachung – sondern diejenigen, die die nächste Entwicklungsstufe dieser Technik erkennen, bevor sie die Phase nach der Ausnutzung erreicht, werden die nächsten Schritte unternehmen. 

SilverfortDas Forschungsteam von [Name des Unternehmens] verfolgt weiterhin die Entwicklung von OAuth-basierten Angriffstechniken.