Microsoft Threat Intelligence beschreibt mit EvilTokens eine Phishing-as-a-Service-Plattform, die Device-Code-Anmeldungen missbraucht und Microsoft-365-Konten ohne klassische Passwortweitergabe übernehmen kann. Der Microsoft Security Blog nennt mehr als 12.000 kompromittierte Postfächer in über 10.000 Organisationen weltweit und beschreibt konkrete Schutzmaßnahmen für Microsoft Entra ID, Conditional Access, Defender XDR und Exchange Online. Für KMU zählt daran nicht der Name der Plattform, sondern der Prüfpunkt: Sind Device-Code-Flows, riskante Anmeldungen, Postfachregeln und Token-Reaktion so konfiguriert, dass ein bestätigter Vorfall schnell sichtbar und eingedämmt wird?
Was Microsoft am 22. September 2026 meldet
Microsoft berichtet, dass EvilTokens seit Februar 2026 für KI-gestützte Köder, automatisierte Infrastruktur und Token-Diebstahl genutzt wurde. Angreifer erzeugen dabei einen legitimen Device-Code-Flow, zeigen dem Benutzer einen Code an und leiten ihn auf die echte Microsoft-Seite microsoft.com/devicelogin. Bestätigt der Benutzer den Code, autorisiert er nicht sein eigenes Gerät, sondern die Sitzung des Angreifers. Der Vorgang kann deshalb auch seriös wirken, obwohl der Auslöser vollständig vom Angreifer kontrolliert wird.
Microsoft beschreibt danach typische Folgeaktivitäten: Zugriff auf E-Mails, Microsoft-Graph-Reconnaissance, neue Geräte, langlebigere Zugriffsmöglichkeiten und bösartige Postfachregeln. Die Digital Crimes Unit hat laut Microsoft Infrastruktur des Dienstes gestört; die empfohlenen Kontrollen bleiben trotzdem relevant, weil Device-Code-Phishing als Technik nicht an einen einzelnen Anbieter gebunden ist.
Warum das für KMU spürbar ist
Die beschriebenen Köder passen in normale Geschäftsprozesse: Rechnungen, Angebotsanfragen, geteilte Dateien, Voicemail oder angebliche Microsoft-Cloud-Hinweise. Organisationen mit 10 bis 250 Arbeitsplätzen haben oft weniger getrennte Rollen, aber viele gemeinsam genutzte Postfächer, Projektordner und externe Kontakte. Ein einziges kompromittiertes Konto kann dadurch Rechnungen, Kundenkommunikation und interne Freigaben betreffen. Hinzu kommt: In kleineren Teams kennt man viele Absender persönlich, deshalb wird eine scheinbar normale Freigabe oder Rückfrage seltener als Angriff eingeordnet.
- Device-Code-Anmeldung wirkt für Benutzer wie ein normaler Microsoft-Schritt.
- MFA schützt nicht, wenn der Benutzer den Angreifer-Flow selbst bestätigt.
- Postfachregeln können Warnungen und Antworten vor dem Benutzer verbergen.
- Graph-Abfragen zeigen, ob nach der Anmeldung weitere Datenbereiche gesucht wurden.
Dringlichkeit: laufende Technik statt fester Frist
Microsoft nennt keinen zukünftigen Stichtag. Die konkrete Handlung ist eine zeitnahe Konfigurations- und Signalprüfung. Besonders wichtig sind Conditional-Access-Regeln für Authentifizierungsflüsse, Entra-ID-Risikosignale, Defender-for-Office-365-Schutz gegen Phishing-Links, Safe Links, Zero-hour auto purge und die Behandlung kompromittierter Postfächer.
Für Umgebungen mit Conditional Access empfiehlt Microsoft, Device-Code-Flow möglichst zu blockieren und notwendige Ausnahmen eng zu begrenzen. Wenn Teams-Geräte oder Konferenzgeräte den Flow wirklich benötigen, sollte die Ausnahme auf definierte Ressourcenkonten beschränkt werden. Das ist keine Lizenzberatung, sondern eine technische Zugriffskontrolle.
Welche Signale zusammengehören
Ein einzelner Link oder eine einzelne IP-Adresse reicht für die Bewertung selten aus. Microsoft listet Defender-XDR-Erkennungen für anomale Device-Code-Authentifizierung, Token-Austausch nach Device-Code-Anmeldung, Geräteregistrierung, ungewöhnliche Microsoft-Graph-Aktivität und verdächtige Postfachregeln. Aussagekräftig wird der Befund, wenn diese Ereignisse als Sequenz geprüft werden. Genau diese Korrelation ist im Alltag entscheidend: Ein Helpdesk sieht vielleicht nur die Benutzerbeschwerde, die IT nur eine Regeländerung, und die Geschäftsführung erst die manipulierte Rechnung.
In Microsoft Defender und Entra ID sollten Administratoren deshalb Benutzer, Zeitpunkt, Anwendung, Gerät, Postfachregel und Folgezugriffe zusammenführen. Wenn ein Konto nach einer Device-Code-Anmeldung plötzlich Graph-Abfragen ausführt, neue Regeln anlegt oder viele Nachrichten berührt, ist die Reaktion dringender als bei einem isolierten Fehlalarm. Die Prüfung sollte auch klären, wer solche Warnungen bearbeitet und wann ein Konto vorübergehend deaktiviert wird.
Konkrete nächste Schritte für Administratoren
- Device-Code-Flow in Conditional Access prüfen und unnötige Nutzung blockieren.
- Ausnahmen für Teams- oder Konferenzgeräte dokumentieren und eng begrenzen.
- Riskante Anmeldungen, Safe-Links-Treffer und Defender-XDR-Warnungen korrelieren.
- Verdächtige Postfachregeln, Weiterleitungen und Inbox-Manipulationen suchen.
- Bei bestätigtem Verdacht Sitzungen widerrufen und Refresh Tokens ungültig machen.
- Network Protection, Web Protection und Anti-Phishing-Richtlinien gegenprüfen.
In einem Microsoft Security Assessment lässt sich daraus ein kompakter Testfall ableiten: Wird Device-Code-Phishing bereits bei Anmeldung, Token-Nutzung und Postfachregel erkannt, oder erst nach Datenabfluss?
Offizielle Microsoft-Quellen
- Microsoft Security Blog: Unmasking EvilTokens
- Microsoft Learn: Block authentication flows
- Microsoft Learn: Responding to a compromised email account
- Microsoft Learn: Inbox manipulation rules playbook
Wenn Sie prüfen möchten, ob Entra ID, Defender XDR und Exchange Online diese Angriffskette in Ihrer Umgebung sichtbar machen, unterstützen wir bei einem fokussierten Review Ihrer Microsoft-365-Sicherheitskonfiguration – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
