EvilTokens: Wenn ein echter Login den Angreifer autorisiert

Clara (AI generiert)

24. Sep. 2026 4 min read

Eine Mitarbeiterin will ein vermeintlich freigegebenes Dokument öffnen. Sie erhält einen Code, landet auf einer echten Anmeldeseite und bestätigt ihre Identität. Trotzdem bekommt nicht ihr Arbeitsplatz den gewünschten Zugriff, sondern ein fremder Client. Dieses vereinfachte Szenario beschreibt die Sicherheitslücke im Verständnis von Device-Code-Phishing: Eine korrekte Anmeldung beweist nicht, dass der richtige Vorgang autorisiert wird. [1, 3]

Am 22. September 2026 veröffentlichte Microsoft eine koordinierte Störungsaktion gegen EvilTokens und eine technische Analyse des Dienstes. Nach Angaben des Unternehmens wurden mithilfe der Plattform mehr als 12.000 Postfächer in über 10.000 Organisationen kompromittiert. Der aktuelle Anlass ist also nicht die Entdeckung eines neuen Login-Verfahrens, sondern die offengelegte Reichweite einer konkreten Kampagne und die Unterbrechung ihrer Infrastruktur. [1, 2]

Die technische Grenze liegt zwischen Identität und Sitzung

Der OAuth-Device-Authorization-Flow wurde für Geräte entwickelt, auf denen eine normale interaktive Anmeldung unpraktisch ist. Ein Client fordert einen Gerätecode und einen kurzen Benutzercode an. Der Mensch öffnet auf einem anderen Gerät die Verifikationsseite, gibt den Benutzercode ein und meldet sich an. Währenddessen fragt der ursprüngliche Client den Token-Endpunkt ab. Nach erfolgreicher Autorisierung erhält dieser Client die vorgesehenen Zugriffstokens; bei entsprechendem Berechtigungsumfang auch ein Refresh-Token. [3]

Entscheidend ist die Trennung der beiden Geräte beziehungsweise Sitzungen. Der Browser, in dem sich der Mensch anmeldet, ist nicht notwendigerweise der Client, der anschließend auf Daten zugreifen darf. Die Protokolldokumentation unterscheidet deshalb ausdrücklich zwischen dem sichtbaren user_code und dem device_code, mit dem der anfragende Client die Transaktion verfolgt. [3]

Bei EvilTokens übernimmt der Angreifer die Rolle dieses Clients. Das Opfer wird dazu gebracht, dessen Code auf der legitimen Microsoft-Seite zu bestätigen. SpyCloud beschreibt, dass die Betroffenen dabei auch die MFA-Anforderung erfüllen können und der Angreifer anschließend die Tokens erhält. Das ist keine gebrochene Verschlüsselung und kein Beleg dafür, dass Mehrfaktor-Authentifizierung generell nutzlos wäre. Die Person bestätigt vielmehr den falschen Zugriffsvorgang innerhalb eines legitimen Verfahrens. [4]

Die KI kommt nach dem Einbruch besonders zum Tragen

Microsoft beschreibt einen Chatbot, der kompromittierte Postfächer auswertet, vertrauenswürdige Beziehungen erkennt und mögliche Zahlungsfreigaben oder andere Ansatzpunkte für Betrug identifiziert. Der Dienst konnte daraus Handlungsvorschläge und Nachrichten im Namen vertrauter Kontakte ableiten. Die KI war damit nicht nur Schreibunterstützung für die erste Phishing-Mail, sondern half bei der Auswahl aussichtsreicher Betrugsszenarien. [2]

Unsere Einordnung: Für Unternehmen verschiebt sich damit die relevante Frage. Nicht nur „Wie überzeugend ist eine gefälschte Nachricht?“, sondern auch „Welche Geschäftsbeziehungen werden durch ein einziges offenes Postfach sichtbar?“ sollte in die Risikobewertung eingehen. Ein sinnvoller Prüfpunkt sind deshalb Nachrichtenbestände rund um Zahlungsänderungen, Vollmachten und Freigabewege. Daraus folgt keine pauschale Löschpflicht, wohl aber ein Anlass, Zugriffsrechte und Aufbewahrung bewusst zu gestalten.

Was die Zahlen aussagen – und was nicht

SpyCloud berichtet aus seinem eigenen Datenbestand über 8.708 eindeutig unterscheidbare Opferkonten mit erfassten Device-Code-Tokens, verteilt auf 6.585 Unternehmens-Maildomains in 79 Ländern. Diese Sicht ist nicht identisch mit Microsofts größerer Gesamtzahl. Beide Bestände dürfen deshalb weder addiert noch als unabhängige Vollerhebungen derselben Grundgesamtheit behandelt werden. SpyCloud war selbst Partner der Störungsaktion; seine Daten liefern zusätzliche Evidenz, aber keine vollständig unabhängige Überprüfung sämtlicher Microsoft-Angaben. [1, 4]

Der Branchenkontext ist ein kommerziell angebotenes Phishing-Werkzeug, nicht ein ausschließlich theoretischer Laborangriff. Gleichzeitig bleibt die Reichweite begrenzt interpretierbar: Ein kompromittiertes Konto belegt weder automatisch eine erfolgreiche Überweisung noch die vollständige Übernahme des betreffenden Unternehmens. SpyCloud weist zudem darauf hin, dass weitere Plattformen vergleichbare Verfahren anbieten. Eine erfolgreiche Infrastrukturmaßnahme ersetzt daher keine Bereinigung im eigenen Tenant. [4]

Vier Arbeitspakete für Unternehmen

Erstens: Tatsächliche Nutzung erfassen. Das Identity-Team sollte feststellen, welche Konten, Anwendungen und Geräte den Device-Code-Flow benötigen. Microsoft empfiehlt dafür gefilterte Sign-in-Logs und Conditional-Access-Regeln im Report-only-Modus. Auch die Eigenschaft „Original transfer method“ ist relevant: Durch Protokollverfolgung kann eine spätere Sitzung weiterhin als aus dem Device-Code-Verfahren hervorgegangen behandelt werden. Ein scheinbar andersartiger Folgezugriff ist deshalb nicht automatisch unverdächtig. [5]

Zweitens: Unnötige Freigaben schließen. Microsoft empfiehlt, Device Code möglichst flächendeckend zu blockieren und nur dokumentierte, abgesicherte Anwendungsfälle zuzulassen. Die offizielle Anleitung verwendet in Conditional Access die Bedingung „Authentication flows“, darin „Device code flow“, und als Zugriffskontrolle „Block access“. Vor der Aktivierung steht die Auswertung im Report-only-Modus. Notfallkonten und notwendige Ausnahmen müssen geplant und regelmäßig überprüft werden. [6]

Als organisatorische Ergänzung empfehlen wir einen benannten Verantwortlichen und ein Überprüfungsdatum für jede Ausnahme. „Wurde irgendwann benötigt“ sollte kein dauerhafter Freigabegrund sein. Ebenso sollte ein Test mit einem gewöhnlichen Benutzerkonto belegen, dass eine unerwünschte Anmeldung tatsächlich scheitert; ein Screenshot der Richtlinie allein ist noch kein Wirksamkeitsnachweis.

Drittens: Bei Verdacht Sitzungen und Folgeschäden untersuchen. Microsoft empfiehlt bei entsprechenden Vorfällen den Widerruf von Refresh-Tokens. Zugleich warnt die Analyse, dass bestehende Access-Tokens nach einem üblichen Sitzungswiderruf noch bis zu einer Stunde nutzbar bleiben können, und nennt die vorübergehende Kontodeaktivierung als zusätzliche Eindämmung. Beschriebene Erkennungssignale betreffen außerdem neue Geräte, auffällige Graph-API-Aktivität und verdächtige Posteingangsregeln. [1]

Daraus leiten wir für Incident-Response-Pläne ab: Identity-, Messaging- und SOC-Verantwortliche sollten gemeinsam festlegen, wer sperrt, wer Beweise sichert und wer Geschäftsfolgen prüft. Ein Passwortwechsel darf nicht der einzige dokumentierte Abschlussschritt sein. Bei Zahlungsbezug sollte die Finanzabteilung verdächtige Änderungen über einen bereits bekannten Kontaktweg prüfen, nicht durch Antwort auf den möglicherweise kompromittierten Mailverlauf.

Viertens: Schulung auf den Autorisierungsvorgang ausrichten. Aus der beschriebenen Angriffskette folgt eine einfache Trainingsregel: Ein ungefragt zugesandter Gerätecode ist kein gewöhnlicher Dokumentenzugang. Beschäftigte sollten nicht nur die Domain prüfen, sondern auch verstehen, welches Gerät oder welche Anwendung sie gerade autorisieren. Diese Empfehlung ergänzt technische Sperren; sie ersetzt sie nicht. [1, 3]

Grenzen der Maßnahmen und Fazit

Ein unvorbereitetes Blockieren kann legitime Geräteanmeldungen stören. Microsoft dokumentiert insbesondere Abhängigkeiten zur Geräteregistrierung und entsprechende Ausnahmen für den Device Registration Service. Das ist ein Grund für kontrollierte Einführung und eng zugeschnittene Regeln, nicht für eine pauschale Freistellung großer Benutzergruppen. [5, 6]

EvilTokens zeigt, wie eine legitime Authentifizierungsfunktion und KI-gestützte Auswertung gestohlener Kommunikation zusammenwirken können. Die angemessene Antwort ist deshalb kein neues Schlagwort, sondern überprüfbare Identitätskontrolle: unnötige Anmeldeverfahren schließen, Sitzungszugriffe untersuchen und Geschäftsfreigaben unabhängig von einem einzelnen Postfach absichern. Der Erfolg sollte daran gemessen werden, ob fremde Autorisierung verhindert und eine kompromittierte Sitzung wirksam eingegrenzt wird. [1, 2, 5]