NovaCookies: Phishing-Dienst stiehlt Microsoft-365-Sitzungen für 320 Dollar im Monat

Der Dienst NovaCookies wird laut einer Analyse des Sicherheitsexpertern Shachar Gritzmander (Island) als Abonnement über Telegram vertrieben. Für 320 Dollar monatlich oder 200 Dollar für vierzehn Tage erhalten Käufer demnach Zugang zu einem sogenannten Adversary-in-the-Middle-Proxy (AiTM), der sich in Echtzeit zwischen Nutzer und Microsoft 365 schaltet. Der Proxy leitet den gesamten Anmeldevorgang – einschließlich Passwort und Mehrfaktor-Authentifizierung – an die echten Microsoft-Server weiter und fängt anschließend das Sitzungs-Cookie ab. Damit lässt sich eine abgeschlossene Anmeldung übernehmen, ohne Passwort oder Einmalcode selbst zu kennen.

Im Paket sollen Domains, Hosting sowie Redirect-Optionen über Google- oder Microsoft-Endpunkte enthalten sein. Ein über Telegram verschicktes Selbstlöschfoto zeigte nach Angaben des Absenders ein Käuferprofil mit Funktionen wie Cookie-Link-Kauf, Bestellungen und Support. Die Forscher betonen, dass sich weder die Identität des Verkäufers noch konkrete Transaktionen unabhängig bestätigen ließen. Island stellt selbst einen Enterprise-Browser her und hat damit ein kommerzielles Interesse am Thema Browser-Sicherheit – die technischen Befunde des Berichts stützen sich jedoch auf dokumentierte Kampagnenartefakte und Code-Analysen.

Was von außen wie eine Reihe unzusammenhängender Phishing-Vorfälle aussieht, kann somit von verschiedenen Käufern stammen, die dasselbe gemietete Produkt einsetzen. Die Attribution einzelner Kampagnen muss daher zwischen dem Dienst, dem werbenden Konto und dem jeweiligen Kunden unterscheiden.

So läuft ein NovaCookies-Angriff ab

Die Island-Forscher beschreiben eine mehrstufige Angriffskette, bei der jeder einzelne Schritt für sich vertrauenswürdig wirkt:

1. Das Opfer erhält eine E-Mail über einen legitimen Dienst – in der stärksten beobachteten Variante eine echte Docusign-Benachrichtigung, die sämtliche Absenderprüfungen besteht.
2. Die E-Mail öffnet ein echtes Docusign-Dokument im regulären Viewer. Das Dokument selbst ist jedoch gefälscht: Es imitiert eine Freigabebenachrichtigung und enthält den schädlichen Link unterhalb der Ebene, die E-Mail-Sicherheitsprodukte typischerweise inspizieren.
3. Der Klick auf den Link wird über eine echte Microsoft-Autorisierungs-URL (oder in einigen Fällen über Googles Anmelde-Endpunkt) umgeleitet. Die Angreifer nutzen dafür eine von Microsoft im März 2026 dokumentierte OAuth-Redirect-Technik: Eine in einem vom Angreifer kontrollierten Tenant registrierte Anwendung leitet den Browser von Microsofts eigener Domain zur Angreifer-Infrastruktur weiter – ohne dass ein Token ausgestellt wird.
4. Der Browser landet auf einer NovaCookies-Seite, die eine Microsoft-365-Anmeldeoberfläche zeigt. Der Proxy leitet Passwort- und MFA-Eingaben in Echtzeit an Microsoft weiter.
5. Sobald Microsoft eine authentifizierte Sitzung ausstellt, fängt der Proxy das Sitzungs-Cookie ab. Die Angreifer können die Sitzung damit übernehmen.

Weder Docusign noch Microsoft wurden in dieser Kette kompromittiert. Ihre Dienste dienten als Liefer- und Weiterleitungsschichten. Die Sicherheitexperten beobachteten daneben auch Ketten über offenbar kompromittierte legitime Websites oder missbrauchte Online-Dienste.

Einmalcodes greifen nicht – Infrastruktur wächst rasant

Da das Opfer eine echte Authentifizierung abschließt – nur über einen vom Angreifer kontrollierten Vermittler –, bieten gewöhnliche Einmalcodes und Push-Bestätigungen keinen Schutz. Die Code-Analyse der Island-Forscher offenbart ein zweckgebautes Kit mit dedizierten Routinen für Authenticator-Push, Einmalcodes und SMS, das Microsofts interne Methodenbezeichnungen verwendet. In einer beobachteten Instanz akzeptierte die Seite zudem wiederholte Passworteingaben, was auf das Ziel hindeuten könnte, mehrere Kandidaten-Passwörter zu sammeln.

Die Infrastruktur wuchs ab Mitte Mai 2026 sprunghaft. Rund 90 Prozent der identifizierten Zielorganisationen waren mit Ködern auf .vu-Domains verknüpft, deren Hostnamen erkennbare Firmennamen durch eingefügte oder weggelassene Buchstaben verfremden. Beispiele aus dem veröffentlichten Datensatz: „fordmotbvmorcompany[.]vu“ lässt „Ford Motor Company“ erkennen, „morganstbftanley[.]vu“ verzerrt „Morgan Stanley“. Die URLs selbst folgen einem charakteristischen Muster mit Pfadbezeichnungen in wechselnder Groß- und Kleinschreibung wie „PwPt-sHaRe“, „Ms36-AcCeSs“ oder „ClOd-ViEw“ – verkürzte Verweise auf Cloud-Produkte, kombiniert mit Aktionsbegriffen. Diese Muster dienen als Kampagnen-Fingerabdruck.

Das Kit schützt sich gegen automatisierte Analysen durch eine Kombination aus Browser-Prüfungen, Proof-of-Work, kurzlebiger Kontextbindung und konfigurierbaren Laufzeitinspektionen – ein System, das die Forscher eher mit einer Betrugserkennungs-Engine vergleichen als mit einer festen Checkliste. Käufer können die Einstellungen individuell anpassen, weshalb sich verschiedene Bereitstellungen unterschiedlich verhalten.

Die ausgewerteten Kampagnenartefakte umfassen Hunderte Organisationen über mehrere Regionen und Sektoren. Etwa die Hälfte war mit den USA assoziiert, kleinere Konzentrationen entfielen auf Großbritannien, Kanada, Deutschland, Israel und die Vereinigten Arabischen Emirate. Die Island-Forscher weisen darauf hin, dass diese Daten Targeting abbilden, nicht bestätigte Kompromittierungen.

Schutzmaßnahmen

Als strukturelle Abwehr empfehlen die Island-Autoren phishing-resistente Authentifizierung für hochwertige Konten: Passkeys, FIDO2-Sicherheitsschlüssel und andere ursprungsgebundene Anmeldedaten authentifizieren sich nicht gegenüber einer falschen Website und unterbrechen damit die Weiterleitung.

Für die Erkennung raten die Forscher, nicht einzelne Domains zu blockieren, sondern das Produkt dahinter zu identifizieren. Konkret sollten Sicherheitsteams die .vu-Köderstruktur, markenthematische Hostname-Mutationen, die gemischte Groß-/Kleinschreibung in URL-Pfaden und Weiterleitungsketten über Microsoft- oder Google-Endpunkte korrelieren. Jedes einzelne Merkmal sei ein schwaches Signal – in Kombination mit Browser-Verhalten und Reputation ergebe sich ein belastbares Bild.

Wird ein abgeschlossener Relay vermutet, empfehle sich eine gezielte Incident Response: Sitzungen sperren, Zugangsdaten zurücksetzen, Anmeldungen beim Identitätsanbieter prüfen sowie neu hinzugefügte MFA-Methoden, OAuth-Berechtigungen, Weiterleitungsregeln und Posteingangsregeln kontrollieren. Zudem sollten Sicherheitsteams davon ausgehen, dass der Zustellungsweg bis zum letzten Hop vertrauenswürdig erscheinen kann – Links innerhalb von Dokumenten-Viewern und Kollaborationsplattformen verdienen dabei besondere Aufmerksamkeit.

Transparenzhinweis: Dieser Artikel wurde mit Unterstützung von KI-Werkzeugen erstellt. Die inhaltliche Verantwortung, Überprüfung der Fakten und redaktionelle Bearbeitung liegen bei der Redaktion.