Die Aufklärungsphase zog sich nach Microsofts Analyse über knapp 16 Stunden. In dieser Zeit führte der erste Service Principal mehr als 300 Leseoperationen gegen virtuelle Maschinen, Abonnements, Ressourcengruppen und weitere Ressourcen aus. Der zweite Service Principal meldete sich 90 Minuten später mit einer eigenen, extrem kurzen Erkundung: Innerhalb von fünf Sekunden zählte er virtuelle Maschinen und Ressourcengruppen über zwei Abonnements hinweg auf.
Nach Ablauf der 16 Stunden las derselbe Service Principal erfolgreich Konfigurationsspeicher von Azure App Services aus – vermutlich auf der Suche nach offen hinterlegten Zugangsdaten. Kurz darauf folgten binnen 35 Minuten über 150 Operationen, die entweder der Zerstörung oder dem Sammeln von Anmeldedaten dienten.
Die eigentliche Löschsequenz dauerte lediglich rund sieben Minuten und umfasste mehr als 100 Versuche, Speicherkonten zu entfernen. Ebenfalls im Visier standen ein Azure Key Vault, eine Function App, ein App-Service-Plan sowie mehrere Azure-SQL-Datenbanken. Die Datenbanklöschungen scheiterten sämtlich, weil der Angreifer eine für diesen Ressourcentyp nicht unterstützte API-Version verwendete.
“Die meisten vom Angreifer ins Visier genommenen Azure-Speicherkonten wurden erfolgreich gelöscht”, so Microsoft. Bei einigen Konten hätten jedoch Azure-Ressourcensperren und der Löschschutz auf Speicherkonto-Ebene die Versuche blockiert – ein Beleg für den Wert unabhängiger Schutzmechanismen, die selbst dann greifen, wie es weiter heißt, wenn eine kompromittierte Identität über weitreichende Administratorrechte verfügt.
Wie der Service Principal ursprünglich kompromittiert wurde, ist unklar. Microsoft stellte allerdings fest, dass Client-ID, Client-Secret und Tenant-ID zuvor von einem Mitarbeiter der betroffenen Organisation im Klartext in einem öffentlichen GitHub-Issue standen. Das Secret wurde zwar entfernt, blieb aber über die öffentliche Bearbeitungshistorie abrufbar.
Darüber hinaus registrierte Microsoft von Storm-3168 zuzuordnender Infrastruktur wiederholte Probing-Versuche gegen Azure App Services mehrerer Kunden. Die Arbeitsteilung zwischen den Service Principals und das Timing der einzelnen Schritte sprechen laut Microsoft für automatisierte oder skriptgesteuerte Abläufe.
Sysdig hatte JADEPUFFER zuvor bei einem Angriff beobachtet, der über eine bekannte Schwachstelle in Langflow (CVE-2025-3248) einstieg, Zugangsdaten sammelte, sich lateral bewegte, Nacos-Konfigurationsdateien verschlüsselte, Datenbanktabellen verwarf und eine Lösegeldforderung in Bitcoin hinterließ. Die Verschlüsselung erfolgte dabei über die in MySQL eingebaute Funktion AES_ENCRYPT(). Dieselbe Langflow-Instanz wurde anschließend ein zweites Mal angegriffen, diesmal mit einer in Go kompilierten Ransomware namens ENCFORGE.
ENCFORGE ist gezielt auf KI-Infrastruktur zugeschnitten und sucht nach nahezu 180 Dateiendungen – darunter Modell-Checkpoints, Vektordatenbanken, Trainingsdatensätze und Embedding-Indizes – sowie nach macOS-typischen Dateien wie Keychain-Speichern, Xcode-Projekten und Apple-Pages- und -Numbers-Dokumenten.
“Ein autonomer Agent überlegte selbst, welche Ziele in Frage kommen, erbeutete und verwendete Zugangsdaten erneut, bewegte sich lateral, richtete Persistenz ein und zerstörte eine Datenbank – und kommentierte dabei durchgehend seine eigene Absicht”, hielt Sysdig damals fest. Keine der Einzeltechniken sei neu oder ausgefeilt gewesen; bemerkenswert sei, dass ein KI-Modell sie zu einer vollständigen Ransomware-Operation gegen vernachlässigte, aus dem Internet erreichbare Infrastruktur verkettet habe.