Rund 7 Minuten dauerte laut Microsoft die Phase, in der die Angreifer über 100 Mal versuchten, Speicherkonten eines Kunden in Azure zu löschen.

Erst kostenlos reinschnuppern, dann entscheiden

Bevor du dich für eine Weiterbildung entscheidest, sieh dir kostenlos an, wie sie läuft, fünf Lektionen plus Live-Demo, ohne Verpflichtung. Passt es, ist der Digitalisierungsmanager bei bewilligtem Bildungsgutschein für dich kostenlos.

Kostenlos reinschnuppern

Was Microsoft am 25. September beschrieben hat

Der Bericht von Microsoft Security Research betrifft die Gruppe JADEPUFFER. Sie wurde laut Microsoft im Juli 2026 von Sysdig entdeckt und als erste dokumentierte agentische Ransomware-Operation beschrieben, Microsoft selbst führt sie unter dem Namen Storm-3168. Den Hintergrund zur Entdeckung haben wir in einem früheren Artikel zu JadePuffer eingeordnet. Laut Security Affairs ist der neue Bericht der erste genaue Blick darauf, was die Gruppe in Azure tut.

Als Werkzeug dienten zwei kompromittierte Dienstkonten, im Azure-Umfeld Service Principals genannt. Das sind technische Identitäten, mit denen Anwendungen auf die Cloud zugreifen, und beide lagen im selben Mandanten des Kunden. Das eine Konto erkundete die Umgebung, das andere erkundete ebenfalls, zerstörte und sammelte Zugangsschlüssel. Wer das Opfer ist, nennt der Bericht nicht, Branche und Größe sind unbekannt. Beschrieben ist nur ein einziger betroffener Mandant.

Vom Auslesen bis zum Löschen

Anfang Juni 2026 las das erste Konto nach Angaben von Microsoft rund 15 Stunden und 30 Minuten lang die Umgebung aus, mit über 300 erfolgreichen Lesezugriffen. Später kam das zweite Konto zum Zug. In 35 Minuten unternahm es über 150 zerstörerische oder schlüsselbezogene Aktionen. Die eigentliche Löschphase dauerte rund 7 Minuten und umfasste über 100 Löschversuche an Speicherkonten. Die meisten der angegriffenen Speicherkonten wurden gelöscht. Dazu kamen ein Schlüsseltresor (Key Vault) und eine Function App samt dem zugehörigen App-Service-Plan. Rund 30 Minuten nach der letzten Löschung rief das Konto dann über 30 Mal erfolgreich die Zugangsschlüssel von Speicherkonten ab.

Neue Rechte brauchten die Angreifer dafür nicht. Alle Aktionen liefen über die Rollen, die das Dienstkonto ohnehin hatte, und Security Affairs fasst es so zusammen: Ausweiten mussten die Angreifer nichts, der Zugriff war schon da.

Was gehalten hat

Nicht alles ließ sich löschen. Bei einigen Speicherkonten verhinderten Ressourcensperren und der Löschschutz die Löschung, obwohl das Konto weitreichende Rechte hatte. Die Datenbanken blieben stehen, weil das Skript laut Microsoft eine nicht unterstützte API-Version nutzte. Auch die Versuche, Sperren von Backup und Wiederherstellung zu entfernen, blieben erfolglos.

Eine Lösegeldforderung hat Microsoft nicht beobachtet, einen Datenabfluss nicht bestätigt. Das Muster aus Löschen, Angriff auf die Wiederherstellung und Schlüsselsammeln passt nach Einschätzung von Microsoft trotzdem zu Erpressung.

Ein Geheimnis im Bearbeitungsverlauf

Wie das Konto übernommen wurde, ist laut Microsoft unklar. Gefunden hat Microsoft allerdings, dass Client-ID, Client-Geheimnis und Mandanten-ID zuvor im Klartext in einem öffentlichen GitHub-Issue standen, gepostet von einem Beschäftigten der betroffenen Organisation. Das Issue wurde später bearbeitet. Das Geheimnis blieb trotzdem im öffentlichen Bearbeitungsverlauf lesbar. Ob genau dieses Geheimnis beim Angriff benutzt wurde, konnte Microsoft nicht bestätigen, als Ursache bewiesen ist das Issue also nicht.

Den Kernsatz des Berichts geben wir übersetzt wieder: Öffentlich gewordene Zugangsdaten bleiben nutzbar, bis sie widerrufen oder ausgetauscht werden, und das Entfernen des ursprünglichen Beitrags allein behebt nichts.

Offen ist auch, wer oder was die Befehle gegeben hat. Die Zeitabstände zwischen den Aktionen und parallel genutzte Token deuten laut Microsoft unter anderem stark auf automatisierte oder skriptgesteuerte Ausführung hin. Dass KI-Agenten die Aktionen gesteuert haben, ist damit nicht belegt. GBHackers schreibt von automatisierter oder agentischer Ausführung und spitzt damit zu, die Einordnung als agentische Ransomware stammt von Sysdig und wird von Microsoft zitiert.

Microsoft empfiehlt, Geheimnisse weder in Quellcode oder Konfigurationsdateien noch in öffentlichen Repositories oder Issues abzulegen. Offengelegte Zugangsdaten sollen sofort widerrufen oder ausgetauscht werden, Dienstkonten nur die nötigsten Rechte erhalten, und Backup und Wiederherstellung brauchen einen gesonderten Schutz.

Unsere Einschätzung

Dienstkonten klingen nach Konzern-IT. Aus unserer Sicht hat auch ein kleiner Betrieb meist einige davon, ohne sie so zu nennen: die Verbindung des Webshops zur Cloud etwa oder das Konto, mit dem ein Dienstleister die Datensicherung abholt.

Am meisten beschäftigt uns der Befund zum bearbeiteten GitHub-Issue. Wir würden jeden Schlüssel und jedes Passwort, das jemals in einem Support-Forum oder im Chat mit einem Dienstleister stand, als verbraucht behandeln und austauschen, auch wenn der Beitrag längst gelöscht ist. Löschen fühlt sich nach Aufräumen an. Wirksam wird erst der Austausch.

Bei den Rechten hilft eine schlichte Frage je Konto, nämlich was es tatsächlich können muss. Ein Zugang, der Rechnungen abholt, braucht keine Löschrechte auf alle Speicher. Der Fall hat auch eine ermutigende Seite, denn Löschschutz, Ressourcensperren und die Sperren der Wiederherstellung haben laut Microsoft zumindest teilweise gehalten, obwohl der Angreifer mit gültigen Zugangsdaten kam. Wer nicht weiß, ob diese Schutzeinstellungen in der eigenen Cloud gesetzt sind, sollte aus unserer Sicht beim IT-Dienstleister nachfragen.

Quellen

Die genannten Angaben stützen sich auf folgende öffentlich zugängliche Quellen (Stand der Recherche: 29. September 2026):

Häufige Fragen

Was ist Storm-3168?

Storm-3168 ist der Name, unter dem Microsoft die Gruppe JADEPUFFER führt. Sysdig hat sie laut Microsoft im Juli 2026 entdeckt und als erste dokumentierte agentische Ransomware-Operation beschrieben. Microsoft Security Research hat am 25. September 2026 einen Bericht über ihr Vorgehen in Azure veröffentlicht.

Wie kamen die Angreifer an die Dienstkonten?

Das ist laut Microsoft unklar. Microsoft fand, dass Client-ID, Client-Geheimnis und Mandanten-ID zuvor im Klartext in einem öffentlichen GitHub-Issue standen und das Geheimnis nach einer Bearbeitung im öffentlichen Verlauf lesbar blieb. Ob genau dieses Geheimnis beim Angriff benutzt wurde, konnte Microsoft nicht bestätigen.

Haben KI-Agenten den Angriff gesteuert?

Das ist nicht belegt. Microsoft sieht starke Hinweise auf automatisierte oder skriptgesteuerte Ausführung. Die Einordnung als agentische Ransomware stammt von Sysdig und wird von Microsoft zitiert.

Was sollte ein Betrieb jetzt regeln?

Microsoft empfiehlt, Geheimnisse nicht in Quellcode, Konfigurationsdateien, öffentlichen Repositories oder Issues abzulegen und offengelegte Zugangsdaten sofort zu widerrufen oder auszutauschen. Dienstkonten sollen nur die nötigsten Rechte bekommen, Backup und Wiederherstellung einen gesonderten Schutz. Aus unserer Sicht lohnt es sich, gemeinsam mit dem IT-Dienstleister zu klären, welche technischen Zugänge es im Betrieb gibt und welche davon löschen dürfen.

Welche Dienstkonten im Betrieb dürfen löschen, und wer weiß das?

Im kostenlosen KI-Schnupperkurs zeigen wir in fünf Lektionen, wie kleine und mittlere Firmen KI im Alltag einsetzen. Tiefer und praxisnah geht es im Vollkurs Digitalisierungsmanager, DEKRA-zertifiziert und förderfähig über den Bildungsgutschein.

Zuletzt aktualisiert: 29. September 2026. Stand der Recherche: 29. September 2026.