Am 4. April 2026 meldete Anodot weitreichende Ausfälle bei seinen Snowflake-, Amazon S3- und Amazon Kinesis-Konnektoren. Am 7. April berichtete BleepingComputer, dass von Anodot gestohlene Authentifizierungstoken genutzt wurden, um auf Daten in mehr als einem Dutzend Kundenumgebungen von Anodot zuzugreifen. Am 11. April hatte ShinyHunters Rockstar Games auf seiner Leak-Seite mit einer Frist bis zum 14. April genannt. Die Frist lief ab. Es kam zu einem teilweisen Datenleck.
Dies war die zweite große Datenklau-Kampagne im Zusammenhang mit Snowflake innerhalb von zwei Jahren, und der Einstiegspunkt war weder ein kompromittierter Benutzer noch offengelegte Anmeldedaten. Ein SaaS-Integrationsanbieter wurde gehackt, Authentifizierungstoken wurden entwendet, und diese Token wurden anschließend genutzt, um auf Daten in mehreren Kundenumgebungen zuzugreifen.
Von außen betrachtet scheint alles in Ordnung zu sein. Die betroffenen Systeme haben sich wie erwartet verhalten. Der Zugriff erfolgte über gültige Mechanismen, und die Aktivitäten verliefen über legitime Kanäle. Deshalb wiederholt sich diese Art von Vorfall immer wieder, ohne dass die erforderlichen Maßnahmen ergriffen werden.
Hier geht es nicht um Snowflake
Wenn man auf den Vorfall aus dem Jahr 2024 zurückblickt, den Mandiant unter der Bezeichnung UNC5537 dokumentiert hat, kommt einem das Muster bereits bekannt vor. Die Angreifer nutzten gestohlene Zugangsdaten, die sie aus den Protokollen von Infostealern gewonnen hatten, um auf Snowflake-Instanzen zuzugreifen und direkt an die Daten zu gelangen. Bei keinem der angegriffenen Konten war die Zwei-Faktor-Authentifizierung (MFA) aktiviert. 79,7 % der verwendeten Zugangsdaten waren zuvor durch Infostealer kompromittiert worden.
Was sich im Jahr 2026 geändert hat, ist nicht das Ergebnis, sondern der Weg dorthin.
Bei dem früheren Vorfall nutzten die Angreifer Zugangsdaten, um sich Zugang zu verschaffen, und Token, um sich dort zu halten. Beim Anodot-Vorfall begannen sie direkt mit den Token.
Der direkte Zugriff wurde durch indirekten Zugriff über Integrationen ersetzt. Der Angreifer muss nicht mehr auf eine Weise mit der Umgebung interagieren, die offensichtliche Signale erzeugt. Die Plattform wird zum letzten Glied in der Kette und nicht mehr zum Ausgangspunkt des Problems.
Dies deckt sich mit den Erkenntnissen aus den jüngsten Vorfällen in der Lieferkette, bei denen die anfängliche Kompromittierung weit weniger ins Gewicht fällt als die Art und Weise, wie der Zugriff anschließend genutzt wird.
Wenn man dies als ein Problem von Snowflake betrachtet, übersieht man den zugrunde liegenden Wandel. Das gleiche Muster zeigt sich in den Bereichen SaaS, cloud und Datenplattformen. Der gemeinsame Faktor ist nicht der Anbieter. Es ist die Art und Weise, wie Zugriff gewährt und systemübergreifend wiederverwendet wird.
Die Lieferkette ist nun betriebsbereit
Früher wurden Integrationen als reine „Technik“ betrachtet. Sie transportieren Daten, automatisieren Arbeitsabläufe und verbinden Systeme, die andernfalls voneinander isoliert blieben.
In der Praxis fungieren sie nun als verteilte Zugriffsebenen.
Eine einzige Integration kann langlebige Token verwalten, in mehreren Umgebungen eingesetzt werden und Aktionen im Namen von Benutzern oder Diensten ausführen. Wenn diese Integration kompromittiert wird, muss der Angreifer keinen eigenen Zugang schaffen. Er nutzt einen bereits bestehenden und vertrauenswürdigen Zugang.
Ein ähnliches Muster lässt sich bei Angriffen auf die Lieferkette beobachten, bei denen die Ausführung innerhalb einer vertrauenswürdigen Umgebung unmittelbar zu einem nutzbaren Zugriff führt, der dann systemübergreifend wiederverwendet wird.
Dieser Zugang umfasst häufig:
- Datenplattformen
- Speichersysteme
- SaaS-Anwendungen
Die Datenübertragung zwischen diesen Systemen erfordert keine neuen Techniken. Sie erfolgt über dieselben Wege, die das Unternehmen täglich nutzt.
An diesem Punkt muss der Angreifer keine seitlichen Bewegungen mehr ausführen. Die Architektur übernimmt das für ihn.
Die Token haben still und leise die letzte Hürde beseitigt
Der Übergang von Anmeldedaten zu Tokens ist kaum wahrnehmbar, verändert jedoch die Funktionsweise des Zugriffs.
Token sind auf Langlebigkeit und Automatisierung ausgelegt. Sie werden einmalig ausgestellt und können ohne wiederholte Authentifizierung wiederverwendet werden. Sie werden über APIs gesteuert, oft ohne Benutzereingriff, und überdauern in der Regel Passwortwechsel oder das Zurücksetzen von Sitzungen.
In vielen Umgebungen werden sie zudem nur unzureichend erfasst. Anmeldevorgänge werden genau überwacht. Die Token-Nutzung wird hingegen oft als Hintergrundaktivität betrachtet.
Im Zusammenhang mit den Snowflake-Hackerangriffen im Jahr 2024 beschrieb einer der Angreifer die Situation auf eine Weise, die man kaum ignorieren kann:
Ich kann immer noch Befehle ausführen, weil ich für jedes Konto das „masterToken“ habe 🤣
Ellyel8
Das Wesentliche ist nicht das Zitat an sich. Es geht darum, wie dieser Zugriff aufrechterhalten wurde. Durch das Lesen öffentlich zugänglicher Dokumentationen erkannte der Angreifer, wie sich die Tokens verhielten, und nutzte sie, um auch nach der Sicherung der Konten weiterhin Zugriff zu behalten.
Durch die Entfernung des Angreifers wurde der Zugriff nicht aufgehoben.
Dadurch entsteht eine Situation, in der der Zugriff auch nach der Durchführung von Abhilfemaßnahmen weiterhin möglich ist. Das Benutzerkonto ist zwar gesichert, doch das mit einer Integration verknüpfte Token bleibt aktiv und gewährt weiterhin denselben Zugriff.
Aus Sicht eines Angreifers ist dies eine sauberere und zuverlässigere Methode zur Persistenz als jede andere, bei der malware zum Einsatz kommt.
Dieser Account (von dem das oben zitierte „Ich kann immer noch Befehle ausführen“ stammt) wurde von Connor Riley Moucka betrieben, der im November 2024 in Kanada festgenommen wurde. Sein Prozess ist für den 19. Oktober 2026 angesetzt. Der Zugang, mit dem er geprahlt hatte, bestand trotz seiner Festnahme weiter, da Token nicht vom Betreiber abhängen, der sie geprägt hat.
Warum diese Aktivität sich gut einfügt
Aus Sicht der Erkennung gibt es hier kaum Anzeichen, die einem herkömmlichen Einbruch ähneln.
Die in der Umgebung zu beobachtenden Vorgänge entsprechen dem normalen Betriebsablauf:
- Authentifizierungsereignisse sind gültig
- API-Aufrufe folgen den erwarteten Mustern
- Integrationen verhalten sich innerhalb ihres vorgesehenen Anwendungsbereichs
Was fehlt, ist der Kontext, der diese Aktionen systemübergreifend miteinander verknüpft.
Ein Datenzugriff, der für sich genommen harmlos erscheint, kann verdächtig werden, wenn man ihn im Zusammenhang mit Aktivitäten auf einer anderen Plattform betrachtet. Ein von einer Integration verwendetes Token mag zunächst harmlos wirken, bis es auf Daten in einer Weise zugreift, die nicht dem bisherigen Verhalten entspricht.
Die meisten Tools sind nicht darauf ausgelegt, dieses Gesamtbild systemübergreifend zusammenzufügen. Sie arbeiten innerhalb einer einzigen Domäne, was bedeutet, dass sie einzelne Aktionen validieren, aber selten hinterfragen, wie diese Aktionen miteinander in Zusammenhang stehen.
Genau diese Lücke nutzt diese Art von Angriff aus.
Ein wiederkehrendes Muster, kein Einzelfall
Die Aktivität wurde mit der Erpressergruppe „ShinyHunters“ in Verbindung gebracht, die gestohlene Daten in großem Umfang über mehrere operativ voneinander getrennte Teams hinweg zu Geld macht. Die konkreten Täter sind dabei weniger wichtig als die Konsistenz der Vorgehensweise.
In der Studie von Resecurity vom Januar 2026 werden die „ShinyHunters“ als gemeinsamer Deckname beschrieben – die Berichterstattung weist darauf hin, dass sich die Namensgebung „sehr häufig und absichtlich ändert, in der Regel durch die Akteure selbst, die die Rückverfolgbarkeit verschleiern wollen“. GTIG verfolgt die aktuellen Aktivitäten in mindestens drei separaten Clustern: UNC6240 ist für Erpressungen unter dieser Marke zuständig; UNC6661 und UNC6671 führten im Januar 2026 parallele Vishing-Kampagnen gegen Identitätsanbieter durch, wobei unterschiedliche Registrare (NICENIC und Tucows) und unterschiedliche Erpressungstöne auf separate Betreiber hindeuten. Die Aktivitäten von Anodot/Snowflake unterscheiden sich wiederum operativ. Gleiche Marke. Verschiedene Teams.
Was all diesen Fällen gemeinsam ist, macht die Vorgehensweise aus: Im Fokus steht die Authentifizierung der Zielperson, nicht die Infrastruktur. Jeder Angreifer, der Zugriff auf Tokens einer weit verbreiteten Integrationsplattform hat, kann dasselbe Ergebnis erzielen. Da immer mehr Unternehmen auf miteinander vernetzte SaaS-Dienste setzen, nimmt die Zahl der indirekten Zugriffswege weiter zu.
Wir haben auch gesehen, wie sich diese Art der Wiederverwendung von Zugriffsrechten zu einem stärker automatisierten und sich selbst verstärkenden Prozess entwickeln kann, bei dem kompromittierte Vertrauensbeziehungen genutzt werden, um die Reichweite ohne direkte Interaktion zu vergrößern.
Gleichzeitig wenden sich Angreifer zunehmend Methoden zu, die weniger Aufwand erfordern und weniger Spuren hinterlassen. Die Kompromittierung eines Drittanbieters oder das Sammeln von Tokens in großem Umfang ist rentabler als der Versuch, in einzelne Umgebungen einzudringen. Aus diesem Grund treten Vorfälle im Zusammenhang mit der Lieferkette immer häufiger auf. Sie bieten Reichweite, Konsistenz und ein Maß an Unauffälligkeit, das der Art und Weise entspricht, wie moderne Umgebungen aufgebaut sind.
Der Angriff ist nicht verdeckt. Er ist fragmentiert.
Den Sicherheitsteams entgeht diese Aktivität nicht. Sie bekommen jeden Tag Teile davon mit:
- Eine Identitätsplattform protokolliert eine erfolgreiche Authentifizierung.
- Eine SaaS-Anwendung erfasst die ordnungsgemäße Nutzung der API.
- Eine Datenplattform zeigt erwartete Abfragen und Exporte an.
Jedes System wertet das aus, was es beobachtet. Keines von ihnen stellt einen Zusammenhang zwischen diesen Handlungen her.
An dieser Stelle beginnt dieses Modell zu versagen.
Der Angreifer muss nicht bei jeder einzelnen Sicherheitskontrolle unentdeckt bleiben. Es reicht aus, wenn jede Kontrolle nur ihren eigenen Teil der Aktivität überprüft. Token erleichtern dies. Integrationen ermöglichen eine systemübergreifende Umsetzung. Wenn sich das Muster erst einmal herausgebildet hat, erstreckt es sich über Domänen, die selten gemeinsam analysiert werden.
Deshalb wirken Vorfälle wie dieser eingedämmt, obwohl weiterhin Daten aus der Umgebung abfließen.
Was kann man dagegen tun?
Die herkömmlichen Gegenmaßnahmen für die „Snowflake“-Kampagne von 2024 (Durchsetzung von MFA für cloud , regelmäßige Änderung gestohlener Anmeldedaten, Aufnahme des Data Warehouse in die Netzwerk-Whitelist) sind nach wie vor richtig, decken diesen Zugriffspfad jedoch nicht mehr ab. Von Anbietern ausgestellte Service-Token enthalten keine MFA-Faktoren. Kunden können diese nicht regelmäßig ändern; dies ist nur dem Anbieter möglich. Das Hardening-Playbook für 2024 schützt vor der Vorgehensweise von 2024. Die Vorgehensweise von 2026 erfordert eine andere Ebene.
Diese Ebene bildet die Grundlage dafür, was jede Instanz – Benutzer, Dienstinstanz, OAuth-Client – im Laufe der Zeit tatsächlich tut, und löst einen Alarm aus, wenn sich das Muster auf mehreren Achsen gleichzeitig verändert.
Drei Fragen, die Sie sich in Bezug auf Ihr eigenes Umfeld stellen sollten:
- Wissen Sie bei jeder SaaS-Integration eines Drittanbieters mit mandantenübergreifendem authentifiziertem Lesezugriff, wie die normale API-Nutzungshäufigkeit und das Ressourcenmuster aussehen, aufgeschlüsselt nach jedem einzelnen Prinzipal?
- Wann wurde das jeweilige Anbietertoken zuletzt überprüft?
- Wann wurde jedes einzelne Gerät zuletzt ausgetauscht – durch den Anbieter?
Das Vectra AI AI-E-Book „Mind Your Attack Gaps“ behandelt die Sicherheitslücke „Authentication succeeds“, die in dieser Kampagne ausgenutzt wird. Wenn Sie in einem einzigen Gespräch erfahren möchten, wie sich die Vorgehensweise der Angreifer in der Lieferkette auf Ihre spezifische Infrastruktur übertragen lässt, wenden Sie sich bitte an uns.