Im April 2024 stellte Mandiant fest, dass sich jemand in die Snowflake-Instanzen von über 165 Unternehmen eingeloggt hatte. Nicht durch einen Exploit und nicht durch eine Zero-Day-Schwachstelle, sondern schlicht mit Benutzername und Passwort. Die Zugangsdaten stammten von Infostealern, die teilweise seit 2020 auf Contractor-Geräten liefen, und das Ergebnis war einer der grössten Cloud-Datenverluste der Geschichte.
Die Infostealer-Pipeline
Die Gruppe, die Mandiant als UNC5537 trackt, hatte eine bemerkenswert einfache Strategie: statt selbst in Systeme einzubrechen, kauften sie fertige Zugangsdaten auf dem Schwarzmarkt. Zu diesem Zeitpunkt kursierten dort Millionen von Credentials, die über Jahre hinweg von Malware-Familien wie Vidar, Redline, LummaC2, RisePro, Racoon Stealer und MetaStealer aus Browser-Passwort-Speichern abgezogen worden waren.
Das eigentliche Problem lag dabei nicht bei den Unternehmensrechnern selbst, sondern bei privaten Laptops und Contractor-Geräten, auf denen sich Mitarbeiter im Browser bei Snowflake angemeldet hatten. Ein Contractor-Laptop mit Vidar-Malware, der seit November 2020 Credentials absaugte, und drei Jahre später meldete sich jemand mit genau diesen Zugangsdaten bei AT&T, Ticketmaster oder der Santander Bank an.
79.7 Prozent der kompromittierten Accounts hatten bereits früher exponierte Zugangsdaten, also Credentials die seit Jahren im Umlauf waren, nie geändert und ohne aktiviertes MFA.
Wie UNC5537 vorging
Die Angreifer verwendeten ein eigenes Reconnaissance-Tool namens FROSTBITE (eine .NET- und Java-Anwendung), um Snowflake-Instanzen aufzuklären, und danach DBeaver Ultimate für die eigentlichen SQL-Queries. Die Vorgehensweise war methodisch und immer gleich:
Zuerst SHOW TABLES, um die Datenbankstruktur zu verstehen. Dann SELECT * um die Daten zu sichten. Danach CREATE TEMPORARY STAGE, um einen temporären Speicherbereich innerhalb von Snowflake anzulegen. COPY INTO mit GZIP-Kompression, um die Daten in diesen Stage zu kopieren. Und schliesslich GET, um alles auf lokale Systeme herunterzuladen. Von dort ging alles zu MEGA.
Die gesamte Infrastruktur war auf Anonymität ausgelegt, mit Mullvad und PIA als VPN-Dienste, VPS-Servern bei ALEXHOST SRL in Moldawien und MEGA als Cloud-Speicher, wobei die Angreifer keine eigene Infrastruktur betrieben sondern ausschliesslich gemietete und anonyme Dienste nutzten.
Das Ausmass
Die Dimensionen dieses Vorfalls waren selbst nach den Massstäben grösserer Datenlecks aussergewöhnlich: 560 Millionen Kundendatensätze bei Ticketmaster, 110 Millionen bei AT&T, 30 Millionen bei der Santander Bank. Insgesamt wurden mindestens 165 Organisationen benachrichtigt, dass ihre Snowflake-Daten kompromittiert worden waren.
Die Timeline verschärft die Problematik zusätzlich: die frühesten Infostealer-Infektionen gehen auf November 2020 zurück, was bedeutet dass die Credentials über drei Jahre lang offen zugänglich waren, nie rotiert wurden und niemand MFA aktiviert hatte. Im April 2024 wurden die ersten Kompromittierungen entdeckt, am 22. Mai kontaktierte Mandiant Snowflake, und am 10. Juni erfolgte die öffentliche Bekanntmachung.
Im Oktober 2024 wurde Alexander „Connor“ Moucka in Kanada verhaftet. John Binns war bereits im Mai 2024 in der Türkei festgenommen worden.
Angriffsweg und Kontrollen
Was diesen Fall aus sicherheitstechnischer Sicht besonders bemerkenswert macht: Snowflake als Plattform wurde nie gehackt, und es gab keine Schwachstelle im Produkt. Die Angreifer haben sich mit gültigen Benutzernamen und Passwörtern eingeloggt, weil die Kunden kein MFA aktiviert hatten, Passwörter nie rotiert wurden und keine IP Allow Lists konfiguriert waren, obwohl diese drei Basismassnahmen zum Standardrepertoire jeder Cloud-Sicherheitskonfiguration gehören.
Schritt 1: Infostealer-Infektion
Malware wie Vidar, Redline oder LummaC2 gelangt auf Contractor- oder Privatgeräte und stiehlt Zugangsdaten aus Browsern. EDR und Application Control auf allen Geräten, einschliesslich der Geräte von Contractors, hätte die Infektion verhindert oder zumindest erkannt.
Schritt 2: Credential Harvesting
Gestohlene Snowflake-Logins landen auf dem Schwarzmarkt. Password Manager statt Browser-Speicherung reduzieren die Angriffsfläche erheblich, weil Infostealer in der Regel Browser-Datenbanken auslesen, nicht den Vault eines dedizierten Passwort-Managers.
Schritt 3: Snowflake Login ohne MFA
Die Angreifer loggten sich mit den gestohlenen Credentials ein, wobei 79.7 Prozent der betroffenen Accounts kein MFA aktiviert hatten. Obligatorisches MFA und IP Allow Lists hätten den Zugang blockiert, selbst mit gültigen Credentials.
Schritt 4: Reconnaissance mit FROSTBITE
Datenbanken und Tabellen werden aufgelistet, SQL-Queries über DBeaver ausgeführt. Anomalie-Erkennung und Session Monitoring hätten die ungewöhnlichen Zugriffsmuster erkannt: ein neues Gerät, eine neue IP, unübliche Query-Patterns.
Schritt 5: Data Staging
Die Daten werden mit COPY INTO und GZIP-Kompression in temporäre Stages kopiert. DLP-Policies und Query Auditing können erkennen wenn jemand ganze Tabellen in einen Stage kopiert, da dies kein normales Nutzungsverhalten darstellt.
Schritt 6: Exfiltration
Der GET-Befehl lädt die Daten auf lokale Systeme herunter, danach erfolgt der Upload zu MEGA. Egress Filtering und Datenklassifizierung setzen Grenzen für die Menge an Daten die eine Snowflake-Instanz verlassen dürfen.
Fazit
Dieser Fall ist ein Lehrstück darüber, wie vermeintlich kleine Versäumnisse kaskadieren können. Keiner der 165 betroffenen Kunden hatte alle drei Basismassnahmen (MFA, Passwort-Rotation, IP-Einschränkungen) aktiv, und Snowflake hat als Reaktion MFA für alle neuen Accounts obligatorisch gemacht, was für die bestehenden Kunden allerdings zu spät kam.
Das grundlegende Problem, das dieser Vorfall offenlegt, betrifft Infostealer-Malware auf Geräten von Drittanbietern und Contractors, einen blinden Fleck den die meisten Unternehmen nicht auf dem Radar haben. Bei Credentials die seit 2020 im Umlauf waren und nie rotiert wurden, brauchte es keinen ausgeklügelten Angriff sondern lediglich einen simplen Login-Versuch mit Zugangsdaten die seit Jahren frei verfügbar waren..
Möchten Sie wissen, ob Ihre Cloud-Zugänge sicher konfiguriert sind? Kontaktieren Sie uns für ein Cloud Security Assessment.