Microsoft schaltet Phishing-Dienst EvilTokens ab: Was Admins zum Device-Code-Flow wissen müssen
Microsoft hat am 22. September 2026 den Phishing-as-a-Service-Dienst EvilTokens zerschlagen, der den OAuth-2.0-Device-Authorization-Flow missbrauchte und rund 12.000 Postfächer kompromittierte. Weil dabei gültige Token ausgestellt werden, schützt klassische Passwortsicherheit kaum. Was Admins in Microsoft 365 und Entra ID jetzt konkret prüfen sollten.
Microsoft hat am Dienstag, dem 22. September 2026, die Abschaltung des Phishing-Dienstes EvilTokens bekannt gegeben. Betroffen sind vor allem Organisationen, die Microsoft 365 und Entra ID einsetzen und den OAuth-2.0-Device-Authorization-Flow nicht eingeschränkt haben. Microsoft nennt rund 12.000 kompromittierte Postfächer. Wer den Gerätecode-Anmeldefluss bereits per Conditional Access blockiert, ist von dieser Angriffstechnik praktisch nicht betroffen.
Handeln müssen Sie heute nur dann sofort, wenn Sie den Device-Code-Flow in Ihrem Tenant nie bewusst eingeschränkt haben. Dann gilt: Anmeldeprotokolle auf Gerätecode-Anmeldungen durchsehen, verdächtige Posteingangsregeln und neu registrierte Geräte prüfen. Ein Patch ist hier nicht die Lösung, denn es handelt sich nicht um eine Softwarelücke, sondern um den Missbrauch eines regulären Protokollablaufs. Die Abschaltung des Dienstes beseitigt kein bereits gestohlenes Token in Ihrem Tenant.
Was ist passiert?
Microsoft hat den Phishing-as-a-Service-Dienst EvilTokens zerschlagen. Die Aktion erfolgte mit Genehmigung des US-Bezirksgerichts für den östlichen Bezirk von Virginia. Beteiligt waren neben Microsoft die Health-ISAC sowie Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation und TRM Labs. Die Akteure hinter Entwicklung und Betrieb führt Microsoft als Storm-2992.
Parallel nahm die Metropolitan Police am 11. September 2026 zwei Männer im Alter von 32 und 38 Jahren im Zusammenhang mit dem kommerziellen Betrieb fest. Microsoft beschreibt EvilTokens als Cybercrime-Plattform, die künstliche Intelligenz an jedem Schritt der Angriffskette einsetzte, um E-Mail-Konten zu übernehmen und Vorgehenspläne für Finanzbetrug zu entwerfen.
Im Zentrum des Dienstes stand laut Microsoft ein Chatbot, der den Posteingang eines Opfers analysieren konnte. Er half Kriminellen dabei, Vertrauensbeziehungen, Zahlungsfreigaben und sensible Zuständigkeiten zu erkennen und Situationen zu finden, in denen Betrug am ehesten gelingt. Steven Masada, Associate General Counsel und General Manager der Digital Crimes Unit von Microsoft, beschreibt, dass die Plattform sogar Betrugsstrategien empfehlen und Nachrichten entwerfen konnte, die vertrauenswürdige Kontakte imitieren.
Wie die Device-Code-Technik funktioniert
EvilTokens wurde erstmals im März 2026 von Huntress als Phishing-as-a-Service-Plattform dokumentiert, die den OAuth-2.0-Device-Authorization-Flow missbraucht. Dieser Flow existiert für Geräte ohne Tastatur oder Browser, etwa Smart-TVs und Konsolen. Der Nutzer bekommt einen kurzen Code angezeigt und gibt ihn auf einer separaten, echten Verifizierungsseite ein.
Genau diesen Ablauf drehen die Angreifer um. Der per Phishing zugestellte Köder zeigt dem Nutzer einen Gerätecode für den Dienst, auf den der Angreifer zugreifen will. Das Opfer wird aufgefordert, diesen Code auf der legitimen Verifizierungsseite einzugeben, etwa unter microsoft.com/devicelogin. Sobald der Code dort eingegeben und die Anmeldung bestätigt ist, stellt der Autorisierungsserver Zugriffs- und Aktualisierungstoken an den Client des Angreifers aus.
Der Angreifer agiert damit dauerhaft unter der Identität des Opfers, ohne jemals selbst Zugangsdaten eingegeben zu haben. Die gestohlenen Token werden für E-Mail-Exfiltration und Persistenz missbraucht, häufig über bösartige Posteingangsregeln, die die eigene Kommunikation vor dem Opfer verbergen. Teilweise wurden die Token auch genutzt, um neuen Geräten Zugriff auf das Postfach zu gewähren und so einen zweiten dauerhaften Zugangsweg aufzubauen.
Wer ist betroffen?
Relevant ist das für jede Organisation mit Microsoft 365 oder Entra ID, in der der Gerätecode-Anmeldefluss nicht gezielt eingeschränkt wurde. Der Flow ist standardmäßig nutzbar, und viele Tenants haben ihn nie bewusst konfiguriert, weil er im Alltag selten sichtbar wird.
- Besonders exponiert sind Postfächer mit Zahlungsfreigaben, Buchhaltung, Geschäftsführung und Einkauf, weil sie das eigentliche Betrugsziel sind.
- Ebenfalls exponiert sind Tenants ohne Auswertung der Entra-Anmeldeprotokolle, weil Gerätecode-Anmeldungen dort schlicht nicht auffallen.
- Deutlich geringer betroffen sind Tenants, die den Authentifizierungsfluss für Gerätecode per Conditional Access bereits blockieren oder auf definierte Geräte begrenzen.
- Nicht betroffen von dieser konkreten Technik sind Umgebungen ohne Entra-ID-Anbindung, etwa rein lokale Mailserver ohne Microsoft-Identität.
Wichtig für die Erwartungshaltung: Die Zahl von rund 12.000 kompromittierten Postfächern stammt von Microsoft und bezieht sich auf den Dienst insgesamt, nicht auf eine Region oder Branche. Eine Aufschlüsselung nach Ländern liegt nicht vor.
Wie kritisch ist das?
Technisch ist das keine Schwachstelle mit CVE-Nummer und keine Remote Code Execution, sondern Missbrauch eines vorgesehenen Protokollablaufs durch Täuschung des Nutzers. Die Wirkung ist trotzdem erheblich, weil am Ende ein gültiges Token steht, das die normale Anmeldung ersetzt.
Der entscheidende Punkt für die Einordnung: Weil hier gültige Token ausgestellt werden und keine Zugangsdaten abgefangen werden, hilft klassische Passwortsicherheit wenig. Ein sehr langes Passwort ändert nichts daran, dass das Opfer die Freigabe selbst erteilt hat. Auch eine bestandene Mehrfaktor-Prüfung schützt nicht, wenn sie im Rahmen genau dieser Freigabe stattfindet.
Die Abschaltung von EvilTokens entfernt einen kommerziellen Anbieter, nicht die Technik. Der Device-Code-Missbrauch ist öffentlich dokumentiert und wurde auch von anderen Gruppen genutzt. Wer daraus ableitet, dass das Thema mit dem Takedown erledigt ist, zieht den falschen Schluss.
Was sollten Admins jetzt tun?
- Zuerst inventarisieren: Prüfen Sie in Entra ID, ob in Ihrem Tenant überhaupt eine Conditional-Access-Richtlinie existiert, die den Authentifizierungsfluss für Gerätecode einschränkt. Ohne diesen Befund ist jede weitere Bewertung Spekulation.
- Anmeldeprotokolle in Entra ID auf Anmeldungen über den Gerätecode-Fluss durchsehen, rückwirkend über einen möglichst langen verfügbaren Zeitraum.
- Wenn der Flow fachlich nicht gebraucht wird: Conditional-Access-Richtlinie anlegen, die den Authentifizierungsfluss für Gerätecode blockiert. Das ist der wirksamste Einzelhebel.
- Wenn der Flow gebraucht wird, etwa für bestimmte Geräte oder Räume: Richtlinie auf eine definierte Ausnahmegruppe begrenzen, statt ihn tenantweit offen zu lassen.
- Posteingangsregeln in exponierten Postfächern prüfen, besonders Regeln, die Nachrichten in selten genutzte Ordner verschieben, als gelesen markieren oder weiterleiten.
- Registrierte Geräte in Entra ID auf unerwartete Neuzugänge prüfen, denn ein zusätzlich registriertes Gerät ist ein zweiter dauerhafter Zugangsweg.
- Bei Verdacht Aktualisierungstoken des betroffenen Kontos zurücknehmen und die Sitzungen beenden. Ein reiner Passwortwechsel ohne Token-Rücknahme genügt nicht.
- Nach einer Token-Rücknahme erneut prüfen, ob Posteingangsregeln und Geräteregistrierungen wieder auftauchen, denn ein übersehener Zugangsweg stellt den Zustand wieder her.
- Mitarbeitende gezielt darauf hinweisen, dass ein per Mail oder Chat zugesandter Anmeldecode niemals auf einer Anmeldeseite eingegeben werden darf, auch wenn die Seite echt aussieht und echt ist.
- Meldeweg festlegen, damit ein unerwarteter Code-Eingabe-Dialog sofort an die IT gemeldet wird, statt still weggeklickt zu werden.
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen ist die praktische Lehre unbequem: Die übliche Schutzkette aus starkem Passwort, Mehrfaktor-Authentifizierung und Spamfilter greift hier nur begrenzt. Der Angriff zielt nicht auf ein Geheimnis, sondern auf eine Zustimmung. Deshalb verschiebt sich der Hebel von der Anmeldung zur Richtlinie und zur Nachkontrolle.
Konkret heißt das: Eine einmalige Conditional-Access-Entscheidung zum Gerätecode-Fluss bringt mehr Sicherheit als jede weitere Passwortregel. Ergänzend braucht es eine regelmäßige Sichtung von Posteingangsregeln und Geräteregistrierungen, weil dort die Persistenz sichtbar wird, nicht im Anmeldevorgang selbst.
Der KI-Anteil des Dienstes ist dabei weniger ein technischer als ein ökonomischer Faktor. Er senkt den Aufwand, aus einem übernommenen Postfach einen zielgerichteten Zahlungsbetrug zu bauen. Wer bisher darauf gesetzt hat, dass Betrugsmails an schlechter Sprache oder fehlendem Kontext erkennbar sind, sollte diese Annahme nicht weiter als Schutzschicht einplanen. Freigabeprozesse mit Rückruf auf einer bekannten Nummer wirken hier zuverlässiger als das Bauchgefühl einzelner Mitarbeitender.
Passende Anleitungen auf S-EDV
- Passkey-Phishing in Microsoft 365 durch Storm-3121 liefert den Hintergrund zu einer anderen Kampagne, die ebenfalls auf den Gerätecode-Fluss setzt.
- Microsoft 365 MFA und Conditional Access in Entra ID einrichten zeigt, wie Richtlinien im Tenant angelegt und auf Gruppen begrenzt werden.
- Phishing-Schutz in Defender für Office 365 einrichten ergänzt die Richtlinienseite um die Filter- und Meldewege für verdächtige Nachrichten.
