Azure Automation wird laut Quelltext sowohl von Microsoft selbst als auch von Unternehmen breit eingesetzt, etwa für DevOps-Abläufe, die Bereitstellung von Ressourcen, Patch-Management und die Rotation von Geheimnissen über skriptgesteuerte Runbooks mit eingebetteten verwalteten Identitäten. Gerade weil diese Konten typischerweise privilegierte Identitäten tragen, wählte Shavits Team den Dienst als Forschungsziel.
Im Kern beschreibt CVE-2025-29827 eine Rechteausweitung in Azure Automation. Ein Angreifer, der bereits Zugriff auf ein eigenes Azure-Automation-Konto hat, konnte nach Angaben des MSRC die Vertrauensgrenze zwischen dem Dienst und den darin verwendeten Identitäten überwinden. Das Ziel war die Übernahme der Automatisierungsidentität eines anderen Tenants. Daraus hätten sich weitreichende Möglichkeiten ergeben: Automatisierungsskripte erstellen oder verändern, auf sensible Konfigurationsdaten oder Zugangsdaten in Azure-Automation-Konten zugreifen sowie Ressourcen in den Cloud-Workloads einer Organisation anlegen, ändern oder löschen.
Shavit zufolge war die Angriffskette nicht auf einen einzelnen Fehler zurückzuführen. Sie bestand aus drei getrennten Schwachstellen: einer Standardkonfiguration, die Azure-Automation-Konten öffentlich zugänglich machte, sowie zwei weiteren Fehlern auf Code-Ebene. Er erklärte, dass ein Automatisierungskonto damals zumindest über den Endpunkt standardmäßig öffentlich gewesen sei und genau das ausgenutzt wurde. Weil diese Voreinstellung öffentlich gewesen sei, habe sich potenziell auf viele Konten zugreifen lassen.
Nach Shavits Angaben ist diese Voreinstellung inzwischen geändert worden; die Standardkonfiguration für Azure-Automation-Identitäten ist nicht mehr öffentlich. Bei seiner Vorführung auf der Black Hat USA im kommenden Monat in Las Vegas will er zeigen, welches Risiko diese Standardeinstellung für Microsoft und dessen Kunden darstellte. Bekannte aktive Ausnutzungen der Schwachstelle gebe es bislang nicht.
Der Forscher ordnet den Fall als Beispiel dafür ein, wie sich unauffällige Fehlkonfigurationen und Logikfehler zu Angriffen mit hoher Wirkung verketten lassen. Für Organisationen empfiehlt er, Identitäten und Token in Cloud-Automatisierungskonten hinsichtlich ihres Umfangs zu prüfen. Zudem rät er dazu, nichts nach außen sichtbar zu machen, wenn dafür kein konkreter Bedarf besteht.
Die jetzt bekannt gewordene Lücke ist nicht die erste Schwachstelle in Azure Automation. Bereits 2021 entdeckten Forscher von Orca Security mit AutoWarp einen Fehler, über den sich Token verwalteter Identitäten von einem gemeinsam genutzten Sandbox-Server abziehen ließen. Orca meldete den Fund damals ebenfalls an das MSRC. Microsoft legte das Problem im März 2022 öffentlich offen und erklärte, es gebe keine Hinweise auf einen Missbrauch der Token.
Shavit betont jedoch die Unterschiede zwischen beiden Fällen. Zwar zielten beide Schwachstellen darauf ab, die verwaltete Identität eines Opfers zu extrahieren, die Angriffsketten seien aber verschieden. AutoWarp missbrauchte die Codeausführungskomponente des Dienstes, um eine Reverse Shell aufzubauen. Seine eigene Entdeckung betreffe dagegen keine Codeausführung. Während Orca AutoWarp als kritisch bezeichnete, erhielt die Schwachstelle keine CVE-Kennung und erscheint auch nicht in der National Vulnerability Database.