„Statt Passwörter zu erraten, spielte der Angreifer von Opfern gestohlene Anmeldetoken erneut ein; mehr als 200.000 fehlgeschlagene Anmeldeversuche aus dem Kampagnenzeitraum haben wir auf den IP-Bereich 193.26.115[.]0/24 zurückverfolgt", erklärten die Huntress-Forscher Andrea Hatcher, Susannah Matt, Matt Poto und Andrew Schwartz.

Technisch setzt der Angriff auf eine AitM-Anmeldeseite, die sich zwischen die Opfer und die echte Microsoft-Infrastruktur schiebt. Sie fängt eingegebene Zugangsdaten und MFA-Codes ab und leitet sie an die legitime Anmeldeseite weiter. Eigentliches Ziel ist das Zugriffstoken, das Microsoft nach erfolgreicher Anmeldung ausstellt – damit muss die Mehrfaktor-Authentifizierung kein zweites Mal umgangen werden. Dieses „Anmeldenachweis"-Token wird binnen Minuten von den Geräten der Angreifer aus für automatisierte Anmeldeversuche gegen Microsoft-365-Dienste wiederverwendet.

Für dieses Vorgehen prägten die Forscher den Begriff Token Spraying: Viele gestohlene Token werden in großem Umfang und über mehrere Organisationen hinweg eingespielt – analog zum Password Spraying.

Nach erfolgreichem Zugriff sorgten die Angreifer für Dauerhaftigkeit, indem sie eine eigene Authenticator-App hinterlegten, um künftige MFA-Abfragen selbst zu bestehen – auch dann, wenn das gestohlene Sitzungstoken abläuft oder vom Opfer widerrufen wird. In mindestens 19 Organisationen wurden die bestehenden MFA-Methoden der Opfer entfernt und innerhalb von drei Stunden nach der ersten Anmeldung eine neue Methode registriert. In einem am 21. Juli 2026 beobachteten Fall aktivierten die Täter weniger als 51 Minuten nach der Übernahme der Sitzung eine neue Authenticator-App mit dem Namen „iPhone 13".

„Betrügerische Geräte dienten demselben Zweck", so die Forscher. „Der Bedrohungsakteur registrierte mindestens 48 gefälschte Computer in den Microsoft-Verzeichnissen der betroffenen Organisationen. Ein registriertes Gerät kann dem Angreifer eine dauerhaftere Möglichkeit geben, Token anzufordern, als die gestohlene Sitzung allein – und es bleibt im Verzeichnis, bis es jemand löscht."

Zusätzlich richteten die Angreifer versteckte Posteingangsregeln ein, mit Namen wie „.", „sss", „ss", „iT", „,.", „……..", „s" und „d". Diese löschten eingehende Nachrichten mit bestimmten Schlüsselwörtern rund um Gehaltsabrechnung, Zahlungseingänge und Boni oder verschoben sie in unauffällige Ordner wie RSS-Feeds und Unterhaltungsverlauf. In einem kompromittierten Postfach markierte die Regel sämtliche eingehenden Nachrichten als gelesen und löschte sie; anschließend wurde das Postfach genutzt, um Spam an Hunderte externe Empfänger zu versenden, bis Microsoft Entra ID Protection das Konto als hochriskant einstufte.

Die eingesetzten Token stammen laut Huntress aus mehreren Quellen: AitM-Relays hinter gefälschten Anmeldeseiten, Device-Code-Phishing sowie Social Engineering während eines regulären Anmeldevorgangs.

Erstmals beobachtet wurde die Kampagne von der rumänischen IP-Adresse 193.26.115[.]221. Diese wird laut VirusTotal von einem Fernzugriffstrojaner namens AsyncRAT genutzt und ist dem deutschen Hosting-Anbieter 1337 Services GmbH zugeordnet. GreyNoise führt derzeit 29 IP-Adressen dieses Anbieters, von denen zehn als bösartig und fünf als verdächtig markiert sind. Das Unternehmen steht in Verbindung mit StarkRDP und rdp[.]sh, über die zahlende Kunden virtuelle Server mieten können.

Die zu StarkRDP und rdp[.]sh gehörenden Domains waren im Januar 2025 im Rahmen der internationalen Strafverfolgungsaktion „Talent" abgeschaltet worden – zusammen mit den Websites von Nulled, Cracked und Sellix. Beide Plattformen sind inzwischen wieder in Betrieb, StarkRDP firmiert nun als exy[.]sh.

„StarkRDP hat immer im Rahmen des Gesetzes gearbeitet und ist an keinem der behaupteten Verbrechen beteiligt; das Verfahren wird das bestätigen", hieß es in einem auf den 30. Januar datierten Beitrag des StarkRDP-Telegram-Kontos, den der unabhängige Cybersicherheitsjournalist Brian Krebs wiedergab. „Beschlagnahmt wurden lediglich der Website-Server und unsere Domain. Leider kann niemand sagen, wer sie genommen hat und mit wem wir darüber sprechen können. Deshalb werden wir den Betrieb bald unter einem anderen Namen wieder aufnehmen, um das Kapitel ‚StarkRDP’ zu schließen."

Organisationen, die einen Token-Replay-Vorfall vermuten, empfiehlt Huntress, Sitzungen zu widerrufen und Passwörter zurückzusetzen, Entra-Geräte zu prüfen, MFA-Methoden zu kontrollieren, nach unerwarteten Posteingangsregeln oder neuen Unternehmensanwendungen zu suchen und den Device-Code-Ablauf per Conditional Access einzuschränken.

„Conditional-Access-Richtlinien können einige Sicherheitslücken schließen, die MFA nicht abdeckt – vorausgesetzt, sie sind richtig umgesetzt", so die Huntress-Forscher. Unternehmen sollten in solchen Richtlinien MFA für alle Benutzer, alle Cloud-Anwendungen und alle Client-App-Typen ausnahmslos verlangen oder den Zugriff blockieren.