Microsoft hat am 9. September 2026 ein Framework namens Cloud Web Applications Threat Matrix vorgestellt, um Bedrohungen für cloudgehostete Webanwendungen und serverlose Plattformen zu strukturieren. Das Framework orientiert sich an der Methode 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 separate Untersuchung der Anwendungsebene und der Cloud-Plattform Lücken beim Verständnis eines Angriffs hinterlassen. So kann ein Angriff beispielsweise von einem Code-Repository oder einer exponierten Verwaltungsschnittstelle ausgehen und anschließend zu einer verwalteten Identität, einer Datenbank oder einem mit der Anwendung verbundenen Speicherdienst gelangen. Das Framework wurde daher entwickelt, um Sicherheitsteams eine gemeinsame Sicht auf die Angriffsphasen zu geben und ihnen dabei zu helfen festzustellen, was ihre Überwachungswerkzeuge erkennen 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 Auswirkungen.
Zu den von Microsoft vorgestellten Beispielen gehören die Übernahme von Subdomains nach der Löschung eines Cloud-Dienstes, während der DNS-Eintrag bestehen bleibt, 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 exponierter Verwaltungsschnittstellen. Das Framework behandelt außerdem das Einschleusen von Triggern für serverlose Funktionen über speziell erstellte Dateien oder Nachrichten sowie die Nutzung von Bereitstellungszugangsdaten, um auf Verwaltungsschnittstellen der Anwendung zuzugreifen oder deren Dateien zu verändern.
Weitere Techniken umfassen die Ausnutzung von Schwachstellen zur entfernten Codeausführung, die Verwendung von Modulen wie Kudu in Azure App Service, die Änderung von Zeitplanaufgaben 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 Metadaten-Schnittstellen 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 Auslesen von Geheimnissen aus Umgebungsvariablen und Konfigurationsdateien und den Zugriff auf Datenbanken und Protokolle der Anwendung. 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 Verfälschung von Website-Inhalten sowie die Ausnutzung der automatischen Skalierbarkeit zur Erhöhung der Rechnung – von Microsoft als Denial of Wallet bezeichnet. Hinzu kommt die Übernahme von Rechenressourcen für Mining, umfangreiche Scans oder das Weiterleiten 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, eine Multi-Faktor-Authentifizierung durchzusetzen, das Prinzip der geringsten Berechtigung auf Benutzer und Workloads anzuwenden und den Zugriff auf Anwendungen, Bereitstellungsumgebungen und sensible Ressourcen zu beschränken.
Außerdem wird empfohlen, Repositories und Build-Systeme zu schützen, Pakete und Erweiterungen aus vertrauenswürdigen Quellen zu verwenden und wiederverwendbare Zugangsdaten weder im Code noch in Konfigurationsdateien zu speichern. Zu den Prioritäten gehören die Zentralisierung von Sicherheitsprotokollen an geschützten Orten, die Verhinderung von Änderungen an Protokollierungseinstellungen, die Festlegung von Limits für Kontingente und Parallelität sowie von 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, um Anwendungsrisiken mit den Risiken der zugrunde liegenden Cloud zu verknüpfen. Das ist für Teams wichtig, die Anwendungen verwalten, die auf mehrere Repositories, Bereitstellungspipelines, Identitäten und Dienste verteilt sind. Das Framework bleibt jedoch ein Werkzeug zur Strukturierung von Bedrohungen und zur Priorisierung der Abwehr 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 die geeigneten Protokolle, Berechtigungen und Messwerte verfügbar sind – ein Punkt, den die Einführung der Matrix allein nicht löst.