Device-Code-Phishing: MFA bestanden, Konto trotzdem weg

/01Was Device-Code-Phishing ist — und was nicht

Device-Code-Phishing missbraucht eine legitime Anmeldeart von Microsoft Entra ID: den Gerätecode-Fluss (Device Code Flow, im OAuth-2.0-Standard „Device Authorization Grant"). Sperren lässt er sich mit einer einzigen Regel in Conditional Access, die den Fluss für alle Konten blockiert, die ihn nicht nachweislich brauchen.

Gedacht ist der Fluss für Geräte ohne vernünftige Tastatur: Konferenzraumsysteme, Smart-TVs, Drucker, Kommandozeilenwerkzeuge. Das Gerät zeigt einen kurzen Code an, der Nutzer öffnet auf dem Handy oder Laptop microsoft.com/devicelogin, tippt den Code ein und meldet sich an. Das Gerät fragt im Hintergrund so lange bei Microsoft nach, bis die Anmeldung erledigt ist, und bekommt dann die Tokens.

Der Angriff dreht die Rollen um. Der Angreifer startet den Fluss auf seiner eigenen Maschine, erhält einen Code und schickt ihn dem Opfer – getarnt als Besprechungs-ID, als Freigabe für ein geteiltes Dokument oder als Sicherheitsprüfung. Das Opfer gibt den Code auf der echten Microsoft-Seite ein, erfüllt die Multi-Faktor-Authentifizierung und landet danach auf einer harmlosen Seite. Die Tokens gehen an das „Gerät", das den Code angefordert hat: das des Angreifers.

Abgrenzung

• Kein klassisches Phishing mit gefälschter Anmeldeseite. Es wird kein Passwort abgegriffen; die Seite, auf der das Opfer sich anmeldet, ist echt. Filter, die nach nachgemachten Microsoft-Seiten suchen, greifen deshalb ins Leere.
• Kein Adversary-in-the-Middle-Angriff. Bei AiTM sitzt ein Proxy zwischen Opfer und Microsoft und fängt das Sitzungs-Cookie ab. Beim Device-Code-Phishing gibt es keinen Proxy; Microsoft stellt die Tokens selbst aus, nur eben an den Falschen.
• Kein Fehler in Entra ID. Der Fluss funktioniert wie spezifiziert. Das Problem ist, dass ein Merkmal, das kaum ein Unternehmen braucht, in den meisten Tenants für alle Konten offen steht.

/02Warum MFA und Passkeys hier nicht schützen

Die unbequeme Nachricht für alle, die in den letzten Jahren MFA und Passkeys sauber eingeführt haben: Gegen diesen Angriff ändern sie nichts. Phishing-resistente Verfahren wie FIDO2 binden die Anmeldung an die Adresse der Seite. Die Adresse stimmt hier aber – das Opfer ist tatsächlich bei Microsoft. Auch die Forscher von ERNW halten in ihrer Analyse zum Tokendiebstahl in Entra ID fest, dass der Angriff phishing-resistente MFA umgeht, weil er den Autorisierungsfluss missbraucht und nicht die Anmeldung selbst.

Das heißt nicht, dass MFA überflüssig wäre. Microsoft empfiehlt in denselben Beiträgen weiterhin phishing-resistente Verfahren, weil sie gegen die meisten anderen Angriffe wirken. Es heißt nur: Wer seine Abwehr allein auf die zweite Anmeldestufe stützt, hat diese Lücke offen. Device-Code-Phishing ist ein Fall für die Frage „Welche Anmeldewege lassen wir überhaupt zu?" – also für Zero-Trust-Regeln, nicht für Authentifizierungsmethoden.

Auch die Schulung stößt an Grenzen. Die üblichen Hinweise – Adresszeile prüfen, keine Passwörter auf unbekannten Seiten eingeben – passen hier nicht. Was Mitarbeiter lernen können, ist eine einzige Regel: Microsoft fordert niemanden per Mail, Chat oder Telefon auf, einen Code auf microsoft.com/devicelogin einzugeben. Wer das nicht selbst an einem Konferenzgerät gestartet hat, gibt keinen Code ein. Wie weit solche Regeln in der Praxis tragen und was eine Klickrate darüber aussagt, haben wir in Phishing-Simulation: Was die Klickrate nicht misst beschrieben.

/03Die Lage 2026: Storm-2372, EvilTokens und KI-Köder

Device-Code-Phishing ist keine neue Technik, aber 2026 ist es vom Spezialwerkzeug staatlicher Gruppen zum Massenprodukt geworden. Drei Etappen, alle von Microsoft selbst dokumentiert:

Das Geschäftsmodell erklärt die Verbreitung: Laut Microsoft kostet der Einstieg in EvilTokens 1.500 US-Dollar, danach 500 US-Dollar Abo, mit fertigen Vorlagen und Telegram-Benachrichtigung, sobald im erbeuteten Postfach ein Stichwort wie „Rechnung" auftaucht. Die Abschaltung im September hat die Infrastruktur getroffen, nicht die Technik. Wer das Kit gekauft hat, kennt den Ablauf; Nachahmer brauchen nur einen Webspace und eine Liste von Adressen.

Was nach dem Einbruch passiert

Microsoft beschreibt in den Berichten vom April und September ein wiederkehrendes Muster. Manche Täter registrierten binnen zehn Minuten ein eigenes Gerät, um ein langlebiges Primary Refresh Token zu bekommen. Andere warteten Stunden, legten dann Posteingangsregeln an, die Antworten ausblenden, und durchsuchten das Postfach nach Überweisungen, Rechnungen und Mails der Geschäftsführung. Für den Mittelstand ist das der eigentliche Schaden: kein verschlüsselter Server, sondern eine geänderte Bankverbindung in einer Rechnung, die echt aussieht, weil sie aus einem echten Postfach kommt.

Die von Microsoft genannten Branchen – Großhandel, Bau, Finanzdienstleister, Immobilien, Hochschulen, Gesundheitswesen – sind keine exotischen Ziele. Deutschland taucht in der Liste der Länder mit den meisten Opfern nicht auf; daraus Entwarnung abzuleiten, wäre bei einem Kit, das jeder kaufen kann, leichtsinnig.

/04Bestandsaufnahme: Wer nutzt den Gerätecode-Fluss?

Bevor Sie sperren, sollten Sie wissen, wer den Fluss heute legitim nutzt. Microsoft schreibt selbst, der Fluss werde von Kunden selten, von Angreifern aber häufig genutzt. Unser Erfahrungswert aus Tenants mit 40 bis 300 Arbeitsplätzen, keine Studienlage: Nach der Auswertung bleibt eine Handvoll Konten übrig – Teams-Raumsysteme, ein oder zwei Administratoren mit Kommandozeilenwerkzeugen, gelegentlich ein Altgerät. Dass das so ist, sagt Ihnen allerdings nur die Messung im eigenen Tenant.

Im Entra Admin Center

Unter Entra ID › Monitoring & health › Sign-in logs den Filter Authentication Protocol hinzufügen und auf Device code setzen. Der Zeitraum ist begrenzt: Entra ID speichert Anmeldeprotokolle mit P1 oder P2 30 Tage, in der kostenlosen Stufe nur sieben.

Per Microsoft Graph PowerShell

Für eine Liste, die sich ablegen und vergleichen lässt, eignet sich das Graph-SDK. Die Eigenschaften authenticationProtocol und originalTransferMethod stehen in der Beta-Schnittstelle; das Herunterladen der Anmeldeprotokolle über Graph setzt Entra ID P1 oder P2 voraus.

# einmalig: Install-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

$seit = (Get-Date).ToUniversalTime().AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
$anm  = Get-MgBetaAuditLogSignIn -Filter "createdDateTime ge $seit" -All

$dc = $anm | Where-Object {
    $_.AuthenticationProtocol -eq 'deviceCode' -or
    $_.OriginalTransferMethod -eq 'deviceCodeFlow'
}

$dc | Group-Object UserPrincipalName, AppDisplayName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Detail je Konto: wann, von wo, mit welchem Ergebnis
$dc | Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName,
    IpAddress, @{n='Land';e={$_.Location.CountryOrRegion}},
    @{n='Fehler';e={$_.Status.ErrorCode}} |
    Sort-Object CreatedDateTime | Format-Table -AutoSize

Ohne Filter auf den Ereignistyp liefert die Schnittstelle nur interaktive Anmeldungen. Das reicht für die Frage „Wer hat den Fluss angestoßen?", weil die Code-Eingabe interaktiv ist. Bei großen Tenants dauert -All über 30 Tage spürbar; dann den Zeitraum in Wochenscheiben abfragen.

Eine Beispielausgabe, wie sie typischerweise aussieht (Namen geändert):

Count Name
----- ----
   14 raum-og2@firma.de, Microsoft Teams Rooms
    6 admin-mk@firma.de, Microsoft Azure CLI
    1 s.becker@firma.de, Microsoft Authentication Broker

Deutung: Das Raumkonto ist erwartbar und kommt auf die Ausnahmeliste. Der Administrator mit Azure CLI ist eine Gewohnheit, die sich ändern lässt (siehe /06). Die einzelne Zeile der Sachbearbeiterin mit dem Authentication Broker ist der Fall, den Sie sofort ansehen: IP-Adresse, Land, Uhrzeit, und ob danach ein neues Gerät registriert wurde. Genau diese Kombination beschreibt Microsoft bei Storm-2372.

Mit Log Analytics oder Sentinel

Wer die Entra-Protokolle per Diagnoseeinstellung in einen Log-Analytics-Arbeitsbereich oder ein SIEM schreibt, hat längere Aufbewahrung und kann dauerhaft alarmieren:

SigninLogs
| where TimeGenerated > ago(90d)
| where AuthenticationProtocol == "deviceCode"
     or OriginalTransferMethod == "deviceCodeFlow"
| summarize Anzahl = count(),
            Erste = min(TimeGenerated), Letzte = max(TimeGenerated),
            IPs = make_set(IPAddress, 10), Laender = make_set(Location, 10)
  by UserPrincipalName, AppDisplayName, ResultType
| order by Anzahl desc

ResultType 0 bedeutet erfolgreiche Anmeldung, alles andere ist ein Fehlercode. Ein erfolgreicher Gerätecode-Eintrag bei einem Konto, das nicht auf Ihrer Ausnahmeliste steht, ist nach der Sperre ein Alarm, den ein SOC nachts genauso ernst nehmen sollte wie tagsüber.

/05Die Sperrregel in Conditional Access

Microsoft empfiehlt ausdrücklich, den Gerätecode-Fluss „wherever possible" zu blockieren, und beschreibt die Regel in der eigenen Dokumentation. Vorher lohnt ein Blick in die Richtlinienliste: Microsoft rollt eine verwaltete Richtlinie „Block device code flow" aus, die in berechtigten Tenants im Report-only-Modus angelegt und frühestens 30 Tage später scharf geschaltet wird, angekündigt zwei Wochen vorher. Steht dort in der Spalte „Created by" bereits Microsoft, entscheiden Sie bewusst, ob Sie diese Richtlinie nutzen oder eine eigene mit Ihren Ausnahmen.

Im Portal

1. Als mindestens Conditional Access Administrator im Entra Admin Center anmelden, Entra ID › Conditional Access › Policies › New policy.
2. Name nach Ihrem Schema, etwa CA-BLOCK-DeviceCodeFlow.
3. Users › Include: All users. Exclude: die Notfallkonten und eine Gruppe CA-Ausnahme-DeviceCode.
4. Target resources › Include: All resources. Exclude: Device Registration Service – sonst scheitert die Registrierung von Teams-Geräten.
5. Conditions › Authentication flows: Configure auf Yes, Device code flow auswählen.
6. Grant: Block access.
7. Enable policy: Report-only. Nach ein bis zwei Wochen Auswertung auf On.

Per Graph, reproduzierbar

Für Dokumentation und mehrere Tenants ist die Regel als Code besser aufgehoben als als Klickfolge. Die Client-ID des Device Registration Service nennt Microsoft in der Dokumentation zu den Authentication Flows.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"

$ausnahme = (Get-MgGroup -Filter "displayName eq 'CA-Ausnahme-DeviceCode'").Id
$notfall  = (Get-MgGroup -Filter "displayName eq 'CA-Notfallkonten'").Id

$regel = @{
  displayName = "CA-BLOCK-DeviceCodeFlow"
  state       = "enabledForReportingButNotEnforced"   # Report-only
  conditions  = @{
    users = @{ includeUsers = @("All"); excludeGroups = @($ausnahme, $notfall) }
    applications = @{
      includeApplications = @("All")
      excludeApplications = @("01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9") # Device Registration Service
    }
    clientAppTypes      = @("all")
    authenticationFlows = @{ transferMethods = "deviceCodeFlow" }
  }
  grantControls = @{ operator = "OR"; builtInControls = @("block") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $regel

Den Report-only-Zeitraum werten Sie über die Registerkarte Policy impact der Richtlinie oder im Anmeldeprotokoll unter Conditional Access › Report-only aus. Jede Zeile „Report-only: Failure" ist eine Anmeldung, die nach dem Scharfschalten gesperrt würde – also entweder ein Kandidat für die Ausnahmegruppe oder genau das, was Sie verhindern wollen.

/06Ausnahmen für Teams Rooms, Azure CLI und Altgeräte

Ausnahmen sind der Teil, an dem die Regel in der Praxis scheitert – nicht technisch, sondern weil die Liste nach einem Jahr niemand mehr kennt. Microsoft gibt für Teams-Geräte eine klare Linie vor: Standard ist die Sperre, Ausnahmen gibt es nur für die Ressourcenkonten der Geräte, und der Device Registration Service bleibt ausgenommen.

Der wichtigste Satz steht in Microsofts Anleitung für Teams-Geräte: Eine Ausnahme ist an das Konto gebunden, es gibt keinen Weg, sie auf eine Ressource oder ein Szenario zu begrenzen. Ein ausgenommenes Konto kann den Gerätecode-Fluss für jede App nutzen. Darum gehört kein normales Nutzerkonto in die Gruppe der Raumsysteme – auch nicht „nur kurz zum Einrichten".

Ausnahmegruppe regelmäßig prüfen

$g = Get-MgGroup -Filter "displayName eq 'CA-Ausnahme-DeviceCode'"
Get-MgGroupMember -GroupId $g.Id -All |
  ForEach-Object { $_.AdditionalProperties.userPrincipalName }

Diese Liste gehört in die vierteljährliche Rechteprüfung, zusammen mit den Mitgliedern privilegierter Rollen (Privileged Access Management). Ein Konto, das dort steht, aber in 90 Tagen keine Gerätecode-Anmeldung hatte, fliegt raus. Administratoren, die den Fluss für Kommandozeilenwerkzeuge brauchten, bekommen statt einer Dauerausnahme die Browser-Anmeldung und – wo Sie das ohnehin planen – zeitlich begrenzte Rollen per Just-in-Time-Zugriff.

/07Verdacht auf Device-Code-Phishing: die ersten Schritte

Ein Mitarbeiter meldet: „Ich habe heute früh einen Code für eine Teams-Besprechung eingegeben, danach kam nichts." Oder die Abfrage aus /04 zeigt eine Gerätecode-Anmeldung, die niemand erklären kann. Dann zählt die Reihenfolge, und die ist in einem Runbook besser aufgehoben als im Gedächtnis.

1. Konto sperren, nicht nur Sitzungen widerrufen. Microsoft weist darauf hin, dass der Widerruf meist nur Refresh Tokens ungültig macht; bereits ausgestellte Access Tokens bleiben bis zu eine Stunde nutzbar.
2. Sitzungen widerrufen – danach, nicht stattdessen.
3. Neu registrierte Geräte des Kontos prüfen und entfernen. Ein vom Angreifer registriertes Gerät mit Primary Refresh Token überlebt sonst den Passwortwechsel.
4. Posteingangsregeln und Weiterleitungen prüfen. Typisch sind Regeln, die Antworten verschieben oder löschen; Microsoft beschreibt auch Regelnamen nur aus Sonderzeichen.
5. Gesendete Mails und Kontakte prüfen. Storm-2372 verschickte aus übernommenen Postfächern weitere Gerätecode-Köder an Kollegen und Partner.
6. Buchhaltung warnen. Laufende Zahlungen mit geänderter Bankverbindung telefonisch über eine bekannte Nummer bestätigen lassen.

$upn = "s.becker@firma.de"

# 1 + 2: sperren, dann Sitzungen widerrufen
Update-MgUser -UserId $upn -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $upn

# 3: registrierte Geräte mit Datum
Get-MgUserRegisteredDevice -UserId $upn -All | ForEach-Object {
  [pscustomobject]@{
    Name        = $_.AdditionalProperties.displayName
    System      = $_.AdditionalProperties.operatingSystem
    Registriert = $_.AdditionalProperties.registrationDateTime
  }
}

# 4: Posteingangsregeln (Exchange Online PowerShell)
Connect-ExchangeOnline
Get-InboxRule -Mailbox $upn |
  Select-Object Name, Enabled, MoveToFolder, DeleteMessage, ForwardTo, RedirectTo

Das Konto wird erst wieder freigegeben, wenn Geräte, Regeln und Weiterleitungen bereinigt sind und die Sperrregel aus /05 aktiv ist – sonst wiederholt sich das Spiel mit dem nächsten Code. Den größeren Rahmen, wer im Ernstfall was entscheidet, beschreibt Cyberangriff: die ersten 60 Minuten; die Gerätecode-Schritte gehören als eigener Fall in Ihren Incident-Response-Plan.

/08Grenzen und Fallstricke der Sperre

Die Regel ist einfach, ihre Nebenwirkungen nicht immer. Vier Punkte, an denen Einführungen hängen bleiben:

• Protokoll-Tracking wirkt nach. Entra ID merkt sich, dass eine Sitzung mit dem Gerätecode-Fluss begonnen hat, und vererbt das an spätere Token-Erneuerungen. Eine Sitzung, die per Gerätecode für SharePoint erlaubt war, kann deshalb beim Zugriff auf Exchange gesperrt werden, obwohl dort kein Gerätecode im Spiel ist. Im Protokoll zeigt das Feld Original transfer method den Grund; gilt die Regel für alle Anwendungen, erscheint der Fehler AADSTS530036. Microsoft nennt das erwartetes Verhalten ohne Abhilfe – betroffene Geräte müssen sich neu anmelden.
• Der Device Registration Service muss draußen bleiben. Seit September 2024 greifen Authentication-Flow-Regeln auch dort, wenn die Regel auf „All resources" zielt. Wer ihn nicht ausnimmt, wundert sich, warum neue Teams-Geräte sich nicht mehr registrieren lassen.
• Die Regel schützt nicht vor Token-Diebstahl über andere Wege. AiTM-Proxys, gestohlene Sitzungs-Cookies von infizierten Rechnern oder böswillige App-Einwilligungen sind eigene Baustellen. Die Sperre schließt genau einen Weg, und zwar einen, der 2026 besonders billig geworden ist.
• Ohne Lizenz keine Feinsteuerung. Conditional Access setzt Entra ID P1 voraus. Wer nur Microsoft 365 Business Standard hat, kann keine eigene Regel mit Ausnahmen bauen (siehe /09).

Ein weiterer Fallstrick ist organisatorisch: Report-only ist bequem und wird gern vergessen. Eine Regel, die seit einem halben Jahr „nur protokolliert", schützt niemanden. Setzen Sie beim Anlegen ein Datum für das Scharfschalten fest und tragen Sie es in den Änderungskalender ein.

/09Entscheidung: sperren, eingrenzen oder Lizenz klären

Für die meisten Mittelständler ist die Antwort kurz: sperren, mit kleiner, dokumentierter Ausnahmeliste. Die Tabelle ordnet die häufigsten Ausgangslagen.

Die Sicherheitsstandards sind die kostenlose Grundsicherung von Entra ID. Laut Microsoft blockieren sie den Gerätecode-Fluss, und seit dem 1. Juli 2026 gilt das für alle neuen Tenants. Ältere Tenants, in denen die Standards irgendwann abgeschaltet wurden – oft wegen eines Druckers oder eines alten Mailprogramms –, stehen dagegen offen. Ein Blick unter Entra ID › Overview › Properties › Manage security defaults klärt das in einer Minute.

Wann ist das Thema für Sie irrelevant? Wenn Sie kein Microsoft 365 und kein Entra ID nutzen – oder wenn Ihre Bestandsaufnahme ergibt, dass die Sicherheitsstandards aktiv sind und Sie keine Raumsysteme betreiben. Dann ist der Fluss bereits zu, und Ihre Zeit ist bei anderen Anmelderegeln besser aufgehoben. Wo Microsoft 365 im Rahmen einer Umstellung ohnehin neu geordnet wird, gehört die Regel in die Grundkonfiguration der Microsoft-365-Migration und nicht in ein späteres Nachrüstprojekt.

/10Häufige Fragen