Am 11. April 2026 behauptete ein Beitrag auf der Leak-Website „ShinyHunters“, rund 80 Millionen Datensätze von Rockstar Games gestohlen zu haben. Der Zugriff erfolgte nicht über Rockstar. Es war Anodot, ein SaaS-Analytics-Anbieter, der Teil der Lieferkette von Rockstar ist. Gestohlene Anodot-Authentifizierungstoken wurden verwendet, um nachgelagerte Datenplattformen abzufragen. Ein anderes Opfer.
Anderer Anbieter. Gleiches Muster.
Entscheidend ist nicht die Plattform, auf der die Auswirkungen letztendlich zu spüren waren. Entscheidend ist, wie der Zugang erlangt und missbraucht wurde.
Alle paar Monate taucht eine neue Schlagzeile auf
Die Schlagzeilen lauten immer wieder:
- 2024: Snowflake-Kunden – anhand von Anmeldedaten, die aus den Protokollen eines Infostealers stammen, die bis ins Jahr 2020 zurückreichen.
- August 2025: Salesforce- Kunden – über OAuth-Token, die aus Salesloft Drift gestohlen wurden. Google schätzte, dass bei diesem einzelnen Anbieterwechsel potenziell mehr als 700 nachgelagerte Organisationen betroffen waren.
- November 2025: Erneut Salesforce – diesmal über Gainsight-OAuth-Token, von denen mehr als 200 Instanzen betroffen sind.
- April 2026: Wieder Snowflake , über Anodot-Token.
- Juni 2026: Erneut Salesforce-Kunden , über das Integrations-Backend von Klue. Zur Authentifizierung bei den Systemen von Klue wurden veraltete, nie aktualisierte Anmeldedaten eines Dienstkontos verwendet; ein bösartiges Code-Update sammelte anschließend OAuth-Token ein, die Klue mit den Salesforce-, Gong-, HubSpot- und Slack-Instanzen der Kunden verbanden. Automatisierte Skripte fragten die Salesforce-REST-API 24 Stunden lang ununterbrochen mit etwa 1.000 Aufrufen pro 15 Minuten ab. Salesforce deaktivierte die Klue-Battlecards-Integration am 11. Juni 2026. Icarus führte den Angriff durch; ShinyHunters bekannte sich in der Erpressungsphase dazu. Microsoft verfolgt diese Aktivität unter der Bezeichnung Storm-3138.
Verschiedene Einstiegsmöglichkeiten. Verschiedene Plattformen.
Das Muster bleibt dasselbe, da ShinyHunters keine einzelne Gruppe ist. Es handelt sich um eine Bezeichnung, die zum Zeitpunkt der Erpressung verwendet wird.
Der Klue-Hack im Juni 2026 veranschaulicht dies genau. Icarus führte den Angriff durch. ShinyHunters bekannte sich in der Erpressungsphase dazu. Anderer Betreiber, gleiche Marke. Das Salesforce-Auditprotokoll zeichnete durchgehend legitime API-Aufrufe verbundener Anwendungen auf. Nichts in der Kundenumgebung deutete auf einen laufenden Angriff hin.
Wenn Sie davon ausgehen, dass es sich um einen einzigen Angreifer handelt, laufen Sie Gefahr, am falschen Ende zu suchen. Beobachten Sie das Verhalten, nicht die Marke.
Der eigentliche rote Faden
Bei den Kampagnen, die ShinyHunters zugeschrieben werden, tauchen vier verschiedene Zugriffsmethoden immer wieder auf:
- Zur Anmeldung wurden gestohlene Zugangsdaten verwendet
- Social-Engineering-Angriffe über den Helpdesk (Vishing) zum Zurücksetzen der MFA und zum Erlangen von Zugriff
- Missbrauch von OAuth/Tokens durch kompromittierte SaaS-Anbieter
- Falsch konfigurierter Gastzugriff auf SaaS-Endpunkte (Ausnutzung einer Schwachstelle im Salesforce-Aura-Framework durch nicht authentifizierte GraphQL-Abfragen, dokumentiert im Juni 2026)
Unterschiedliche Fähigkeiten, dasselbe Ergebnis: ein berechtigter Zugriff, der sich wie ein legitimer Benutzer oder eine legitime Anwendung verhält.
In der öffentlichen Berichterstattung stehen Snowflake oder Salesforce im Vordergrund, da die Daten letztendlich dort gespeichert werden. Der Zugangsweg ist jedoch die Identität.
In den meisten Unternehmensumgebungen wird diese Identität in Plattformen wie Microsoft 365 eingebunden. Dadurch ist M365 einer der ersten Orte, an denen diese Aktivität sichtbar wird. Nicht, weil es das Ziel ist, sondern weil dort die kompromittierte Identität zum Einsatz kommt.
Anatomie eines Angriffs im Stil von ShinyHunters
Unabhängig von der Art des Zugriffs verläuft der Angriff nach einem ähnlichen Muster:
- Zugriff: Melden Sie sich mit gültigen Anmeldedaten oder Tokens an.
- Einrichten: Stellen Sie sicher, dass dieser Zugriff dauerhaft besteht.
- Erweitern: Daten in verschiedenen SaaS-Anwendungen untersuchen.
- Exfiltration: Daten aus nachgelagerten Systemenextrahieren .
Snowflake und ähnliche Plattformen bilden den letzten Schritt. Alles, was für die Früherkennung entscheidend ist, geschieht bereits davor.
Was man tatsächlich vor den Phasen des Aufpralls sehen kann
Erster Zugriff: eine „normale“ Anmeldung, die nicht normal ist
Die Anmeldung ist erfolgreich. Aber:
- Der Standort ist neu
- Die Verbindung stammt aus einer VPN- oder Proxy-Infrastruktur wie Mullvad, Oxylabs, NetNut oder einem Tor-Ausgangsknoten.
- Die Aktivitäten nach der Anmeldung weichen vom üblichen Verhaltensmuster des Benutzers ab.
Bei einem Identitätsanbieter wie Entra ID scheint dies eine legitime, erfolgreiche Anmeldung zu sein. Betrachtet man den Kontext jedoch genauer, ist dies nicht der Fall.
Persistenz: Den Zugriff dauerhaft sichern
Sobald er drinnen ist, sorgt der Schauspieler dafür, dass er zurückkehren kann:
- Neue MFA-Methoden aufgenommen
- Neue Geräte registriert
- Oauth-Anwendungen, denen Zugriff gewährt wurde
Jede einzelne Aktion ist für sich genommen legitim. Zusammengenommen erzählen sie jedoch in den Minuten nach einer neuen Anmeldung eine ganz andere Geschichte.
Erkundung: Der Weg zum SaaS
Bevor sie auf die Data Warehouses zugreifen, bewegen sich Angreifer durch Systeme, die Mitarbeiter täglich nutzen. Für viele Unternehmen bedeutet das Microsoft 365 oder ähnliche SaaS-Plattformen:
- Auflistung von SharePoints und OneDrive
- Zugriff auf Dokumentbibliotheken, mit denen der Benutzer noch nie zu tun hatte
- Stichwortsuche nach sensiblen Inhalten
- Umfassender Dateizugriff
In dieser Phase stellt sich der Angreifer eine einfache Frage: Auf welche Daten kann diese kompromittierte Identität zugreifen?
Anschließend wird die Lösung auf andere SaaS-Plattformen und nachgelagerte Datensysteme ausgeweitet.
Unterschiedliche Methoden, gleiche Signale
Dieses Muster lässt sich bei allen vier Ansätzen beobachten:
- Gestohlene Zugangsdaten (2024): ungewöhnliche, aber erfolgreiche Anmeldung
- Vishing und Umgehung der Multi-Faktor-Authentifizierung (2025–2026): Nach der Anmeldung folgen rasche Maßnahmen zur Aufrechterhaltung des Zugriffs sowie die Erfassung von SaaS-Diensten.
- Sicherheitslücke bei Anbieter/OAuth (2025–2026): Vertrauenswürdige Anwendungen verhalten sich ungewöhnlich.
- Fehlerhafte Konfiguration des Gastzugriffs (2026): Zahlreiche API-Aufrufe aus einem nicht authentifizierten Gastkontext. Es liegt kein Anmeldeereignis vor, das eine Warnung auslösen könnte.
Der Einstiegspunkt ändert sich. Das Verhalten nach der Authentifizierung bleibt unverändert.
Fallstudie: Der Datenverstoß bei Klue, Juni 2026
Der Hackerangriff auf Klue ist das deutlichste aktuelle Beispiel für den Ablauf eines Angriffs über die Lieferkette. Der Angreifer (der als „Icarus“ identifiziert wurde und später von ShinyHunters im Rahmen einer Erpressungsaktion zu sich selbst bekannt gab) nutzte veraltete, nie aktualisierte Anmeldedaten eines Dienstkontos, um sich beim Integrations-Backend von Klue zu authentifizieren. Es gab keinen Exploit. Die Anmeldedaten waren gültig und wurden von der Organisation selbst ausgestellt. Bei der Anmeldung gab es keine Auffälligkeiten.
Ein Update mit bösartigem Code erfasste anschließend OAuth-Token , die Klue mit den Salesforce-, Gong-, HubSpot- und Slack-Instanzen der Kunden verbanden. Die Token wurden über verschlüsselte Kanäle übertragen. Es sah aus wie eine routinemäßige Code-Bereitstellung. Keine malware . Von dort aus fragten automatisierte Python-Skripte die Salesforce-REST-API 24 Stunden lang ununterbrochen mit etwa 1.000 Aufrufen pro 15 Minuten ab. Jeder API-Aufruf wurde mit einem gültigen Token authentifiziert und war vom normalen Integrationsdatenverkehr nicht zu unterscheiden. CRM-Daten wurden in großem Umfang abgezogen.
Salesforce hat die Integration von Klue Battlecards am 11. Juni deaktiviert. Zu den benachrichtigten Unternehmen gehörten Recorded Future, Tanium, Jamf und Huntress. Microsoft hat den Cluster in seiner Mitteilung vom 13. Juli 2026 als „Storm-3138“ erfasst .
Zur Frage der Zuordnung: Die obige Analyse ordnet dies korrekt Icarus als Betreiber zu. Dass ShinyHunters bei der Erpressung die Verantwortung dafür übernommen hat, stellt keine Korrektur dieser Zuordnung dar. Genau darum geht es. Die Zuordnung erfolgt im Moment der Erpressung durch denjenigen, der die Operation durchführt. Belassen Sie die Zuordnung zum Icarus-Operator auf der Folie und fügen Sie einen Hinweis hinzu, dass ShinyHunters bei der Erpressung die Verantwortung übernommen hat, denn genau auf dieser Unterscheidung basiert das Argument „Verfolge das Verhalten, nicht die Marke“.
Wo Vectra AI
Die Kampagnen von ShinyHunters sind erfolgreich, weil sie legitime Zugangsdaten nutzen: echte Anmeldedaten, echte MFA-Abläufe, echte OAuth-Token, echte Anwendungen. Die meisten Sicherheitsmaßnahmen sind darauf ausgelegt, Angreifer vor der Authentifizierung zu stoppen. Diese Kampagnen sind jedoch danach erfolgreich.
Vectra AI das Verhalten von Angreifern nach erfolgreicher Authentifizierung – über Identitäts-, SaaS-, cloud und Netzwerkbereiche hinweg. Die Frage lautet nicht:„Wie wurde der Zugriff erlangt?“, sondern: „Stimmen die Handlungen der Identität mit ihrem Verhaltensprofil überein?“
Wie die Erkennung mit dem Angriffsmuster korreliert
Zugriff: Eine erfolgreiche Anmeldung von einem neuen Standort aus oder über eine Proxy-Infrastruktur, die nicht mit der Basiskonfiguration der Identität übereinstimmt.
Einrichten: MFA-Methoden hinzugefügt, Geräte registriert, OAuth-Anwendungen autorisiert – unmittelbar nach der Anmeldung.
Erweitern: Aktivitäten werden über Microsoft 365, Salesforce und andere SaaS-Lösungen hinweg abgeglichen, wodurch Kundenprofile sichtbar werden, die auf ganz neue Weise mit Ihrem Unternehmen interagieren.
Exfiltration: Massen-Downloads und API-Extraktion traten als Abschluss einer Abfolge zutage, nicht als isolierte Ereignisse.
Warum dies bei allen Methoden funktioniert
Es spielt keine Rolle, wie der Zugriff erlangt wurde: gestohlene Anmeldedaten, ein Anruf beim Helpdesk oder ein kompromittiertes Anbietertoken. Der Angreifer muss sich dennoch anmelden, eine dauerhafte Präsenz aufbauen, das System erkunden und Daten abziehen. Dieses Verhaltensmuster ist unvermeidlich. Genau dafür wurde Vectra entwickelt.
Die Erkennungslücke schließen
Die Standardempfehlungen sind nach wie vor wichtig: phishing MFA, regelmäßige Änderung von Zugangsdaten, Überprüfung der OAuth-Bereiche, Identitätsprüfung durch den Helpdesk (siehe die Empfehlungen zur Absicherung in GTIGs UNC6040 und die FLASH-Empfehlung des FBI). Das allein reicht jedoch nicht mehr aus. Moderne Angriffe sind darauf ausgelegt, diese Sicherheitsmaßnahmen zu umgehen.
Die Erkennung funktioniert einwandfrei. Sie ist nur unvollständig.
ShinyHunters ist keine einzelne Gruppe. Es handelt sich um ein Angriffsmuster, das auf einer Idee basiert: Gelingt die Authentifizierung, kann sich der Angreifer als harmlose Identität ausgeben.
Die ersten Anzeichen tauchen nicht in der in den Schlagzeilen genannten Datenplattform auf. Sie zeigen sich vielmehr in Identitäts- und SaaS-Plattformen, in denen der Angreifer zunächst aktiv werden muss. Das Problem ist nicht die Sichtbarkeit. Das Problem ist, dass die Erkennung an der falschen Stelle des Angriffs beginnt.
In meinem E-Book „Mind Your Attack Gaps“ beschreibe ich drei Sicherheitslücken bei der Erkennung. ShinyHunters nutzt Lücke 2: Die Authentifizierung ist erfolgreich. Echte Anmeldedaten, echte Einmalcodes, echte OAuth-Token, echte Sitzungscookies. Das Audit-Protokoll verzeichnet eine erfolgreiche Anmeldung.
Das „Hardening Playbook“ für 2024 ist zwar nach wie vor gültig, deckt jedoch den Zugriffspfad nicht mehr ab.