Microsoft hat am 9. September 2026 ein Framework mit dem Namen Cloud Web Applications Threat Matrix vorgestellt, um Bedrohungen zu strukturieren, die sich gegen cloudgehostete Webanwendungen und serverlose Plattformen richten. Das Framework basiert auf dem Ansatz von MITRE ATT&CK zur Klassifizierung von Angreifertaktiken, konzentriert sich jedoch auf Angriffspfade, die Grenzen zwischen Anwendung, verwalteter Laufzeitumgebung, Workload-Identitäten, Entwicklungs- und Bereitstellungspipelines sowie verbundenen Cloud-Ressourcen überschreiten.
Microsoft zufolge kann die getrennte Untersuchung der Anwendungsschicht und der Cloudplattform Lücken beim Verständnis eines Angriffs hinterlassen. So kann ein Einbruch beispielsweise von einem Code-Repository oder einer offengelegten Verwaltungsschnittstelle ausgehen und anschließend zu einer verwalteten Identität, einer Datenbank oder einem mit der Anwendung verbundenen Speicherdienst weiterführen. Das Framework wurde daher entwickelt, um Sicherheitsteams eine gemeinsame Sicht auf die Angriffsphasen zu geben und ihnen dabei zu helfen, festzustellen, was ihre Überwachungstools sehen und was nicht.
Was deckt das Framework ab?
Das Framework unterteilt die Techniken in 11 Taktiken. Dazu gehören Ressourcenentwicklung, erster Zugriff, Ausführung, Persistenz, Rechteausweitung, Umgehung der Überwachung, Zugriff auf Zugangsdaten, Aufklärung, laterale Bewegung, Datensammlung und Wirkung.
Zu den von Microsoft vorgestellten Beispielen gehören die Übernahme von Subdomains nach dem Löschen eines Cloud-Dienstes bei gleichzeitigem Fortbestehen des DNS-Eintrags, das Einschleusen von Code in ein mit der automatischen Bereitstellung verbundenes Repository, das Einschleusen eines schädlichen Container-Images in eine private Registry sowie die Ausnutzung offengelegter Verwaltungsschnittstellen. Das Framework behandelt außerdem das Einschleusen von Triggern für serverlose Funktionen über speziell erstellte Dateien oder Nachrichten sowie die Verwendung von Berechtigungsnachweisen für die Bereitstellung, um auf Verwaltungsschnittstellen der Anwendung zuzugreifen oder deren Dateien zu verändern.
Weitere Techniken umfassen die Ausnutzung von Schwachstellen zur Remotecodeausführung, die Verwendung von Modulen wie Kudu im Azure App Service, die Änderung von Planungsaufgaben oder Quellcode zur Aufrechterhaltung des Zugriffs sowie die Nutzung gültiger Cloud-Konten. Microsoft warnt außerdem vor dem Zugriff auf Token von Workload-Identitäten über Metadatenschnittstellen und vor der Wiederverwendung von Konnektoren, die authentifizierte Sitzungen mit externen Diensten aufrechterhalten.
Risiken gehen über Datendiebstahl hinaus
Das Framework beschränkt die Auswirkungen nicht auf einen herkömmlichen Einbruch. Es behandelt die Deaktivierung der Cloud-Protokollierung oder die Änderung von Richtlinien zur Protokollaufbewahrung sowie das Extrahieren von Geheimnissen aus Umgebungsvariablen und Konfigurationsdateien und den Zugriff auf Anwendungsdatenbanken und -protokolle. Detaillierte Protokolle können Schlüssel, personenbezogene Daten oder interne Pfade enthalten, die bei späteren Angriffen hilfreich sind.
Das Framework führt außerdem betriebliche und finanzielle Risiken auf, etwa das Löschen von Daten oder die Verunstaltung von Website-Inhalten sowie die Ausnutzung der automatischen Skalierbarkeit zur Erhöhung der Rechnung – von Microsoft als Denial of Wallet bezeichnet. Hinzu kommt die Entführung von Rechenressourcen für Mining, groß angelegte Scans oder die Weiterleitung von Datenverkehr.
Was ändert sich praktisch für Sicherheitsteams?
Der praktische Wert besteht darin, die Sicherheitsprüfung von der Frage „Ist die Anwendung geschützt?“ auf die Untersuchung der gesamten Vertrauenskette zu verlagern: vom Repository und der Build-Pipeline über die Laufzeitumgebung und die Identität bis hin zu den verbundenen Diensten. Microsoft empfiehlt, die Multi-Faktor-Authentifizierung durchzusetzen, das Prinzip der geringsten Rechte auf Benutzer und Workloads anzuwenden sowie den Zugriff auf Anwendungen, Bereitstellungsumgebungen und sensible Ressourcen zu beschränken.
Außerdem wird empfohlen, Repositorys und Build-Systeme zu schützen, Pakete und Erweiterungen aus vertrauenswürdigen Quellen zu verwenden und wiederverwendbare Zugangsdaten nicht im Code oder in Konfigurationsdateien zu speichern. Zu den Prioritäten gehören die Zentralisierung von Sicherheitsprotokollen an geschützten Standorten, die Verhinderung von Änderungen an Protokollierungseinstellungen, das Festlegen von Grenzen für Kontingente und Parallelität sowie Finanzwarnungen – zusätzlich zum Testen von Sicherungs- und Wiederherstellungsplänen.
Die certi.news-Einordnung
Die eigentliche Entwicklung besteht hier nicht in der Einführung eines neuen Produkts, sondern in der Bereitstellung eines einheitlichen Modells, mit dem sich Anwendungsrisiken mit den Risiken der zugrunde liegenden Cloud verknüpfen lassen. Das ist für Teams wichtig, die Anwendungen verwalten, die auf mehrere Repositorys, Bereitstellungspipelines, Identitäten und Dienste verteilt sind. Das Framework bleibt jedoch ein Instrument zur Strukturierung von Bedrohungen und zur Festlegung von Verteidigungsprioritäten und ist kein Beleg dafür, dass eine Organisation eine vollständige Abdeckung jeder Technik besitzt. Wie wirksam es eingesetzt werden kann, hängt außerdem davon ab, ob in jeder Umgebung geeignete Protokolle, Berechtigungen und Messwerte verfügbar sind – ein Punkt, den die Einführung der Matrix allein nicht löst.