Sieben Minuten, über 100 gelöschte Speicherkonten: Was Ihre Cloud jetzt braucht

Sieben Minuten. So lange soll es laut Berichten gedauert haben, bis eine Angreifergruppe mit dem Namen JadePuffer über 100 Azure-Storage-Accounts eines einzigen Opfers gelöscht hatte. Microsoft ordnet den Vorfall als erste dokumentierte agentische Ransomware-Operation ein: Nicht ein Mensch klickte sich durch Konsolen, sondern ein KI-Agent arbeitete eine Liste von Löschbefehlen ab, schneller, als irgendein IT-Team reagieren könnte.

Für Sie als Geschäftsführerin, Geschäftsführer oder IT-Verantwortlichen im Mittelstand ist das keine Meldung aus einer fernen Konzernwelt. Die Angriffsfläche, um die es ging, ist Ihnen vermutlich vertraut: Cloud-Speicher, Backups, Dienstkonten, ein Entwickler, der einmal einen Zugangsschlüssel an der falschen Stelle abgelegt hat. Dieser Artikel konzentriert sich bewusst nicht auf die große Bedrohungslage, die wir in anderen Beiträgen bereits beschrieben haben, sondern auf eine einzige praktische Frage: Was sollten Sie diese Woche in Ihrer Cloud prüfen? Dafür bekommen Sie eine Checkliste mit fünf Punkten.

Was passiert ist und was noch unklar bleibt

Beginnen wir mit dem, was nach aktuellem Stand berichtet wird. Microsoft hat Ende September 2026 Analysen zu zwei Angriffen aus dem Juni veröffentlicht, die es der Gruppe JadePuffer zuordnet, bei Microsoft unter der Bezeichnung Storm-3168 geführt. Die Angreifer waren nicht über eine ausgefeilte Sicherheitslücke eingedrungen. Nach Microsofts Darstellung stammten die Zugangsdaten eines Azure-Dienstkontos (eines sogenannten Service Principals) aus einem öffentlich einsehbaren GitHub-Verlauf. Microsoft weist in diesem Zusammenhang darauf hin, dass das nachträgliche Entfernen oder Schwärzen eines veröffentlichten Zugangs diesen nicht ungültig macht. Wer ein Geheimnis einmal veröffentlicht hat, muss es austauschen.

Danach gingen die Angreifer erstaunlich geduldig vor. Berichten zufolge dauerte die Auskundschaftung der Umgebung rund 15 Stunden, mit vielen lesenden Zugriffen auf Abonnements, Ressourcengruppen und Speicherkonten. Erst danach folgte die zerstörerische Phase: Innerhalb von etwa sieben Minuten wurden mehr als 100 Storage-Accounts gelöscht. Weitere Ziele waren laut Berichten ein Key Vault, eine Function App und ein App-Service-Plan. Versuche gegen Azure-SQL-Datenbanken schlugen demnach fehl. Außerdem wurden anschließend Zugriffsschlüssel von Speicherkonten abgefragt, die den Angriff überstanden hatten, offenbar, um sich weiteren Zugriff zu sichern.

Der wichtigste Satz der Analysen für Ihre Praxis lautet: Überlebt haben nur die Ressourcen, die bereits vor dem Angriff durch passive Schutzmechanismen gesichert waren, also durch Azure-Ressourcensperren und den Löschschutz auf Speicherebene. Nicht die Überwachung hat gerettet, nicht das Sicherheitsteam, sondern eine Konfiguration, die jemand Monate vorher vorgenommen hatte.

Gerettet hat in diesem Fall nicht die schnellste Reaktion, sondern die Einstellung, die jemand lange vor dem Angriff gesetzt hat. Passive Schutzmaßnahmen arbeiten auch dann, wenn niemand am Bildschirm sitzt.

Ebenso wichtig ist, was bislang nicht belegt ist. Es wurde laut den Berichten keine Lösegeldforderung beobachtet, und ob Daten tatsächlich abgeflossen sind, ist nicht bestätigt. Das Muster passt zu einer Erpressungsabsicht, aber ob die Gruppe tatsächlich Geld verlangt hat, wissen wir nicht. Wir arbeiten hier zudem mit Sekundärberichten, unter anderem von BleepingComputer und weiteren Nachrichtenseiten, die wir nicht einzeln gegen das Originaldokument von Microsoft geprüft haben. Zahlen wie die 100 Konten oder die sieben Minuten sollten Sie daher als „laut Berichten“ lesen. An der Richtung ändert das nichts, an den Konsequenzen für Ihre Cloud-Konfiguration auch nicht.

Warum menschliche Reaktionszeit nicht mehr reicht

Bisher folgte Ransomware einem ziemlich eingespielten Ablauf: Eindringen, tagelang umsehen, Daten abziehen, verschlüsseln, Erpresserbrief. Zwischen den Schritten lagen oft Stunden oder Tage, und genau in diesen Lücken fanden Verteidiger ihre Chance. Ein Alarm in der Nacht, ein aufmerksamer Administrator, ein auffälliger Datenstrom: Es gab Zeitfenster, in denen ein Mensch eingreifen konnte.

Ein KI-Agent verschiebt diese Rechnung. Er muss nicht schlafen, nicht nachdenken, ob ein Befehl riskant ist, und er kann mehrere Zugriffe gleichzeitig ausführen. Laut Berichten arbeiteten die Angreifer mit mehreren parallelen Anmeldetoken, vier davon für das Löschen, eines für Bestandsaufnahme und Schlüsselabfrage. Wenn die zerstörerische Phase nur sieben Minuten dauert, ist die Frage nicht mehr, ob Ihr Team gut genug reagiert. Die Frage ist, ob irgendein Mensch in dieser Zeit eine Meldung lesen, bewerten, eskalieren und handeln kann. Realistisch: nein.

Dazu kommt ein zweiter Befund, der parallel diskutiert wird. Anthropic hat in einer Untersuchung beschrieben, dass das offene Modell GLM-5.3 des chinesischen Anbieters Zhipu AI in einem Benchmark zu Chrome-Schwachstellen in 50 von 410 Versuchen einen vollständigen Exploit entwickelte. Zum Vergleich nennen die Berichte 56 Treffer für Anthropics eigenes, nicht frei verfügbares Modell Mythos Preview. Außerdem sollen sich die Schutzmechanismen von GLM-5.3 mit einfachen Tricks umgehen lassen, etwa durch die Behauptung, man sei ein autorisierter Red-Team-Agent. Wir geben diese Zahlen so wieder, wie sie berichtet werden, und haben sie nicht unabhängig nachgemessen.

Was bedeutet das für Sie? Zwei Dinge. Erstens: Fähigkeiten, die vor kurzem noch einigen wenigen Laboren vorbehalten waren, stehen als offene Gewichte allen zur Verfügung, auch Kriminellen. Zweitens: Der Aufwand pro Angriff sinkt. Wenn ein Agent Reconnaissance, Rechteausweitung und Zerstörung weitgehend selbstständig erledigt, lohnt sich ein Angriff auch gegen Ziele, die früher zu klein oder zu unbedeutend waren. Der Mittelstand rückt damit von der Randzone in die Mitte des Zielkorridors. Nicht, weil Ihr Unternehmen plötzlich interessanter wäre, sondern weil der Angriff billiger geworden ist.

Die Konsequenz ist eine Verschiebung des Schwerpunkts. Erkennung und Reaktion bleiben wichtig, aber sie reichen nicht als alleinige Verteidigung. Entscheidend wird, was vor dem Angriff konfiguriert ist: Rechte, die klein gehalten werden, Löschvorgänge, die ohne zusätzliche Hürde gar nicht möglich sind, und Kopien, die selbst ein Administrator mit gestohlenen Zugangsdaten nicht vernichten kann. Das führt direkt zur Checkliste.

Die 5-Punkte-Checkliste, Teil 1: Löschen erschweren und Kopien unveränderlich machen

Die ersten drei Punkte beantworten dieselbe Frage: Was passiert, wenn jemand mit gültigen Zugangsdaten versucht, Ihre Daten zu löschen? Im Fall JadePuffer funktionierte genau das, weil die Löschbefehle als legitime Verwaltungsaufrufe durchgingen. Die Plattform kann nicht unterscheiden, ob ein Administrator oder ein gestohlenes Dienstkonto den Befehl sendet. Deshalb braucht es Bremsen, die unabhängig von der Identität greifen.

Punkt 1: Ressourcensperren und Löschschutz auf allem, was zählt. Azure bietet Ressourcensperren, mit denen sich Ressourcen gegen versehentliches oder böswilliges Löschen (Sperrstufe „CanNotDelete“) oder gegen Änderungen schützen lassen. Genau diese Sperren gehörten laut Berichten zu den Dingen, die den Angriff überstanden haben. Prüfen Sie: Haben Ihre produktiven Storage-Accounts, Ihre Key Vaults, Ihre Datenbanken und die Ressourcengruppen mit Backups eine solche Sperre? Wenn Sie diese Frage nicht in zwei Minuten beantworten können, ist das bereits die Antwort.

Seien Sie dabei ehrlich über die Grenzen. Eine Sperre lässt sich von jemandem mit ausreichend hohen Rechten wieder entfernen. Sie ist eine Hürde, keine Mauer, und sie funktioniert besonders gut zusammen mit Punkt 4: Wenn das kompromittierte Dienstkonto gar nicht das Recht hat, Sperren zu verwalten, scheitert der Agent an dieser Stelle. Dass im Fall JadePuffer Sperren hielten, deutet darauf hin, dass die Angreifer sie entweder nicht entfernen konnten oder nicht darauf vorbereitet waren. Verlassen Sie sich nicht darauf, dass das beim nächsten Mal auch so ist.

Punkt 2: Soft-Delete und Versionierung einschalten, auch bei Key Vaults. Soft-Delete sorgt dafür, dass gelöschte Blobs, Container oder Freigaben nicht sofort verschwinden, sondern für eine einstellbare Frist wiederherstellbar bleiben. Versionierung bewahrt frühere Stände von Dateien auf, falls sie überschrieben statt gelöscht werden. Bei Key Vaults kommt der Löschschutz („Purge Protection“) hinzu, der verhindert, dass ein gelöschter Tresor vor Ablauf der Aufbewahrungsfrist endgültig entfernt wird. Prüfen Sie, ob diese Funktionen bei Ihnen aktiv sind, wie lang die Fristen sind und ob jemand weiß, wie eine Wiederherstellung konkret abläuft. Beachten Sie außerdem: Soft-Delete auf Ebene einzelner Blobs hilft nicht automatisch, wenn das gesamte Speicherkonto gelöscht wird. Fragen Sie Ihren Dienstleister, welche Ebene bei Ihnen abgedeckt ist und welche nicht.

Punkt 3: Mindestens eine unveränderliche Backup-Kopie. „Wir haben ein Backup“ ist die gefährlichste Aussage im Gespräch über Ransomware, wenn niemand sagen kann, wo es liegt und wer es löschen darf. Laut Berichten wurden im Fall JadePuffer auch Backup- und Site-Recovery-Ressourcen angegriffen und waren nur teilweise durch bestehende Sperren geschützt. Ein Backup, das im selben Abonnement liegt, mit demselben Dienstkonto erreichbar ist und sich löschen lässt, ist nur eine zweite Kopie, aber kein Schutz. Anforderungen, die Sie stellen sollten:

• Unveränderlichkeit (WORM): Daten dürfen während einer festgelegten Frist weder geändert noch gelöscht werden, auch nicht von Administratoren. Azure bietet dafür unveränderlichen Speicher und für Azure Backup unveränderliche Tresore.
• Trennung: Die Backup-Kopie liegt in einem separaten Abonnement oder Tenant oder bei einem anderen Anbieter, mit eigenen Zugangsdaten, die nicht zum Alltagsbetrieb gehören.
• Wiederherstellungstest: Mindestens einmal im Jahr, besser vierteljährlich, wird eine echte Wiederherstellung durchgespielt und die Zeit gemessen. Erst dann kennen Sie Ihre tatsächliche Ausfallzeit.
• Dokumentation: Wer darf die Wiederherstellung auslösen, und wo liegen die Zugangsdaten, wenn die Hauptumgebung nicht mehr erreichbar ist?

Die Unveränderlichkeit hat einen Preis: Sie kostet Speicherplatz, und eine einmal gesetzte Frist lässt sich nicht verkürzen. Das ist gewollt. Für den Mittelstand heißt das: Lieber die wirklich kritischen Datenbestände unveränderlich sichern, also Buchhaltung, Verträge, Kundendaten und Produktionsparameter, als alles pauschal. Eine ehrliche Priorisierung ist hier mehr wert als ein Gießkannenansatz.

Die 5-Punkte-Checkliste, Teil 2: Rechte klein halten und Auffälliges erkennen

Die ersten drei Punkte begrenzen den Schaden. Die nächsten beiden verhindern, dass es überhaupt so weit kommt, oder verschaffen Ihnen zumindest Zeit. Sie setzen dort an, wo der Angriff tatsächlich begann: bei einem Dienstkonto mit zu vielen Rechten und einem Geheimnis am falschen Ort.

Punkt 4: Rechtevergabe nach dem Prinzip der minimalen Rechte. Microsoft nennt als Gegenmaßnahme ausdrücklich, zu weit gefasste Rollenzuweisungen zu entfernen, genannt wird etwa die Rolle „Storage Account Contributor“. Die Erfahrung aus der Praxis ist ernüchternd: Dienstkonten werden bei Projektstart großzügig ausgestattet, weil es schnell gehen muss, und später nie wieder beschnitten. Nach einigen Jahren hat jede Automatisierung mehr Rechte als jeder Mitarbeiter. Ein einziges geleaktes Geheimnis genügt dann für den Totalverlust.

Gehen Sie so vor:

• Inventur der Dienstkonten: Listen Sie alle Service Principals, App-Registrierungen und Automatisierungskonten auf. Wer hat sie angelegt, wofür, wann wurde zuletzt ein Login beobachtet?
• Rollen prüfen: Hat ein Konto Besitzer- oder Mitwirkenden-Rechte auf Abonnementebene, obwohl es nur in eine Ressourcengruppe schreiben muss? Verkleinern Sie den Geltungsbereich.
• Löschrechte trennen: Das Recht, Ressourcen zu löschen und Sperren zu verwalten, gehört nicht in Konten, die täglich im Automatikbetrieb laufen.
• Zeitlich begrenzte Adminrechte: Menschen sollten erhöhte Rechte nur bei Bedarf und befristet aktivieren, etwa über Privileged Identity Management, je nach Lizenzumfang.
• Schlüssel statt Identität vermeiden: Speicherkonto-Schlüssel gewähren sehr weitreichenden Zugriff. Wo möglich, nutzen Sie identitätsbasierte Anmeldung und schalten den Zugriff per Shared Key ab. Laut Berichten fragten die Angreifer nach ihrer Löschaktion massenhaft Schlüssel ab, das zeigt, wie begehrt sie sind.

Zu Punkt 4 gehört auch das Thema, das den Angriff überhaupt ermöglicht hat: Geheimnisse im Quellcode und in Ticketsystemen. Aktivieren Sie die Geheimnis-Erkennung Ihrer Code-Plattform, scannen Sie bestehende Repositories und Verläufe einmalig komplett, und etablieren Sie die Regel, dass ein veröffentlichtes Geheimnis sofort ausgetauscht wird, nicht nur gelöscht. Prüfen Sie auch Dokumentation, Chat-Verläufe und Support-Tickets, denn dort landen Zugangsdaten erfahrungsgemäß genauso häufig.

Punkt 5: Monitoring auf Muster, nicht nur auf Einzelereignisse. Auch wenn Überwachung allein nicht reicht, sollte sie Ihnen zumindest sagen, dass etwas passiert, solange noch etwas zu retten ist. Im Fall JadePuffer gab es eine lange Vorlaufphase mit vielen lesenden Zugriffen, das ist ein verwertbares Signal, das Stunden vor der Zerstörung sichtbar war. Microsoft nennt als Erkennungsmerkmale unter anderem massenhafte Lesezugriffe auf Abonnements und Ressourcengruppen, Anmeldungen eines Dienstkontos aus ungewohnten Netzen, große Mengen an Schlüsselabfragen und Versuche, Sperren von Backup-Ressourcen zu entfernen. Konkrete Indikatoren wie die Kennung eines bestimmten Software-Clients oder einzelne IP-Adressen veröffentlicht Microsoft ebenfalls. Nutzen Sie diese Listen, aber verlassen Sie sich nicht darauf: Angreifer wechseln solche Merkmale schnell.

Wichtiger sind Fragen, die Sie unabhängig vom konkreten Vorfall beantworten sollten:

• Werden Aktivitätsprotokolle (Activity Log) und Diagnosedaten Ihrer Abonnements zentral gesammelt und länger als die Standardfrist aufbewahrt, an einem Ort, den ein Angreifer nicht mit denselben Rechten löschen kann?
• Gibt es Warnungen für Massenlöschungen, also eine hohe Zahl von Löschaufrufen in kurzer Zeit?
• Sind passende Schutzfunktionen wie Microsoft Defender for Cloud für Resource Manager, Storage und Key Vault aktiviert, soweit Ihr Budget es zulässt?
• Wer wird nachts oder am Wochenende benachrichtigt, und was darf diese Person ohne Rückfrage tun?
• Gibt es eine automatische Reaktion, etwa das Sperren eines Dienstkontos bei auffälligem Verhalten, die ohne Mensch auskommt?

Die letzte Frage ist die entscheidende. Wenn der Angriff sieben Minuten dauert, muss die erste Reaktion maschinell erfolgen. Das muss kein teures Sicherheitszentrum sein. Schon eine einfache Regel, die ein Dienstkonto bei ungewöhnlich vielen Löschaufrufen automatisch deaktiviert, kann den Schaden spürbar begrenzen. Die Regel produziert gelegentlich Fehlalarme, und das ist der Preis, den Sie dafür zahlen.

In 30 Tagen umsetzen: ein realistischer Plan für den Mittelstand

Eine Checkliste mit fünf Punkten klingt machbar, wird aber im Alltag schnell zur Liste, die niemand abarbeitet. Damit das nicht passiert, schlagen wir einen Zeitplan vor, den ein kleines IT-Team oder Ihr externer Dienstleister in vier Wochen bewältigen kann. Die Zahl der Wochen ist eine Planungsannahme, keine Studie, passen Sie sie an Ihre Umgebung an.

Woche 1: Überblick schaffen. Erstellen Sie eine Liste Ihrer Cloud-Abonnements, Speicherkonten, Key Vaults, Datenbanken und Backup-Tresore. Markieren Sie, was geschäftskritisch ist. Das klingt banal, aber in vielen Unternehmen existieren Ressourcen, von denen niemand mehr weiß, wem sie gehören. Parallel prüfen Sie, ob Geheimnisse in Repositories oder Tickets liegen, und tauschen alles aus, was Sie finden.

Woche 2: Löschschutz setzen. Aktivieren Sie Ressourcensperren, Soft-Delete, Versionierung und Purge Protection für alle als kritisch markierten Ressourcen. Das ist meist ein Konfigurationsschritt ohne Ausfallzeit. Testen Sie vorher kurz, ob Ihre Deployment-Prozesse mit den Sperren zurechtkommen, denn eine Sperre kann auch legitime Automatisierung bremsen. Planen Sie dafür einen definierten Ablauf für das befristete Aufheben ein.

Woche 3: Rechte aufräumen. Reduzieren Sie die Rollen der Dienstkonten, trennen Sie Löschrechte ab und stellen Sie Administratorzugänge auf befristete Aktivierung um. Beginnen Sie mit den zehn mächtigsten Konten, nicht mit allen. Dokumentieren Sie, was Sie geändert haben, damit sich später nachvollziehen lässt, warum etwas nicht mehr funktioniert.

Woche 4: Backup härten und Alarm testen. Richten Sie die unveränderliche, getrennte Kopie Ihrer wichtigsten Daten ein und führen Sie eine Wiederherstellung durch. Richten Sie Warnungen für Massenlöschungen ein und prüfen Sie, wer sie erhält. Spielen Sie anschließend einen Ernstfall durch: Ein Dienstkonto wird kompromittiert, was passiert in den ersten zehn Minuten? Wer diese Übung einmal gemacht hat, weiß mehr über seine Lücken als nach jedem Papier-Audit.

Rechnen Sie ehrlich mit Aufwand. Manche Maßnahmen kosten Speicherplatz, Lizenzen oder die Zeit Ihres Dienstleisters. Setzen Sie diese Kosten ins Verhältnis zum Szenario: Ein Betrieb, der alle Speicherkonten und die zugehörigen Backups verliert, steht nicht nur still, sondern muss je nach Datenlage möglicherweise auch Meldepflichten nach der DSGVO prüfen. Ein Ausfall kostet deutlich mehr als jede der hier genannten Maßnahmen.

Fragen an Ihren Dienstleister und was Sie daraus mitnehmen

Viele Mittelständler betreiben ihre Cloud nicht selbst, sondern über einen IT-Dienstleister oder ein Systemhaus. Das ist völlig in Ordnung, aber es verschiebt die Verantwortung nicht. Die Haftung und die Folgen eines Datenverlusts bleiben bei Ihnen. Nutzen Sie die Checkliste daher als Gesprächsgrundlage und stellen Sie die folgenden Fragen schriftlich:

• Welche unserer Cloud-Ressourcen sind gegen Löschen gesperrt, und welche nicht? Bitte als Liste.
• Wo liegt die unveränderliche Backup-Kopie, wer kann sie löschen, und wann wurde zuletzt eine Wiederherstellung getestet?
• Welche Dienstkonten haben Rechte auf Abonnementebene, und wann wurden ihre Geheimnisse zuletzt ausgetauscht?
• Was passiert automatisch, wenn in kurzer Zeit viele Ressourcen gelöscht werden?
• Wer hat nachts und am Wochenende Bereitschaft, und welche Befugnisse hat diese Person?

Wenn die Antworten vage ausfallen, ist das ein Befund, kein Grund zur Panik. Er zeigt Ihnen, wo Sie zuerst ansetzen. Die Qualität einer Antwort erkennen Sie daran, dass sie konkret, datiert und überprüfbar ist.

Und was hat das mit KI-Agenten auf Ihrer Seite zu tun? Eine ganze Menge. Wenn Sie selbst KI-Agenten einsetzen, etwa für Dokumentenverarbeitung, Kundenservice oder interne Recherche, brauchen auch diese Zugänge zu Ihren Systemen. Jeder dieser Agenten ist ein weiteres Dienstkonto mit eigenen Rechten und eigenem Geheimnis. Die Regeln dieser Checkliste gelten für sie genauso: minimale Rechte, keine Löschrechte, Protokollierung, schnelles Sperren. Wer seine Agenten von Anfang an so einrichtet, hat die Disziplin, die er für die Abwehr fremder Agenten braucht, ohnehin schon im Haus. Das ist kein Zufall, sondern dieselbe Governance-Frage von zwei Seiten.

Zum Schluss die Einordnung ohne Dramatik: JadePuffer ist kein Weltuntergang und kein Beweis, dass die Cloud unsicher wäre. Der Fall zeigt vielmehr, dass die Grundlagen zählen. Ein öffentliches Geheimnis, zu viele Rechte, fehlender Löschschutz, das sind keine Zero-Day-Lücken, sondern Konfigurationsfragen, die Sie selbst in der Hand haben. Neu ist nur das Tempo, in dem sie ausgenutzt werden. Wer die fünf Punkte dieses Artikels in den nächsten Wochen abarbeitet, gehört in einem möglichen Ernstfall zu den Betrieben, deren Daten noch da sind, wenn der Agent nach sieben Minuten fertig ist.