Was angekündigt wurde und was die gerichtliche Bekanntmachung belegt

Am 22. September 2026 veröffentlichte Microsoft in seinem Bereich für gerichtliche Dokumentenbekanntmachungen eine Seite mit dem Titel „EvilTokens“. Das für diesen Beitrag verifizierte Material bestätigt den Titel, den Ort der Seite und ihr Veröffentlichungsdatum. Es reicht jedoch nicht aus, um Einzelheiten zu den Parteien, den beantragten Maßnahmen oder dem Verfahrensstand festzustellen. Deshalb sollten konkrete Vorwürfe oder eine Gerichtsentscheidung auf Grundlage dieser Seite nicht als erwiesene Tatsachen dargestellt werden. Diese Abgrenzung ist wichtig: Eine Bekanntmachung ist für sich genommen kein vollständiger Bericht über den zugrunde liegenden Vorgang.

Die Berichterstattung von CSO Online ordnet den Fall in den breiteren Zusammenhang KI-bezogener Cyberkriminalität ein. Diese journalistische Einordnung belegt für sich genommen nicht, welche Rolle KI gegebenenfalls bei konkreten Vorfällen spielte. Die hier verfügbaren Quellen enthalten keine unabhängige Prüfung, die ihren Einsatz, Umfang oder ihre Wirkung bei EvilTokens zugeschriebenen Kampagnen bestätigt. Dieselbe Zurückhaltung gilt für Auswirkungszahlen und den Umfang möglicher Maßnahmen gegen die Plattform. Die verifizierten Dokumente enthalten keine unabhängige Zahl betroffener Konten und beschreiben nicht, welche technischen Ressourcen entfernt wurden. Microsofts Seite bestätigt eine Veröffentlichung zu EvilTokens in einem Bereich für gerichtliche Bekanntmachungen, ermöglicht aber keine vollständige Rekonstruktion des Sachverhalts. Wer dokumentierte Angaben von nicht verifizierbaren Punkten trennt, macht aus einer Ankündigung oder Medienreferenz keine vermeintlich bestätigte Bilanz.

Der legitime Ablauf, der zum Köder werden kann

Die Authentifizierung mit Gerätecode ist ein legitimer OAuth-Autorisierungsablauf und eignet sich für Geräte mit eingeschränkten Benutzeroberflächen, etwa Fernseher, Drucker oder IoT-Geräte. Das Gerät fordert einen Code an, und die Person schließt die Authentifizierung im Browser eines anderen Geräts ab. Laut Microsoft-Dokumentation wartet der Client auf die Antwort des Autorisierungsdienstes, während der Benutzer den Vorgang abschließt; der Benutzercode ist nur begrenzte Zeit gültig. Praktisch trennt der Ablauf das Gerät, das authentifiziert werden muss, von dem Gerät, auf dem die Person ihre Anmeldedaten eingibt und die Anfrage bestätigt. Der Code verbindet beide Seiten für einen begrenzten Zeitraum. Durch wiederholte Abfragen kann das ursprüngliche Gerät erfahren, ob die Autorisierung abgeschlossen wurde, ohne eine eigene Anmeldeschnittstelle zu benötigen.

Das ist praktisch, wenn ein Gerät keine geeignete Tastatur oder keinen geeigneten Browser hat. Zugleich müssen Benutzer verstehen, welche Anfrage sie bestätigen. Die Dokumentation erlaubt eine allgemeine Beschreibung des Verfahrens, doch die für diesen Beitrag verifizierten Quellen reichen nicht aus, um zu bestätigen, dass EvilTokens den Ablauf in einer bestimmten Kampagne verwendete oder dessen technische Schritte zu rekonstruieren. Als allgemeines Risiko dieses Ablaufs kann eine Person dazu gebracht werden, einen Code einzugeben und eine Anfrage zu bestätigen, die sie nicht selbst gestartet hat oder nicht erkennt. Ein legitimes Portal garantiert nicht, dass auch die zu bestätigende Anfrage legitim ist. Diese Erläuterung des Risikos ist nicht mit einer verifizierten Beschreibung der Vorgehensweise von EvilTokens gleichzusetzen.

Was sich über KI sagen lässt

Die Überschrift von CSO Online verknüpft die Unterbrechung von EvilTokens mit dem breiteren Kontext KI-gestützter Cyberkriminalität. Die verfügbaren verifizierten Quellen enthalten jedoch keine unabhängige Untersuchung, die den Einsatz von KI-Fähigkeiten bei konkreten Vorfällen bestätigt. KI lässt sich daher nicht als nachgewiesene Erklärung für den Erfolg einer mit EvilTokens verbundenen Kampagne darstellen. Die Einordnung eines Medienberichts und Belege zu einem konkreten Vorfall sind voneinander zu unterscheiden: Aus der ersten ergibt sich nicht automatisch, was im zweiten geschehen ist.

Das allgemeine Risiko des Ablaufs lässt sich erklären, ohne es einer bestimmten Technologie zuzuschreiben: Eine Person kann dazu verleitet werden, eine ihr unbekannte Authentifizierungsanfrage zu bestätigen. Ermöglicht diese Bestätigung eine gültige Sitzung, bilden Kontrollen, die sich allein auf das Passwort konzentrieren, das gesamte Risiko nicht ab. Sowohl der Autorisierungsmechanismus als auch die Entscheidung, eine Anfrage zu bestätigen, sind relevant; diese allgemeinen Überlegungen belegen jedoch nicht, wie ein bestimmter Dienst funktionierte. KI verdient Aufmerksamkeit, muss aber nicht als Faktor in diesem Fall dargestellt werden, um die praktische Vorsichtsmaßnahme zu erläutern. Das verfügbare Material lässt weder erkennen, ob Automatisierung eingesetzt wurde, noch welche Aufgaben sie übernommen oder welchen Beitrag sie geleistet hätte. Ebenso wäre es nicht verantwortungsvoll, eine Zahl betroffener Konten als bestätigt wiederzugeben, solange dafür keine verifizierbare Quelle vorliegt. Die Berichterstattung zum KI-Kontext sollte von den Schlussfolgerungen getrennt bleiben, die sich tatsächlich aus der Dokumentation ziehen lassen.

Was eine Unterbrechung bedeutet – und was nicht

Microsofts Seite bestätigt eine Veröffentlichung mit dem Titel „EvilTokens“. Die in den verifizierten Quellen verfügbaren Informationen erlauben jedoch keine Aussage darüber, wie viele oder welche Arten technischer Ressourcen entfernt worden sein könnten. Sie belegen auch nicht, dass die gesamte zugehörige Infrastruktur verschwunden ist. Dass eine Seite in einem Bereich für gerichtliche Bekanntmachungen existiert, reicht nicht aus, um einer Maßnahme ein konkretes technisches Ergebnis zuzuschreiben. Auch die praktischen und anhaltenden Folgen einer angekündigten Unterbrechung müssen durch Belege gestützt werden, die über die Ankündigung hinausgehen.

Allgemein kann die Unterbrechung einer Plattform die Fortsetzung der ihr zugeschriebenen Aktivitäten erschweren. Sie beweist jedoch nicht, dass sämtliche Instanzen, Betreiber oder Kopien identifiziert oder entfernt wurden. Ebenso wenig belegt sie, dass andere Akteure nicht auf eine andere Infrastruktur ausweichen oder eine ähnliche Technik nachahmen können. Das sind allgemeine Grenzen bei der Bewertung einer Abschaltung, keine verifizierten Aussagen über den Umfang einer konkreten Maßnahme gegen EvilTokens. Auf Grundlage der verifizierbaren Informationen sollte weder behauptet werden, alle zugehörigen Domains oder Dienste seien entfernt worden, noch sollte angegeben werden, welche Maßnahmen gegen jede einzelne Komponente ergriffen wurden. Die Unterbrechung eines identifizierten Vorgangs kann dessen Reichweite verringern; sie beseitigt nicht von selbst eine Phishing-Technik und hindert andere nicht daran, sie nachzuahmen. Wer den Status einer Plattform von einer möglichen Fortsetzung ähnlicher Methoden unterscheidet, vermeidet Schlussfolgerungen, die über die verfügbaren Belege hinausgehen.

Schutzmaßnahmen: erst prüfen, dann blockieren

Organisationen, die den Gerätecode-Ablauf nicht benötigen, können ihn laut Microsoft-Dokumentation mithilfe einer Conditional-Access-Richtlinie blockieren. Vor der Anwendung sollte geprüft werden, ob die Organisation diesen Ablauf nutzt und welche Anmeldungen davon betroffen sein könnten. Die Microsoft-Dokumentation zu Authentifizierungsabläufen erklärt, wie dieser Ablauf als Bedingung einer Richtlinie verwendet werden kann. Daraus folgt nicht, dass jede Organisation dieselbe Sperre einrichten sollte. Die Prüfung ist wichtig, weil eine pauschale Sperre Geräte oder Prozesse unterbrechen könnte, die rechtmäßig auf diese Methode angewiesen sind. Falls Ausnahmen nötig sind, sollten sie auf festgestellte Bedürfnisse beschränkt und bei Änderungen an Systemen oder ihrer Nutzung überprüft werden.

Die praktische Empfehlung lautet, unnötige Abläufe zu reduzieren, ohne dem Gerätecode legitime Einsatzmöglichkeiten abzusprechen, und eine Konfiguration zu testen, bevor sie breit angewendet wird. Das ist eine operative Orientierung auf Grundlage der dokumentierten Kontrolle, keine Aussage, dass eine bestimmte Richtlinie für jede Umgebung geeignet wäre. Für Benutzer ist eine unerwartete Aufforderung, einen Code einzugeben oder eine Anmeldung zu bestätigen, ein hilfreiches Warnsignal. Wer die Authentifizierung nicht selbst gestartet hat und nicht weiß, welches Gerät oder welche Anwendung sie anfordert, sollte den Vorgang nicht abschließen und die Anfrage über einen bekannten Kanal prüfen. Am Aussehen des Portals allein lässt sich nicht erkennen, wer die mit dem Code verknüpfte Anfrage gestartet hat; auch der Kontext ist entscheidend. Sicherheitsteams können den Fall zum Anlass nehmen, aktivierte Abläufe und ungewöhnliche Anmeldungen zu überprüfen. Die Empfehlung lautet nicht, MFA aufzugeben, sondern sie mit bedarfsgerechten Richtlinien und Aufmerksamkeit für den Kontext jeder Bestätigung zu verbinden.