Die beiden übernommenen Dienstprinzipale hatten laut Microsoft unterschiedliche Rollen: Der erste betrieb Aufklärung und Ressourcenerkennung, der zweite übernahm zusätzlich die zerstörerischen Operationen und das Einsammeln von Zugangsdaten.
Rund 15,5 Stunden lang erfasste der erste Dienstprinzipal virtuelle Maschinen, Abonnements, Ressourcengruppen und weitere Objekte und führte dabei mehr als 300 erfolgreiche Leseoperationen aus. Etwa 90 Minuten nach Beginn dieser Aufklärung listete der zweite Dienstprinzipal virtuelle Maschinen und Ressourcengruppen über zwei Abonnements hinweg auf — in nur fünf Sekunden. “Diese Breite der Aktivität würde dem Bedrohungsakteur Sichtbarkeit über die gesamte Azure-Umgebung der Organisation verschaffen”, schreiben Weizman und Mudi.
Sechzehn Stunden später las der zweite Dienstprinzipal Konfigurationsspeicher von Azure App Service aus, möglicherweise auf der Suche nach offenliegenden Zugangsdaten. Versuche, Azure-OpenSearch-Ressourcen zu finden, blieben erfolglos, ebenso eine ListKey-Operation gegen ein nicht existierendes Speicherkonto.
Weniger als eine Sekunde danach begann die Zerstörung: über 100 Versuche, Storage-Konten zu löschen, die überwiegend gelangen. JadePuffer löschte zudem einen Azure Key Vault, eine Function App und einen App-Service-Plan in derselben Ressourcengruppe. Parallele Löschversuche gegen mehrere Azure-SQL-Datenbanken scheiterten, weil der Angreifer eine nicht unterstützte API-Version verwendete.
Etwa 30 Minuten nach der Löschaktion forderte der Dienstprinzipal eine Inventarliste der Azure-Storage-Konten an, darunter solche mit Bezug zu Site Recovery, und rief anschließend über 30 Mal erfolgreich per ListKeys die zugehörigen Zugriffsschlüssel ab.
Wie der Dienstprinzipal ursprünglich kompromittiert wurde, ist laut Microsoft unklar. Die Forscher fanden jedoch, dass Client-ID, Client Secret und Tenant-ID zuvor von einem Mitarbeiter der betroffenen Organisation im Klartext in einem öffentlichen GitHub-Issue offengelegt worden waren. Das Issue wurde später bereinigt, die Angaben blieben aber über die öffentliche Bearbeitungshistorie zugänglich. Ob die offengelegten Zugangsdaten im Angriff genutzt wurden, konnte Microsoft nicht bestätigen.
Für Ross Filipek, Chief Information Security Officer bei Corsica Technologies, ist der Fall “eine nützliche Warnung davor, wie eine routinemäßige Bereinigung ein Konto weiterhin exponiert lassen kann”. Und: “Sobald Angreifer eine Anwendungsidentität besitzen, kann ihre Aktivität wie gewöhnliche Cloud-Administration aussehen.”
Ob der Angriff tatsächlich vollständig KI-gesteuert war, bezweifelt Nick Tausek, Lead Security Automation Architect bei Swimlane: “Ich stimme Microsofts Warnung vor KI-orchestrierten Angriffen zu, allerdings zeigen die Azure-Belege koordinierte Automatisierung, statt zu beweisen, dass eine KI jeden einzelnen Schritt gesteuert hat.” Agentische KI könne dennoch ein gefährlicher Gegner sein.
Microsoft zufolge sondiert JadePuffer-verbundene Infrastruktur seit Jahresbeginn mehrere Azure-App-Services verschiedener Kunden. Der Agent teste dabei unterschiedliche Wege in Cloud-Umgebungen, unter anderem über “WordPress-Administration, PHP-CGI, den Code-Validierungs-Endpunkt von LangFlow (/api/v1/validate/code) und andere Webshell-artige Pfade”.
Verteidiger sollten ihrerseits auf KI setzen, rät Microsoft: “Statt von Analysten zu verlangen, jeder einzelnen Aktion manuell nachzugehen, sollen Vorhaben wie Project Perception und MDASH ein Modell stützen, in dem Verteidiger mithilfe von KI in immer größeren und komplexeren Umgebungen untersuchen und reagieren können.” Als Gegenmaßnahmen empfiehlt Microsoft unter anderem passende Microsoft-Defender-for-Cloud-Pläne für kritische Azure-Workloads, den Schutz und die fortlaufende Bewertung von Anwendungs-Zugangsdaten und Geheimnissen, das sofortige Rotieren kompromittierter oder offengelegter Zugangsdaten samt Lebenszyklus-Praktiken sowie das Prinzip der geringsten Rechte für Dienstprinzipale und andere Workload-Identitäten.