Phishing Series Part 1: Der Code, den niemand hinterfragt

Device-Code-Phishing: Wenn MFA sauber funktioniert – und der Angreifer trotzdem drin ist

Der Benutzer bekommt eine Mail: ein Dokument wurde freigegeben. Schnell geklickt, landet auf einer Seite mit einem neunstelligen Code und der Anweisung, ihn auf microsoft.com/devicelogin einzugeben. Er tut es. Meldet sich mit Passkey an, was phishing-resistent, sauber und genau so ist, wie es allen beigebracht wird. Er sieht „Sie sind angemeldet“ und macht weiter mit dem Tag.

In diesem Moment hält jemand anderes ein gültiges Access- und Refresh-Token auf das Konto des Benutzers.

Kein Passwort wurde gestohlen. Keine gefälschte Login-Seite war im Spiel. Die URL im Browser war echt, das Zertifikat war echt, die MFA war echt.

Und genau das ist das Problem…

Technisch basiert der Angriff auf einem vollkommen legitimen Microsoft-Anmeldeverfahren: dem OAuth 2.0 Device Authorization Flow, meistens einfach Device Code Flow genannt.

Dieser Mechanismus wurde ursprünglich für Geräte entwickelt, auf denen eine normale Anmeldung umständlich oder gar nicht möglich ist – zum Beispiel Smart-TVs, Konsolen oder Kommandozeilen-Tools. Das Gerät zeigt einen kurzen Code an und bittet den Benutzer, diesen auf einem zweiten Gerät unter microsoft.com/devicelogin einzugeben.

Genau diesen Mechanismus missbraucht der Angreifer.

1. Der Angreifer startet eine Anmeldung

Der Angreifer startet auf seinem eigenen System einen Device-Code-Login gegen Microsoft.

Microsoft erzeugt daraufhin zwei Werte:

• einen User Code, zum Beispiel G8MB3QVWX
• einen internen Device Code, mit dem der gestartete Login-Vorgang eindeutig identifiziert wird

Der entscheidende Punkt: Der Code gehört zu der Anmeldung, die der Angreifer gestartet hat.

2. Der Code wird an das Opfer weitergegeben

Jetzt muss der Angreifer nur noch jemanden dazu bringen, diesen Code zu bestätigen.

Zum Beispiel über eine Phishing-Mail:

Ein Dokument wurde mit Ihnen geteilt.
Geben Sie zur Bestätigung diesen Code ein: G8MB3QVWX

Der Benutzer landet anschliessend tatsächlich auf:

https://microsoft.com/devicelogin

Keine nachgebaute Microsoft-Seite. Keine falsche Domain. Kein gestohlenes TLS-Zertifikat.

Die Microsoft-Seite ist echt.

3. Der Benutzer meldet sich ganz normal bei Microsoft an

Der Benutzer gibt den erhaltenen Code ein.

Microsoft fragt anschliessend nach der normalen Authentifizierung:

• E-Mail-Adresse
• Passwort / Passkey
• MFA
• Anmeldung erfolgreich

Auch ein Passkey funktioniert hier genau so, wie er funktionieren soll.

Der Passkey überprüft nämlich korrekt:

„Bin ich wirklich auf einer Microsoft-Webseite?“

Die Antwort lautet: Ja.

Das Problem liegt an einer anderen Stelle.

Der Benutzer bestätigt gerade unbewusst den Login-Vorgang des Angreifers.

4. Microsoft verbindet beide Seiten miteinander

Während der Benutzer die Anmeldung abschliesst, wartet das System des Angreifers im Hintergrund.

Es fragt Microsoft regelmässig:

Ist der Device Code bereits bestätigt?

Zunächst antwortet Microsoft sinngemäss:

Noch nicht.

Sobald das Opfer die Anmeldung abgeschlossen hat, ändert sich die Antwort.

Authentifizierung erfolgreich.

Microsoft stellt daraufhin dem Client, der den Device-Code-Vorgang gestartet hat, ein gültiges Access Token und – abhängig vom verwendeten Client und den angeforderten Berechtigungen – gegebenenfalls auch ein Refresh Token aus.

Und dieser Client läuft beim Angreifer.

Das Entscheidende dabei

Der Angreifer hat weder das Passwort noch den Passkey des Benutzers gesehen.

Er musste auch die MFA nicht knacken.

MFA hat erfolgreich funktioniert.

Was der Benutzer jedoch nicht erkannt hat: Er authentifizierte nicht einfach nur sich selbst. Er autorisierte damit gleichzeitig den bereits laufenden Device-Code-Vorgang des Angreifers.

Ein Passkey schützt sehr effektiv davor, Zugangsdaten auf einer gefälschten Webseite einzugeben. Er kann aber nicht entscheiden, warum der Benutzer gerade einen legitimen Device Code bestätigt.

Genau deshalb ist Device-Code-Phishing so interessant:

Die Authentifizierung selbst wird nicht gebrochen. Der Angreifer manipuliert den Kontext, in dem die legitime Authentifizierung stattfindet.

Die Technik ist nicht neu – Nestori Syynimaa hat sie im Oktober 2020 beschrieben. Bis August 2024 hat sie schlicht niemand benutzt. Dann kam Storm-2372 mit Teams-Einladungen als Köder, und 2025 blieb Device-Code-Phishing weitgehend eine Sache staatsnaher Akteure.

2026 ist die Technik zur Massenware geworden. Die Zahlen aus dem ersten Halbjahr sind ungewöhnlich eindeutig:

• CrowdStrike meldet im Threat Hunting Report 2026 eine 15-fache Zunahme von Device-Code-Phishing gegenüber dem zweiten Halbjahr 2025.
• Push Security kommt auf einen 37-fachen Anstieg erkannter Landing Pages und verfolgt inzwischen über 25 verschiedene Kits.
• Barracuda zählte in vier Wochen im April über 7 Millionen Angriffsversuche.
• Microsoft beobachtete ab Mitte März 10 bis 15 neue Kampagnen pro 24 Stunden.
• Das FBI publizierte im Mai 2026 mit PSA I-052126 seine erste eigenständige Warnung zu einem einzelnen PhaaS-Kit (Kali365).

Der Auslöser ist kein technischer Durchbruch, sondern ein Geschäftsmodell. Im Februar 2026 tauchte EvilTokens auf – das erste kriminelle Phishing-as-a-Service-Kit, das den Device-Code-Flow schlüsselfertig verkauft, inklusive Token-Harvesting, Webmail-Oberfläche und KI-generierten Ködern. Sekoia zählt die Schweiz zu den am stärksten betroffenen Ländern. Danach ging es schnell: Kali365, Device Code Lab, Venom, CYB3R, Ghost Hub. Selbst Tycoon 2FA und Greatness, beide gross geworden mit AiTM-Reverse-Proxy-Phishing, haben Device-Code-Payloads nachgerüstet. Proofpoint beobachtet mit TA4903 einen etablierten BEC-Akteur, der praktisch vollständig auf die Technik umgestellt hat.

Nebenbei erklärt das auch, warum so viele Kits gleich aussehen: Ein Grossteil davon sind per LLM zusammengebaut worden – ähnliche Prompts, ähnlicher Code, ähnliches Layout.

Die folgenden Screenshots enthalten fiktive Daten, werden jedoch anhand der tatsächlichen Phishing-as-a-Service-Kit dargestellt.

Der Lure-Manager. Sechs eingesetzte Phishing-Seiten, von denen jede ein anderes Microsoft-Produkt vortäuscht (OneDrive, SharePoint, Teams, Outlook, DocuSign, Voicemail) und über eine eigene, von Cloudflare bereitgestellte benutzerdefinierte Domain bereitgestellt wird. Anhand der Besucher- und Erfassungszahlen auf der rechten Seite misst der Betreiber, was funktioniert.

Der Token-Tresor. Jede Zeile entspricht einer aktiven M365-Sitzung, auf die der Operator sofort reagieren kann. Die Spalte «Stage» (RECON / EXPLOIT / CASHOUT / DONE) dient dem Operator als Workflow-Tracker; die ADMIN-Tags kennzeichnen Konten mit Admin-Berechtigungen im Microsoft-Tenant. Die Schaltflächen «INBOX» und «EXPORT» auf der rechten Seite erfüllen genau die Funktion, die ihr Name vermuten lässt.

Ein Klick auf die Schaltfläche «INBOX» bei einem erfassten Token öffnet das Postfach des Opfers in einer voll funktionsfähigen Webmail-Ansicht, die über das Panel bereitgestellt wird.

Dem Quellcode der Seite zufolge nutzt das Business Email Compromise-Intelligence-Modul «Claude Sonnet», um abgefangene E-Mail-Konversationen auszuwerten, potenzielle Betrugsfälle zu identifizieren und kontextbezogene Antwortentwürfe zu erstellen. Hier ist ein Entwurf für eine Umleitung einer Überweisung zu sehen, komplett mit gefälschten Bankdaten und einer künstlich erzeugten Dringlichkeit, der vom Angreifer vorbereitet wurde, um ihn über das kompromittierte Konto zu versenden.

Die frühen Kampagnen scheiterten am 15-Minuten-Fenster: Der Code stand direkt in der Mail, und wer sie 20 Minuten später öffnete, lief ins Leere. Die aktuellen Kits haben das gelöst und einiges dazugelernt:

• Dynamische Code-Generierung. Der Code wird erst erzeugt, wenn das Opfer die Landing Page öffnet. Die 15 Minuten laufen ab dem Klick, nicht ab dem Versand.
• Clipboard-Hijacking. Der Code landet per navigator.clipboard.writeText() automatisch in der Zwischenablage – ein Reibungspunkt weniger.
• Redirect-Ketten über vertrauenswürdige Infrastruktur. Cloudflare Workers, Vercel, AWS Lambda, GitHub Pages, kompromittierte legitime Domains. Reputationsfilter greifen nicht.
• Backend auf sauberen PaaS-IPs. Die EvilTokens-Welle lief über Railway.com, eine zweite Welle über BL Networks.
• Anti-Analyse. Deaktiviertes Rechtsklick-Menü, blockierte DevTools-Shortcuts, Debugger-Loops, CAPTCHAs vor der Nutzlast. ReversingLabs fand zusätzlich Zero-Width-Unicode-Zeichen mitten in den Wörtern, an denen Signaturen normalerweise anschlagen.
• Browser-in-the-Browser statt Redirect, plus KI-generierte Köder, die zur Rolle des Opfers passen – RFP, Rechnung, Lohnanpassung, Voicemail.

Ein klassischer Access Token ist typischerweise ungefähr eine Stunde gültig. Bei CAE-fähigen Sessions kann die Token-Lebensdauer deutlich länger sein, weil der Zugriff ereignisbasiert neu bewertet wird.

Interessant wird die Eskalation:

Device Registration – PRT. Zielt der Angreifer auf die App Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), kann er ein eigenes Gerät im Tenant registrieren und daraus ein Primary Refresh Token ableiten – nahtloses SSO auf alles, was an Entra ID hängt, auf Browser-Ebene. Microsoft hat Fälle beobachtet, in denen das innerhalb von 10 Minuten nach der Kompromittierung passierte.

Family of Client IDs – Auch ohne diesen Schritt gehören viele Microsoft-First-Party-Apps zur Family of Client IDs: Ein Refresh Token für ein Familienmitglied lässt sich ohne erneute Anmeldung gegen Access Tokens für andere tauschen. Ein einziger geklauter Office-Token öffnet Outlook, Teams, OneDrive, SharePoint und die Azure-Management-APIs.

Der Rest ist Handwerk. Graph-Recon zur Organisationsstruktur, Filterung nach Personen mit Zahlungsbefugnis, Inbox-Rules zur Unterdrückung von Warnmails, gezielte Suche nach Zahlungsläufen und offenen Rechnungen.

Die ehrliche Antwort fängt mit einer schlechten Nachricht an: Alles, was du bis hierhin gelesen hast, passiert ausserhalb deines Tenants. Der Köder liegt bei Cloudflare, das Backend bei Railway, die Anmeldung findet bei Microsoft statt.

Die gute Nachricht: Im Tenant bleiben aber die Authentifizierung und die darauf folgenden Aktivitäten sichtbar. Genau dort beginnt das Hunting.

1. Device Code Flow per Conditional Access blockieren.

Bedingungen > Authentifizierungsflüsse > Device Code Flow + Gewähren > Zugriff blockieren. Fang im Report-only-Modus an, um legitime Nutzung zu finden. Schau ausserdem unter Conditional Access > Richtlinien > Microsoft-managed nach, ob Microsoft die Richtlinie in deinem Tenant längst selbst ausgerollt hat.

2. Teams-Rooms sauber ausnehmen, statt die Richtlinie aufzuweichen.

Microsoft hat dafür eine eigene Anleitung: eine persistente Gruppe mit den Raum-Ressourcenkonten plus eine Ausnahme für die Ressource Device Registration Service. Die Ausnahme gilt kontobezogen für alles – halte die Gruppe klein und schau sie regelmässig durch.

Microsoft Learn: Restrict device code flow for Microsoft Teams devices with Conditional Access

3. Drei Fallstricke, die in den meisten Anleitungen fehlen:

• Conditional Access wird bei der Ausstellung beziehungsweise Erneuerung von Access Tokens ausgewertet. Eine neu aktivierte Block-Policy beendet jedoch nicht automatisch jedes bereits ausgestellte Access Token oder jede bestehende Anwendungssitzung. Ohne Continuous Access Evaluation können Access Tokens bis zu ihrer Ablaufzeit weiter gültig sein.

Zugriffstoken können ein Sicherheitsrisiko darstellen, wenn sie innerhalb eines Zeitraums widerrufen werden müssen, der kürzer als die typische einstündige Lebensdauer ist. Aus diesem Grund arbeitet Microsoft aktiv daran, die kontinuierliche Auswertung des Zugriffs in Office 365-Anwendungen vorzunehmen, was dazu beiträgt, die Invalidierung von Zugriffstoken nahezu in Echtzeit zu gewährleisten.

• Das Gerät, auf dem sich der Benutzer anmeldet, ist nicht zwingend das Gerät, das den Token bekommt. Beim Device-Code-Flow kann sich der Benutzer auf seinem verwalteten und compliant Firmenlaptop anmelden, während der Device Code ursprünglich vom Rechner des Angreifers stammt. Nach erfolgreicher Autorisierung wird der Token an den ursprünglichen OAuth-Client zurückgegeben. RFC 8628 beschreibt genau diese Trennung zwischen Device Client und End User at Browser.

• Das Blockieren des Device-Code-Flows löst nicht das gesamte OAuth-Phishing-Problem. Die Conditional-Access-Bedingung erfasst gezielt Device Code Flow und Authentication Transfer. Andere OAuth-Flows wie der Authorization Code Flow bleiben davon grundsätzlich getrennt. Microsoft dokumentiert zudem, dass Device-Code-Sessions über „protocol tracking“ auch bei späteren Token-Refreshes weiterhin erkannt und blockiert werden können.

4. Geräteregistrierung einschränken.

MFA für Device Join/Register absichern und das Registrierungslimit sinnvoll begrenzen. Das erschwert insbesondere die Eskalation über ein vom Angreifer registriertes Gerät bis hin zum PRT.

Interessanter sind die Einstellungen unter:

Entra ID > Devices > Device settings

Dort sollte insbesondere geprüft werden:

• Users may join devices to Microsoft Entra: nicht pauschal All, sondern wenn möglich Selected
• Users may register their devices with Microsoft Entra: nur so weit öffnen wie tatsächlich benötigt
• Maximum number of devices per user: auf einen realistischen Wert begrenzen
• Device Join und Registration über Conditional Access absichern

Dabei nicht blind auf Selected umstellen: Autopilot, Teams-Geräte und andere Provisioning-Szenarien müssen vorher getestet werden.

5. Compliant Device als zweite Verteidigungslinie

Grant > Require device to be marked as compliant

oder:

Require Microsoft Entra hybrid joined device

Der Device-Code-Flow hat hier ein fundamentales Problem.

Der Browser, auf dem der Benutzer die Anmeldung bestätigt, und der Client, der den Device Code erzeugt hat und später den Token erhält, sind zwei verschiedene Geräte.

Microsoft beschreibt diese Einschränkung selbst: Der Device-Code-Flow kann den Device-State des einen Geräts nicht einfach auf das andere übertragen.

Das ist genau das Szenario unseres Angriffs:

Firmenlaptop des Benutzers

1. compliant
2. verwaltet
3. Passkey
4. legitime Microsoft-Seite

aber:

OAuth-Client des Angreifers

1. unbekannt
2. nicht compliant
3. nicht verwaltet

Eine Policy, die einen verwalteten oder compliant Device-Kontext voraussetzt, ist deshalb eine starke zusätzliche Barriere.

Sie ersetzt aber nicht die explizite Device-Code-Policy.

Die Reihenfolge bleibt:

Device Code Flow blockieren

und zusätzlich:

Zugriff auf sensible Ressourcen nur von vertrauenswürdigen Geräten erlauben.

Der interessante Fehlercode 50199

Im Zusammenhang mit Device Code taucht ausserdem häufig:

50199

auf.

Spannend wird insbesondere eine Sequenz, in der innerhalb derselben Session beziehungsweise Correlation ID zuerst dieser Zwischenzustand und danach ein erfolgreicher Login erscheint.

EntraIdSignInEvents
| where Timestamp > ago(30d)
| where EndpointCall == "Cmsi:Cmsi"
| where ErrorCode in (0, 50199)
| summarize
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    ErrorCodes = make_set(ErrorCode),
    IPAddresses = make_set(IPAddress),
    Applications = make_set(Application),
    Resources = make_set(ResourceDisplayName)
    by AccountUpn, CorrelationId, SessionId
| where ErrorCodes has_all (0, 50199)
| order by LastSeen desc

Das alleine beweist noch keinen Angriff.

Legitime Device-Code-Nutzung existiert.

Aber wenn dieselbe Session zusätzlich von einem ungewöhnlichen Land, einer unbekannten IP, einer unerwarteten Application ID oder einem privilegierten Benutzer kommt, wird die Sache erheblich interessanter.

Danach kommt BEC

Wenn der Token Zugriff auf Exchange oder Graph ermöglicht hat, hört die Untersuchung nicht beim Login auf.

Interessant sind insbesondere neue oder veränderte Inbox Rules:

CloudAppEvents
| where Timestamp > ago(7d)
| where Application == "Microsoft Exchange Online"
| where ActionType in (
    "New-InboxRule",
    "Set-InboxRule",
    "UpdateInboxRules",
    "Set-Mailbox"
)
| project
    Timestamp,
    AccountId,
    AccountObjectId,
    ActionType,
    IPAddress,
    CountryCode,
    City,
    RawEventData
| order by Timestamp desc

Besonders verdächtig:

ForwardTo

ForwardAsAttachmentTo

RedirectTo

Regeln, die Security-Mails löschen oder verschieben.

Und Regeln, deren Namen absichtlich unscheinbar wirken.

Bei einem bestätigten Account Takeover gehören ausserdem Mailbox-Zugriffe, gesendete Nachrichten, Suchaktivitäten, SharePoint-/OneDrive-Zugriffe und Änderungen an Authentifizierungsmethoden in den Scope.

Token Protection | Noch eine Schicht

Conditional Access besitzt zusätzlich:

Require token protection for sign-in sessions

Token Protection bindet unterstützte Tokens kryptografisch stärker an den Gerätekontext und erschwert dadurch Token Replay von einem anderen System.

Das ist primär eine Verteidigung gegen gestohlene beziehungsweise exportierte Tokens.

Device-Code-Phishing sollte deshalb nicht nach dem Motto:

„Wir haben Token Protection, also brauchen wir den Device-Code-Block nicht.“

behandelt werden.

Die Rollen sind unterschiedlich:

Authentication Flows Policy

verhindert den missbrauchten Device-Code-Vorgang.

Device Compliance

reduziert Zugriff von nicht vertrauenswürdigen Geräten.

Token Protection

erschwert Token Replay.

CAE

reduziert nach einer erkannten Kompromittierung das Zeitfenster für unterstützte Ressourcen.

Zusammen werden diese Kontrollen interessant.

Device-Code-Phishing ist interessant, weil technisch fast nichts „kaputt“ sein muss.

• Die Microsoft-Seite ist echt.
• Der Passkey ist echt.
• Die MFA ist echt.
• Der Benutzer authentifiziert sich tatsächlich bei Microsoft.

Nur gehört die Anmeldung nicht zu dem Vorgang, den der Benutzer glaubt zu bestätigen.

Deshalb löst man das Problem auch nicht mit „noch stärkerer MFA“.

Man löst es strukturell:

1. Device Code Flow blockieren, wo er nicht benötigt wird.
2. Ausnahmen klein und nachvollziehbar halten.
3. Geräteregistrierung kontrollieren.
4. Nicht verwaltete Geräte vom Zugriff fernhalten.
5. Device-Code-Sessions aktiv überwachen.

Und für den Fall, dass trotzdem ein Token verloren geht, eine Incident Response haben, die mehr kann als nur auf „Revoke Sessions“ zu klicken.

Webinar Short: Vibe-Coding eines PhaaS-Kits

Dieses kurze Webinar zeigt, wie sich mit modernen KI-gestützten Entwicklungsansätzen innerhalb kurzer Zeit ein Phishing-as-a-Service-(PhaaS)-Kit erstellen lässt.

Das Video liefert zusätzlichen Kontext dazu, was das Opfer auf der linken Seite sieht und der Angreifer auf der rechten Seite.

URL-Muster zum Abrufen des Device Codes

Wie bereits in der Analyse beschrieben, rufen EvilTokens-Phishing-Seiten den benötigten User Code über einen HTTP-POST-Request an den Endpunkt /api/device/start ab.

Anschliessend wird der Authentifizierungsstatus regelmässig über den folgenden Endpunkt abgefragt:

/api/device/status/<SESSION_ID>

Eine passende Suchabfrage für urlscan.io lautet:

filename:"/api/device/start" AND filename:"/api/device/status/"

Diese Suche kann dabei helfen, weitere Webseiten zu finden, welche dieselben charakteristischen API-Endpunkte verwenden und möglicherweise auf einer ähnlichen EvilTokens-Phishing-Infrastruktur basieren.