14.10
In Cloud-stuff ,Internet ,KI-Generierter Inhalt ,Microsoft ,Security | Tags:
Das hier ist ein vollständig KI generierter Artikel.
Die Ransomware-Kampagne JadePuffer gilt als erste dokumentierte agentische Ransomware, bei der ein KI-Agent grosse Teile der Erpressungsoperation steuert. Neue Analysen von Microsoft zeigen nun, dass derselbe Akteur – intern als Storm-3168 verfolgt – zusätzlich gestohlene Azure-Identitäten missbraucht hat, um Cloud-Ressourcen gezielt zu zerstören und Zugangsdaten für mögliche spätere Datendiebstähle zu sammeln.

Agentische Ransomware trifft auf Cloud-Infrastruktur
JadePuffer wurde im Sommer erstmals bekannt, als Threat Hunter von Sysdig eine Kampagne analysierten, bei der ein grosser Sprachmodell-Agent (LLM) weite Teile des Angriffs automatisiert steuerte: von der Erstkompromittierung über das Eindringen in eine Produktionsdatenbank bis hin zur Datenzerstörung. Microsoft ordnet diese Aktivitäten der Gruppe Storm-3168 zu und sieht nun ein erweitertes Taktikprofil, das sich gezielt gegen Azure-Umgebungen richtet.
In einem aktuellen Bericht beschreibt Microsoft, wie Storm-3168 in einem Zeitraum von rund 18 Stunden zwei Azure-Service-Principals kompromittierte und diese Maschinenidentitäten für umfangreiche Reconnaissance, Ressourcenzugriffe und schliesslich für destruktive Operationen nutzte. Die Aktivitäten deuten stark auf die Vorbereitung eines weiteren Ransomware- oder Erpressungsangriffs hin – auch wenn letztlich keine Lösegeldforderung beobachtet wurde.
Missbrauch von Service Principals: Zwei Rollen, ein Ziel
Die beiden kompromittierten Service Principals gehörten demselben Azure-Tenant, wurden aber klar funktional getrennt eingesetzt: Einer diente der Aufklärung und Ressourcenerkennung, der andere war für Zerstörung und Credential-Diebstahl zuständig. Wie genau Storm-3168 die Service Principals übernehmen konnte, ist nicht abschliessend geklärt. Microsoft verweist jedoch auf einen früheren Sicherheitsvorfall in derselben Organisation, bei dem ein Mitarbeitender Client-IDs, Client-Secrets und Tenant-IDs im Klartext in einem öffentlichen GitHub-Issue veröffentlicht hatte.
Seit Jahresbeginn beobachtete Microsoft zudem wiederholte Scans von Storm-3168-zugeordneten Infrastrukturen gegen verschiedene Azure App Services mehrerer Kunden. Diese anhaltenden Probing-Aktivitäten deuten auf eine systematische Suche nach verwertbaren Fehlkonfigurationen und exponierten Identitäten hin.
18 Stunden Angriff: Von Reconnaissance bis Zerstörung
Der eigentliche Angriff lief in mehreren Phasen ab. In den ersten rund 15,5 Stunden nutzte Storm-3168 den ersten Service Principal für umfangreiche Lesezugriffe. Dabei wurden detaillierte Informationen zu Azure Virtual Machines, Subscriptions, Resource Groups und weiteren Ressourcen gesammelt – insgesamt über 300 erfolgreiche Read-Operationen. Dieses breite Lagebild verschaffte dem Angreifer eine nahezu vollständige Übersicht über die Azure-Umgebung des Opfers.
Etwa 90 Minuten nach Beginn der ersten Lesezugriffe wurde der zweite Service Principal aktiv. Innerhalb von nur fünf Sekunden las er Informationen zu VMs und Resource Groups über zwei Subscriptions hinweg aus. Beide Service Principals nutzten dieselbe, Storm-3168 zugeordnete Infrastruktur, wiesen identische Netzwerk-Fingerprints auf und verwendeten denselben User-Agent (python-requests/2.34.2), was die Zuordnung zum Angreifer zusätzlich stützt.
Rund 16 Stunden nach den ersten Zugriffen entdeckte der zweite Service Principal Konfigurationsspeicher von Azure App Services – vermutlich mit dem Ziel, dort hinterlegte Zugangsdaten zu finden. Parallel dazu versuchte der Angreifer erfolglos, Azure-OpenSearch-Ressourcen zu identifizieren und führte eine ListKey-Operation gegen ein nicht existierendes Storage-Konto aus. Kurz darauf begann die eigentliche Zerstörungsphase.
Zielgerichtete Zerstörung und Angriff auf Backup-Mechanismen
In der destruktiven Phase versuchte der kompromittierte Service Principal innerhalb von 35 Minuten über 150 Operationen, die entweder Ressourcen löschen oder Zugangsdaten abgreifen sollten. Die eigentliche Zerstörung dauerte nur etwa sieben Minuten, war aber hochintensiv: Der Angreifer versuchte, mehr als 100 Azure-Storage-Accounts zu löschen, wovon der Grossteil erfolgreich entfernt wurde. Nur dort, wo Azure-Resource-Locks oder Schutzmechanismen auf Storage-Ebene aktiv waren, konnten Löschungen verhindert werden.
Zusätzlich wurden ein Azure Key Vault, eine Function App und ein App Service Plan gelöscht, die alle derselben Resource Group angehörten und mutmasslich funktional zusammenhingen. Parallel dazu versuchte Storm-3168, mehrere Azure-SQL-Datenbanken zu löschen. Diese Versuche scheiterten jedoch, weil eine nicht unterstützte API-Version für den Ressourcentyp verwendet wurde – ein technisches Detail, das in diesem Fall als unbeabsichtigter Schutzmechanismus wirkte.
Etwa 28 Minuten nach Ende der Zerstörungsaktivitäten forderte derselbe Service Principal eine Inventarliste der Azure-Storage-Accounts an und führte über 30 erfolgreiche ListKeys-Operationen aus, um die Zugriffsschlüssel der jeweiligen Storage-Konten zu erhalten. Darunter befanden sich auch Storage-Accounts, die mit Azure Site Recovery verknüpft waren. Mehrere Löschversuche gegen Azure Site Recovery Locks und Azure Backup Protection Locks scheiterten zwar, zeigen aber klar die Absicht, auch Wiederherstellungsmechanismen zu schwächen oder auszuschalten.
Indizien für Ransomware – ohne sichtbare Erpressung
Für Microsoft ergibt sich aus der Kombination der beobachteten Taktiken ein klares Bild: Die gezielte Zerstörung zahlreicher Ressourcen, die Versuche, Backup- und Recovery-Funktionen zu beeinträchtigen, sowie das Sammeln von Zugangsdaten für potenzielle spätere Datenzugriffe entsprechen typischen Mustern von Ransomware- und Erpressungsoperationen in Cloud-Umgebungen.
Bemerkenswert ist allerdings, dass in diesem Fall weder eine Lösegeldforderung noch eine bestätigte Datenexfiltration festgestellt wurde. Es ist möglich, dass der Angriff vor Abschluss der Erpressungsphase entdeckt oder gestört wurde, oder dass Storm-3168 die gesammelten Informationen für spätere Kampagnen nutzen wollte. Klar ist jedoch, dass agentische Ransomware wie JadePuffer zunehmend in der Lage ist, komplexe Cloud-Angriffe zu orchestrieren, bei denen Identitätsdiebstahl, Automatisierung und gezielte Zerstörung ineinandergreifen.
Lehren für Azure-Kunden: Identitäten und Recovery härten
Für Betreiber von Azure-Umgebungen lassen sich aus dem Vorfall mehrere zentrale Handlungsfelder ableiten. Erstens zeigt der Fall, wie kritisch der Schutz von Service Principals und anderen Maschinenidentitäten ist. Harte Zugangskontrollen, regelmässige Rotation von Secrets, die konsequente Nutzung von Managed Identities, sowie die Vermeidung von Klartext-Credentials in öffentlichen Repositories sind grundlegende Massnahmen, um ähnliche Angriffe zu erschweren.
Zweitens unterstreicht der Angriff die Bedeutung von Defense-in-Depth bei Backup- und Recovery-Mechanismen. Resource Locks, getrennte Backup-Subscriptions, unveränderliche Backups (Immutable Storage) und klar definierte Wiederherstellungsprozesse können den Schaden im Ernstfall begrenzen – selbst wenn ein Angreifer bereits weitreichende Rechte in der Produktionsumgebung erlangt hat.
Drittens sollten Unternehmen ihre Überwachungs- und Alarmierungsmechanismen für Cloud-Identitäten und -Ressourcen schärfen. Ungewöhnliche Muster wie massenhafte Read-Operationen in kurzer Zeit, plötzliche Löschwellen oder wiederholte ListKeys-Aufrufe sind starke Indikatoren für laufende Angriffe und sollten automatisiert erkannt und eskaliert werden.
Fazit
Der JadePuffer-Fall verdeutlicht, wie sich agentische Ransomware und Cloud-spezifische Angriffsvektoren gegenseitig verstärken können. Storm-3168 nutzte kompromittierte Azure-Service-Principals, um sich in kurzer Zeit ein umfassendes Bild der Zielumgebung zu verschaffen, kritische Ressourcen zu zerstören und gleichzeitig Wiederherstellungsmechanismen ins Visier zu nehmen. Auch wenn in diesem konkreten Fall keine sichtbare Erpressung stattfand, sollten Azure-Kunden den Vorfall als Warnsignal verstehen: Identitätsschutz, robuste Backup-Strategien und fein granulare Überwachung sind zentrale Bausteine, um sich gegen die nächste Generation von Cloud-Ransomware zu wappnen.


Und...wetsch das Cookie ha öder nöd ?
And...do you want the cookie or not ?
Comments are closed.