2025 Landschaft der Bedrohungsjagd und -abwehr in der Cloud

Executive Summary

Insikt Group beobachtet einen anhaltenden Wachstumstrend und eine verstärkte Aktivität von Bedrohungsakteur , die Cloud-Infrastrukturen nutzen und ausnutzen, um die Zahl der Opfer, die sie ins Visier nehmen und infizieren, zu erhöhen. Aktuelle Berichte über die beobachteten zeigen, dass sich Cloud-bezogene Bedrohungen auf einige wenige konsistente Muster konzentrieren, die als Hauptabschnitte dieses Berichts dienen:

In allen Fällen erfolgt der erste Zugriff häufig über anfällige oder falsch konfigurierte Dienste, die dem Internet ausgesetzt sind – darunter Application Delivery Controller, Monitoring-Dashboards, E-Mail-Sicherheitsgateways und Enterprise Resource Planning (ERP)-Plattformen – sowie über gestohlene oder schlecht kontrollierte Anmeldedaten aus öffentlichen Leaks, kompromittierte Entwickler-Workstations und durch Social Engineering manipulierte Helpdesk-Workflows. Sobald Bedrohungsakteur in eine Zielumgebung eingedrungen ist, nutzt er systematisch hybride Identitäts- und VPN-Infrastrukturen, um verzeichnissynchronisierte Konten, nicht-menschliche Identitäten und Führungskräfteidentitäten sowie privilegierte Cloud-Rollen ins Visier zu nehmen und so die mandantenweite administrative Kontrolle zu erlangen.

Die Aktivitäten nach dem Kompromiss zeichnen sich durch eine intensive Nutzung der integrierten Cloud- und SaaS-Funktionalität aus: Aufzählung und Exfiltration von Daten über native Speicher- und Backup-Dienste, Zerstörung oder Verschlüsselung von Cloud-Backups und Snapshots zur Erzielung von Wirkung, Manipulation statischer Frontends und Continuous Integration/Continuous Deployment (CI/CD)-Pipelines, um das Vertrauen in Anwendungen und Repositories zu untergraben, und Nutzung gängiger Plattformen wie Kalenderdienste als verdeckte Command-and-Control (C2)-Kanäle.

Im Vergleich zur vorherigen Version deuten die meisten der in diesem Bericht besprochenen Ereignisse darauf hin, dass Bedrohungsakteur ähnliche Bedrohungsverhaltensweisen an den Tag legt; allerdings scheinen sich seit der letzten Version drei spezifische Trends herausgebildet zu haben:

Die mit dem Missbrauch verbundenen Trends deuten auf einen Wandel in der Wahrnehmung Bedrohungsakteur hin und zeigen, dass Bedrohungsakteur die umfassenderen Vorteile der Cloud-Dienste von Kompromittierung erkunden.

Cloud-Bedrohungslandschaft herunterladen: Einblicke für Führungskräfte

Wichtige Erkenntnisse

Hintergrund

Die rasante Verbreitung und kontinuierliche Weiterentwicklung von Cloud-Diensten haben einen eigenständigen und sich stetig erweiternden Angriffsraum geschaffen, Bedrohungsakteur aktiv ausnutzt. Da Unternehmen zunehmend Kernsysteme und sensible Daten aus traditionell isolierten, lokalen Umgebungen in internetzugängliche Cloud-Plattformen verlagern, betrachtet Gegner diese Bereitstellungen als eine zentralisierte Sammlung wertvoller Daten und oft schwacher Sicherheitskontrollen. Sie nutzen weit verbreitete Fehlkonfigurationen, uneinheitliche Cloud-Sicherheitsexpertise und die Einheitlichkeit der großen Cloud- und SaaS-Plattformen aus, indem sie öffentlich verfügbare Erkennungstools verwenden, um in großem Umfang nach exponierten Assets und unsicheren Einstellungen zu suchen. Gleichzeitig nutzt Bedrohungsakteur zunehmend Cloud-Infrastruktur für seine eigenen Operationen und verwendet kommerzielle Dienste, um Malware zu hosten, die Kommando- und Kontrollfunktionen aufrechtzuerhalten und die Datenexfiltration durchzuführen. Die gleiche Flexibilität, Reichweite und Verschleierung der Zuordnung, die Cloud-Dienste legitimen Nutzern bieten, ermöglicht es Bedrohungsakteur , bösartigen Datenverkehr mit legitimen Aktivitäten zu vermischen.

Die Verteidiger hingegen agieren in einem Umfeld, in dem Cloud Computing hinsichtlich der Akzeptanz bereits ausgereift ist, sich aber in Bezug auf die praktische Anwendung und sichere Implementierung noch in einem frühen Stadium befindet. Sicherheitsteams müssen sich mit sich schnell ändernden Produktangeboten, ständigen Funktionsaktualisierungen und komplexen, verteilten Architekturen auseinandersetzen, die es schwierig machen, vollständige Transparenz und konsistente Kontrollen über Regionen, Mandanten und Dienste hinweg aufrechtzuerhalten. Viele Organisationen setzen Cloud-Technologien mit begrenzten internen Fachkenntnissen, unrealistischen Erwartungen oder suboptimalen Implementierungen ein und beklagen häufig einen Mangel an erfahrenen Fachkräften, die in der Lage sind, diese Umgebungen sicher zu konzipieren und zu verwalten. Fehlende Fähigkeiten und Kenntnisse, kombiniert mit dem Umfang und dem ständigen Wandel von Cloud-Umgebungen, führen zu Konfigurationsabweichungen, unüberwachten Assets und Sicherheitslücken. Als Folge davon stehen die Verteidiger vor einer wachsenden Herausforderung: Sie müssen hochverfügbare, global verteilte Systeme schützen, die zwar einen geschäftlichen Nutzen bieten, gleichzeitig aber die Angriffsfläche der Organisation und die Wahrscheinlichkeit eines erfolgreichen Kompromisses erhöhen.

Methodik

Dieser Bericht identifiziert fünf Hauptbedrohungen für Cloud-Umgebungen, die jeweils in einem eigenen Abschnitt näher erläutert werden:

Jeder Abschnitt enthält Radardiagramme, die die folgenden Attribute messen, die mit einer bestimmten Bedrohung verbunden sind. Diese Feststellungen wurden von Insikt Group durch die Untersuchung von Fällen getroffen, in denen ein Bedrohungsvektoren beobachtet wurde, um die folgenden Fragen zu beantworten:

Bedrohungen für Cloud-Umgebungen

Ausnutzung und Fehlkonfiguration

Abbildung 1 veranschaulicht und vergleicht Attribute, die mit Cloud-Missbrauch verbunden sind. Eine Beschreibung der einzelnen Attribute finden Sie im Abschnitt "Methodik " dieses Berichts.

Abbildung 1: Radardiagramm, das Ausbeutung und Fehlkonfiguration als Bedrohungsvektoren veranschaulicht (Quellen: Recorded Future)

Kosten der Auswirkungen: 3 (Mittel)

Wie die Insikt Group bereits festgestellt hat: „Die erfolgreiche Ausnutzung von Cloud-Infrastruktur oder der darin eingebetteten Technologien kann einem Bedrohungsakteur vielfältige Vorteile bringen, lässt sich aber nicht direkt in Kosten für das Opfer umsetzen.“ Diese Feststellung kann auch auf die Risiken angewendet werden, die von einer falsch konfigurierten Cloud-Infrastruktur ausgehen, wie in diesem Bericht erörtert wird. In beiden Fällen ermöglichen Ausnutzung und Fehlkonfiguration Bedrohungsakteur zwar häufig den ersten Zugriff, zusätzlichen internen Zugriff oder erweiterte Berechtigungen innerhalb einer Cloud-Umgebung, die Gesamtauswirkungen auf eine Cloud-Umgebung sind jedoch nicht explizit an die Ausnutzbarkeit oder die Fähigkeit eines Bedrohungsakteurzur Ausnutzung von Fehlkonfigurationen gebunden.

Häufigkeit: 5 (Sehr hoch)

Fehlkonfigurationen stellen ein häufiges Risiko in Cloud-Umgebungen dar, und die Bedrohungsforschung hat immer wieder gezeigt, dass sie von Bedrohungsakteur häufig als erster Zugriffsvektor ausgenutzt werden. Obwohl sie nicht so häufig für den Erstzugriff ausgenutzt werden, erben Cloud-Umgebungen eine Vielzahl von Sicherheitslücke-bezogenen Risiken durch Drittanbietertechnologien, die oft in sie eingebettet sind.

Insikt Group stellt außerdem fest, dass im vergangenen Jahr mehrere kritische Sicherheitslücke in Cloud-nativen Diensten identifiziert wurden; allerdings werden diese Sicherheitslücke nach Recherchen der Insikt Groupviel seltener entdeckt und offengelegt als Sicherheitslücke in den in die Cloud-Infrastruktur eingebetteten Technologien.

Entwicklungspotenzial: 3 (Mittel)

Das Risiko, das von Fehlkonfigurationen und der Ausnutzung Sicherheitslücke in Cloud-Umgebungen ausgeht, ist durch die darin implementierten Technologien und Dienste begrenzt. Mit der Verfügbarkeit neuer Technologien und Dienste sowie der Aktualisierung bestehender Technologien und Dienste können neue Risiken durch Fehlkonfigurationen und Missbrauch entstehen. Gleichzeitig kann Bedrohungsakteur diese Risiken nur im Kontext anfälliger oder falsch konfigurierter Technologien oder Dienste nutzen, wodurch das Gesamtentwicklungspotenzial dieses Risikos begrenzt wird.

Aufwand für die Durchführung: 2 (Niedrig)

Das externe Erkennen bekannter Fehlkonfigurationen und Sicherheitslücke ist für Bedrohungsakteur ein unkomplizierter Prozess. Es gibt zahlreiche Tools, die es Bedrohungsakteur ermöglichen, diese Schwachstellen programmatisch zu identifizieren und in einigen Fällen auch automatisch auszunutzen. Die Erforschung Sicherheitslücke ist wesentlich schwieriger als der Missbrauch und die Bewaffnung von Proof-of-Concept (PoC)-Exploits aus Open-Source-Quellen; basierend auf den von Recorded Future gesammelten Daten deuten Scan- und Ausnutzungsversuche jedoch darauf hin, dass die Aktivitäten im Zusammenhang mit der Offenlegung einer Sicherheitslücke Sicherheitslücke insbesondere die Aufklärung – eine deutlich größere Bedrohung für die Verteidiger darstellen.

Zusammenfassung der Bedrohung

Die im vergangenen Jahr gesammelten Daten deuten darauf hin, dass Fehlkonfigurationen in der Cloud und die Ausnutzung Sicherheitslücke weiterhin ein kritisches Risiko für die Verteidiger darstellen, neben gängigen Angriffsvektoren, die Bedrohungsakteur sowohl innerhalb als auch außerhalb von Cloud-Umgebungen ausnutzen wird. Diese Schwächen ermöglichen es Bedrohungsakteur , Zugang zu erhalten und eine falsche Legitimität in Cloud-Umgebungen herzustellen, was als Mittel dient, um ihre letztendlichen Ziele zu erreichen, indem sie die Umgebung kontinuierlich ins Visier nehmen.

Fehlkonfigurationen sind ein Problem, das Cloud-Anbieter, Architekten und Sicherheitsexperten in Cloud-Umgebungen ständig zu beheben versuchen; allerdings kann dieser Kreislauf menschlicher Fehlkonfigurationen auch zu Fehlkonfigurationen führen. Die mit der Überwachung, Identifizierung und Behebung von Fehlkonfigurationen in Cloud-Umgebungen verbundenen personellen, betrieblichen und finanziellen Kosten sind hoch. Da Cloud Computing weiterhin wächst, nehmen auch die Angebote cloudnativer Dienste und die Infrastruktur selbst stetig zu, was zu Herausforderungen bei der Risikominderung führt, da sich die Angriffsfläche von außen vergrößert. Die Verteidiger müssen über neue Versionen von Cloud-Diensten auf dem Laufenden bleiben, um sicherzustellen, dass die Best Practices für die Konfiguration eingehalten werden.

Die Ausnutzung von Sicherheitslücken in Cloud-Umgebungen wird aufgrund der verwalteten Natur der Cloud-Dienstleister nicht so häufig erkannt wie Fälle von Fehlkonfigurationen. Die Berichterstattung über Bedrohungen im Laufe des Jahres zeigt jedoch, dass die Ausnutzung sowohl innerhalb als auch am Rande von Cloud-Umgebungen erfolgt.

Ausblick

Es wird erwartet, dass Bedrohungsakteur sich weiterhin auf Cloud-Umgebungen als attraktive Ziele konzentrieren werden, indem sie eine Kombination aus Konfigurationsschwächen und der Ausnutzung anfälliger, öffentlich zugänglicher Technologien nutzen, insbesondere nach den Aufdeckungen Sicherheitslücke .

Ausgehend von den aktuellen Trends dürften Expositionsbedingte Risiken, einschließlich konfigurationsbezogener Probleme und ungepatchter oder neu aufgedeckter Sicherheitslücke, ein beständiger Faktor bei Cloud-Kompromissen bleiben, die oft den Erstzugriff ermöglichen und gleichzeitig interne Cloud-Dienste und die unterstützende Infrastruktur beeinträchtigen.

Mit der zunehmenden Beschleunigung der Cloud-Nutzung werden auch Umfang und Vielfalt der eingesetzten Dienste und Technologien zunehmen. Diese Erweiterung erhöht die Wahrscheinlichkeit sowohl ausnutzbarer Sicherheitslücke als auch unbeabsichtigter Expositionen und unterstreicht damit die Bedeutung skalierbarer Sicherheitskontrollen, zeitnaher Patches und kontinuierlicher Transparenz in Cloud-Umgebungen.

Minderungsmaßnahmen und Erkennung

Abbildung 2 veranschaulicht eine hypothetische Angriffskette, die Fehlkonfigurationen und Ausnutzungsmethoden beinhaltet. In dieser Visualisierung hat die Insikt Group jene Abschnitte der Angriffskette identifiziert, in denen Verteidiger am effizientesten nach Verhaltensweisen suchen und diese abmildern können, die mit Fehlkonfigurationen und Ausnutzungen in der Cloud zusammenhängen.

Figur 2: Visuelle Darstellung potenzieller Angriffsvektoren für Cloud-Missbrauch (Quelle: Recorded Future)

① Angriffsversuche auf öffentlich zugängliche Cloud-Dienste und -Geräte

Ungepatchte oder falsch konfigurierte, mit dem Internet verbundene Dienste, wie z. B. Anwendungsgateways, VPN-Portale und Webanwendungen, sind häufige Ziele für den ersten Zugriff. Eine erfolgreiche Ausnutzung kann die Ausführung von Remote-Code, den Diebstahl von Zugangsdaten und einen Ausgangspunkt für die laterale Ausbreitung in Cloud- und On-Premise-Ressourcen ermöglichen.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

② Skriptbasierte Post-Kompromiss-Aktivität

Nachdem sie Fuß gefasst haben, setzen Bedrohungsakteur häufig auf skriptbasierte Ausführung, wie beispielsweise PowerShell und andere Interpreter, mit Verschleierung und speicherbasierten TTPs , um Tools herunterzuladen, Abwehrmechanismen zu deaktivieren und sich lateral zu bewegen, während sie offensichtliche dateibasierte Indikatoren vermeiden.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

③ Nicht autorisierte Fernzugriffstools oder anomale Binärausführung

Bedrohungsakteur setzen häufig Fernzugriffs- und Verwaltungstools sowie umbenannte oder portable Binärdateien ein oder verwenden diese für andere Zwecke, um einen dauerhaften und interaktiven Zugriff zu gewährleisten. Diese Binärdateien geben sich oft als legitime Aktivitäten aus und nutzen möglicherweise geplante Aufgaben oder Dienste zur Gewährleistung der Datenbeständigkeit.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

④ Rechteausweitung durch Identitätsföderation oder Zugangsdatenmanipulation

Die auf die Cloud fokussierte Kampagne missbraucht zunehmend Identitäts- und Föderationsmechanismen, um Privilegien auszuweiten und dauerhaften Zugriff zu erhalten. Durch die Änderung von Verbundeinstellungen, den Missbrauch von Synchronisierungskonten, die Fälschung von Token oder die Erstellung von Hintertüridentitäten können Angreifer Benutzer imitieren, bestimmte Multi-Faktor-Authentifizierungsmechanismen (MFA) umgehen und selbst nach Passwortänderungen bestehen bleiben.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

Beispiele aus der Praxis

Die Insikt Group hat eine Liste von Ereignissen zusammengestellt, die im vergangenen Jahr veröffentlicht wurden und die die Bedrohungen durch Ausnutzung und Fehlkonfiguration verdeutlichen. Diese Ereignisse werden im Folgenden erläutert.

Bedrohungsakteur Missbrauch AzureHound zur Erkennung von Kompromittierungen in Microsoft Azure-Umgebungen

Am 24. Oktober 2025 veröffentlichte die Unit 42 von Palo Alto Networks einen Bericht, der detailliert beschreibt, wie Bedrohungsakteur AzureHound in Microsoft Azure-Umgebungen missbraucht. AzureHound ist ein Open-Source-Datenerfassungstool, das ursprünglich von SpecterOps (@SpecterOps) für Penetrationstests innerhalb der BloodHound-Suite entwickelt wurde. Gemäß Einheit 42 nutzen Bedrohungsakteur, insbesondere die iranisch-verbundene Gruppe Curious Serpens, die mutmaßlich staatlich unterstützte Bedrohungsakteur Void Blizzard und der Ransomware-Betreiber Storm-0501, AzureHound in den Post-Kompromiss-Erkennungsphasen, um Microsoft Entra ID (ehemals Azure Active Directory)-Umgebungen abzubilden. Diese Operationen zielten noch im August 2025 auf Azure-Mandanten in hybriden und Multi-Tenant-Umgebungen ab und ermöglichten es Bedrohungsakteur , umfassende Ermittlungen durchzuführen, die die laterale Bewegung und die Eskalation von Berechtigungen erleichterten.

Nach der Analyse von Unit 42 beginnt die Infektionskette, wenn Bedrohungsakteur mithilfe gestohlener Anmeldedaten oder Authentifizierungstoken ersten Zugriff auf die Azure-Umgebung eines Ziels erlangen. Bedrohungsakteur verwenden dann informationsstehlende Malware wie Raccoon Stealer und Redline, um Anmeldedaten und Sitzungstoken vom Browser des Opfers zu erlangen. Mithilfe dieser gestohlenen Authentifizierungsartefakte, einschließlich Benutzernamen und Passwörtern, Aktualisierungstoken oder JSON Web Tokens (JWTs), authentifiziert sich Bedrohungsakteur in der Azure-Umgebung. In einigen Fällen nutzen sie TTPs zur Ausnutzung der Multi-Faktor-Authentifizierungsmüdigkeit (MFA), um sich in der Microsoft Entra ID-Umgebung des Opfers zu authentifizieren. Nach der Authentifizierung verwenden Bedrohungsakteur verfügbare Token oder Dienstprinzipal- Anmeldedaten , um eine Verbindung zu Azure-APIs herzustellen.

Nach der Zugriffserstellung setzt Bedrohungsakteur AzureHound ein, um die folgenden Funktionen und Aktionen zu implementieren:

Die mutmaßliche Salt-Typhoon-Kampagne nutzte Citrix NetScaler Gateway, um eine SnappyBee-Backdoor einzuschleusen; ein Beispiel ist bei Recorded Future Malware Intelligence verfügbar.

Am 20. Oktober 2025 veröffentlichte das Cybersicherheitsunternehmen Darktrace einen technischen Blogbeitrag, in dem eine Kampagne gegen eine europäische Telekommunikationsorganisation detailliert beschrieben wurde. Laut Darktrace nutzte die Kampagne, die Anfang Juli 2025 begann, eine öffentlich zugängliche Citrix NetScaler Gateway Appliance, wahrscheinlich CVE-2023-3519, für den ersten Zugriff und setzte SnappyBee (auch bekannt als Deed RAT), eine Variante von ShadowPad, ein. CVE-2023-3519 ist eine kritische Sicherheitslücke, die die Ausführung von Remote-Code (RCE) in Citrix Application Delivery Controller (ADC)- und Citrix Gateway-Appliances ermöglicht. Darktrace ordnet die Kampagne mit mäßiger Sicherheit dem staatlich geförderten Bedrohungsakteur Salt Typhoon zu.

Nach dem Erhalt des Zugangs verlagerte der Bedrohungsakteur seine Aktivitäten vom Kompromiss NetScaler Gateway auf interne Citrix Virtual Delivery Agent (VDA)-Hosts innerhalb des Machine Creation Services (MCS)-Subnetzes der Organisation. Um ihre Infrastruktur zu verschleiern und die Zuordnung zu erschweren, leitete der Bedrohungsakteur seinen ersten Zugriff über einen Endpunkt, der mit dem SoftEther Virtual Private Network (VPN)-Dienst verbunden ist. Nachdem der Bedrohungsakteur in das Netzwerk eingedrungen war, verteilte er SnappyBee als Dynamic-Link-Library-Datei (DLL) auf mehrere interne Citrix VDA-Hosts, gebündelt zusammen mit legitimen Antivirenprogrammen (AV), wie Norton, Bkav und IObit Malware Fighter, und führte es mittels DLL-Sideloading aus.

Eine Sicherheitslücke im OneDrive-Dateiauswahldialog von Microsoft ermöglicht Webanwendungen uneingeschränkten Lesezugriff auf das gesamte OneDrive der Benutzer.

Am 28. Mai 2025 veröffentlichte Oasis Security einen technischen Blogbeitrag, in dem eine Schwachstelle im OneDrive-Dateiauswahldialog von Microsoft detailliert beschrieben wurde. File Picker ist eine Webkomponente, die es Anwendungen ermöglicht, über OAuth-Autorisierung auf Dateien im OneDrive-Speicher eines Benutzers zuzugreifen, diese hochzuladen und herunterzuladen. Der Dateiauswahldialog (Versionen 6.0 bis 7.2 mit implizitem Flow und 8.0 mit Microsoft Authentication Library) fordert immer die breiten Berechtigungen Files.Read.All, Files.ReadWrite.All und offline_access an. Als Folge davon gewährt selbst die Zustimmung zum Hochladen einer einzelnen Datei Apps stillschweigend vollen und dauerhaften Lese- und Schreibzugriff auf das gesamte OneDrive des Benutzers.

Laut Oasis Security können Webanwendungen wie ChatGPT, Slack, Trello, ClickUp und andere, die OneDrive-Datei-Uploads unterstützen, unbeabsichtigt vollen Lesezugriff auf das gesamte OneDrive-Konto eines Benutzers erhalten, selbst wenn nur eine einzige Datei hochgeladen wird. Da der OneDrive File Picker in zahlreiche und vielfältige SaaS-Anwendungen integriert ist, ist die Schwachstelle sowohl weit verbreitet als auch trivial ausnutzbar: Eine bösartige App muss lediglich den Picker hosten und dann das Autorisierungstoken des Benutzers aus localStorage oder sessionStorage lesen, um alle im OneDrive-Konto des Benutzers gespeicherten Dateien aufzulisten oder zu exfiltrieren.

Oasis meldete den Fehler an Microsoft, woraufhin Microsoft die Anbieter informierte, die OneDrive File Picker implementierten. Zum Zeitpunkt der Veröffentlichung dieses Artikels hat Microsoft noch keine Lösung bereitgestellt; laut Oasis erklärte Microsoft jedoch, dass man „zukünftige Verbesserungen in Betracht zieht, darunter eine präzisere Abstimmung zwischen den Funktionen des OneDrive-Dateiauswahldialogs und den dafür erforderlichen Zugriffsrechten“.

Der Fehler liegt darin begründet, dass der Dateiauswahldialog keine fein abgestuften OAuth-Bereiche bietet. Wenn ein Benutzer einer Webanwendung wie ChatGPT oder Slack die Berechtigung erteilt, eine Datei über OneDrive hochzuladen, fordert der Dateiauswahldialog vollen Lesezugriff (und in einigen Fällen auch Schreibzugriff) auf das gesamte OneDrive-Verzeichnis an. Dies liegt an den übermäßig weit gefassten, vordefinierten Berechtigungen in Microsoft Graph, die nicht für Zugriffsszenarien auf einzelne Dateien angepasst werden können. Anstatt also ausschließlich Zugriff auf eine bestimmte Datei zu gewähren, gewähren die über die Dateiauswahl ausgegebenen OAuth-Token Zugriff, der über die ausgewählte Datei hinausgeht und sich auf das gesamte OneDrive-Verzeichnis des Benutzers erstreckt. Diese Token fordern häufig den offline_access Zugriffsbereich an, wodurch Anwendungen den Zugriff über die Sitzung des Benutzers hinaus für längere Zeiträume aufrechterhalten können.

Dieser Konstruktionsfehler erhöht das Risiko aufgrund von mehrdeutigen Zustimmungsabfragen, die den Eindruck erwecken, der Zugriff sei auf ausgewählte Dateien beschränkt; in Wirklichkeit erhalten Anwendungen jedoch Berechtigungen, ohne dass der Benutzer davon Kenntnis hat. In der Version 7.0 von File Picker werden sowohl Lese- als auch Schreibberechtigungen angefordert, selbst in Upload-Szenarien, und während Version 8.0 die Authentifizierung an die Entwickler delegiert, werden keine engeren Berechtigungen erzwungen. Infolgedessen können Benutzer unwissentlich sensible Daten an Drittanwendungen weitergeben, die einen weitaus größeren Zugriff haben als beabsichtigt.

Der zweite Fehler liegt in der unsicheren Speicherung sensibler Authentifizierungstoken, wie z. B. Zugriffs- und Aktualisierungstoken, insbesondere in älteren Versionen des Dateiauswahldialogs (6.0 bis 7.2). Diese Versionen verwenden die Autorisierungsmethode „Implicit Flow“, die Zugriffstoken über URL-Fragmente offenlegt und diese als Klartext im localStorage des Browsers speichert, wodurch bösartige Skripte oder Browsererweiterungen leicht darauf zugreifen können. In neueren Versionen wie 8.0, bei denen die Authentifizierung über die Microsoft Authentication Library (MSAL) erfolgt, speichern Entwickler häufig Token im sessionStorage ohne Verschlüsselung oder Sicherheitsvorkehrungen, was zu erheblichen Sicherheitsrisiken führt. Diese unsicheren Speicherpraktiken ermöglichen es Bedrohungsakteur , mit Zugriff auf den Browserkontext Tokens leicht zu kapern und vollen Lesezugriff auf das OneDrive-Konto zu erlangen.

Basierend auf den mit der Schwachstelle verbundenen Berichten könnte Bedrohungsakteur diese Schwachstelle auf mindestens zwei Arten ausnutzen:

In beiden Ausnutzungsszenarien ist nur eine minimale Benutzerinteraktion erforderlich. Angesichts der weitverbreiteten Nutzung des OneDrive-Dateiauswahldialogs auf zahlreichen Kollaborations- und Produktivitätsplattformen ist dieser Fehler weit verbreitet, da jede Webanwendung betroffen ist, die den OneDrive-Dateiauswahldialog im Upload-Modus einbettet.

WhoAMI-Angriff nutzt Namensverwechslung von AMIs aus, um AWS-Umgebungen zu kompromittieren.

Am 12. Februar 2025 veröffentlichten die Datadog Security Labs einen Bericht, in dem der Angriff "WhoAMI" detailliert beschrieben wird. Dieser zielt auf eine Sicherheitslücke ab, die durch Namensverwechslungen bei Amazon Machine Images (AMIs) entsteht, die in Amazon Web Services (AWS)-Umgebungen verwendet werden. Ein AMI ist eine vorkonfigurierte virtuelle Maschinenvorlage, die zum Starten von Elastic Compute Cloud (EC2)-Instanzen in AWS verwendet wird und das Betriebssystem, die Anwendungen und die notwendigen Konfigurationen enthält. EC2 ist ein skalierbarer Cloud-Computing-Dienst, der virtuelle Server (Instanzen) zur Ausführung von Anwendungen auf AWS bereitstellt. Laut Datadog Security Labs, die die Sicherheitslücke im August 2024 entdeckten, kann Bedrohungsakteur bösartige AMIs in ahnungslose AWS-Konten einschleusen. Mithilfe des WhoAMI-Angriffs kann Bedrohungsakteur eine beträchtliche Anzahl von AWS-Umgebungen kompromittieren, darunter auch die von großen Organisationen. Bemerkenswerterweise hatte auch AWS selbst Nicht-Produktionssysteme, die vor der Implementierung von Korrekturen anfällig für dieses Problem waren. Um dieses Risiko zu minimieren, hat AWS die Funktion „Zulässige AMIs“ eingeführt, mit der Benutzer die AMI-Auswahl auf verifizierte Anbieter beschränken können.

Die Sicherheitslücke entsteht durch eine fehlerhafte Filterung von AMI-Suchanfragen mit der ec2:DescribeImages API. Viele Organisationen und Infrastructure-as-Code (IaC)-Tools, wie zum Beispiel Terraform, suchen dynamisch nach dem neuesten AMI, das einem bestimmten Namensmuster entspricht. Wenn die Suchanfrage das Attribut „owners“ weglässt, gibt AWS eine Liste von AMIs aus vertrauenswürdigen und nicht vertrauenswürdigen Quellen zurück. Bedrohungsakteur kann diesen Konstruktionsfehler ausnutzen, indem er ein bösartiges AMI mit einem Namen veröffentlicht, der einem offiziellen AMI mit einem aktuelleren Zeitstempel ähnelt, wodurch automatisierte Prozesse dieses AMI auswählen. Bei Verwendung zum Starten von EC2-Instanzen gewähren diese bösartigen AMIs Bedrohungsakteur die Kontrolle über die Cloud-Umgebung des Opfers, was potenziell zu unberechtigtem Zugriff, Datendiebstahl oder weiteren Netzwerkkompromittierungen führen kann. Laut Datadog beschränkt sich der Fehler nicht auf Terraform; er betrifft auch AWS-Befehlszeilenschnittstellen (CLI)-Befehle und verschiedene Programmiersprachen, darunter Python-, Go- und Bash-Skripte.

DataDog teilte die folgenden Schritte zur Ausnutzung einer Sicherheitslücke mit, um beliebigen Code in der AWS-Umgebung eines Opfers auszuführen und unbefugten Zugriff auf Cloud-Ressourcen zu erlangen:

  1. Erstellen Sie ein benutzerdefiniertes AMI mit eingebetteten schädlichen Nutzdaten, wie z. B. einer Hintertür oder einem Mechanismus zur Datenexfiltration.
  2. Benennen Sie das AMI ähnlich wie ein vertrauenswürdiges AMI und achten Sie darauf, dass es gängigen Namensmustern entspricht (z. B. ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*).
  3. Veröffentlichen Sie das AMI öffentlich oder teilen Sie es mit ausgewählten AWS-Konten.
  4. Stellen Sie sicher, dass es als das aktuellste AMI und nicht als die legitimen AMIs angezeigt wird.
  5. Veranlassen Sie das Opfer dazu, das AMI dynamisch über ein falsch konfiguriertes Skript oder IaC-Tool wie Terraform abzurufen, das das neueste AMI ohne Angabe des Eigentümers abruft.
  6. Veranlassen Sie das Opfer dazu, eine EC2-Instanz mit dem Kompromiss-AMI zu starten, wodurch der Code des Bedrohungsakteurin der Cloud-Umgebung des Opfers ausgeführt werden kann.
  7. Sicherstellung der Persistenz und Kontrolle über die Instanz, um weitere Ausnutzungen wie den Diebstahl von Zugangsdaten, die laterale Bewegung oder die Datenexfiltration zu ermöglichen.

Am 13. Februar 2025 veröffentlichte Datadog den whoAMI-Scanner, ein Open-Source-Tool, das Instanzen identifiziert und kennzeichnet, die nicht vertrauenswürdige AMIs verwenden. Laut Repository benötigt whoAMI-scanner ein zu scannendes AWS-Profil, eine Region und eine Liste vertrauenswürdiger AMI-Anbieterkonten. Werden keine Parameter angegeben, werden die vordefinierten Standardeinstellungen verwendet. Sobald die AWS-Konfiguration angegeben wurde, lädt whoAMI-scanner sie, ruft die AWS-Kontoidentität des Aufrufers ab und bestimmt, welche AWS-Regionen gescannt werden sollen. Für jede Region werden die laufenden EC2-Instanzen abgefragt und die zu jeder Instanz gehörende AMI-ID extrahiert. whoAMI-scanner überprüft diese AMIs dann anhand einer Datenbank bekannter AWS-Konten und kategorisiert sie als verifiziert, selbst gehostet, zugelassen (wenn die AWS-Funktion "Allowed AMIs" aktiviert ist) oder nicht verifiziert. Wenn whoAMI-scanner eine öffentliche AMI aus einer unbekannten oder nicht vertrauenswürdigen Quelle findet, kennzeichnet er die AMI als potenziell bösartig. whoAMI-scanner generiert einen zusammenfassenden Bericht, der den Status aller analysierten AMIs anzeigt und die Benutzer vor nicht verifizierten Instanzen warnt. Falls angegeben, schreibt whoAMI-scanner auch in eine CSV-Datei. Schließlich informiert whoAMI-scanner die Betreiber über den Status der AWS-Funktion „Allowed AMIs“ und empfiehlt Maßnahmen zur Sicherung ihrer Umgebungen.

Koordinierte Ausnutzung der Grafana-Sicherheitslücke CVE-2021-43798 in Cloud-Umgebungen

Am 2. Oktober 2025 veröffentlichte GreyNoise einen Bericht über einen koordinierten eintägigen Anstieg von Ausnutzungsversuchen gegen Grafana-Instanzen, die anfällig für CVE-2021-43798 sind, eine Pfadtraversierungslücke, die das Lesen beliebiger Dateien auf exponierten Systemen ermöglicht. Die am 28. September 2025 beobachtete Aktivität umfasste 110 bösartige IP-Adressen, die sich auf über das Internet zugängliche Grafana-Installationen in den Vereinigten Staaten, der Slowakei und Taiwan konzentrierten. Dies unterstreicht, wie lange gepatchte, aber weit verbreitete Software in Cloud- und Hybridumgebungen nach wie vor ein wertvoller Aufklärungs- und erster Zugriffsvektor ist.

Im Zentrum der Angriffskette stehen HTTP-Anfragen, die die Sicherheitslücke CVE-2021-43798 (Path Traversal) ausnutzen, um beliebige Dateien von Grafana-Servern zu lesen. Diese Server befinden sich, wenn sie mit dem Internet verbunden sind, üblicherweise in der Cloud-Infrastruktur oder fungieren als Monitoring-Frontends für Cloud-Workloads. Eine erfolgreiche Ausnutzung kann sensible Konfigurations- oder Zugangsdaten offenlegen und so Folgeaktionen wie die Dienstermittlung, die laterale Bewegung in zugrunde liegende Cloud-Ressourcen oder den Wechsel zu anderen verwalteten Diensten ermöglichen. GreyNoise weist darauf hin, dass die Grafana- Sicherheitslücke, einschließlich CVE-2021-43798, häufig in Aufklärungsphasen von mehrstufigen Exploit-Ketten und groß angelegten Server-Side Request Forgery (SSRF)- und Exploit-Wellen auftritt, die sich über verschiedene Software-Ökosysteme erstrecken. Dies unterstreicht ihre Rolle als wiederverwendbare Bausteine in Cloud-orientierten Toolchains und nicht als isolierte Fehler.

Der beobachtete Anstieg wies eine enge Abstimmung der Zielauswahl und der verwendeten Werkzeuge auf: Der Datenverkehr aus mehreren Ländern folgte einem einheitlichen Zielverhältnis (ungefähr 3:1:1 in den USA, der Slowakei und Taiwan), wobei übereinstimmende TCP- und HTTP-Fingerabdrücke darauf hindeuteten, dass verschiedene Infrastrukturgruppen, hauptsächlich aus Bangladesch, mit kleineren Clustern in China und Deutschland, wahrscheinlich gemeinsame Aufgaben ausführten oder ein Standard-Exploit-Kit und eine Zielliste wiederverwendeten. In einem Cloud-Kontext spiegelt dieses Muster wider, wie Gegner „wiederauflebende“ Sicherheitslücke operationalisieren. Angreifer werden ältere Sicherheitslücke, wie beispielsweise CVE-2021-43798, und neuere Grafana-Schwachstellen in automatisierte Scanner- und Exploit-Frameworks integrieren, um kontinuierlich große Bereiche öffentlicher Cloud-Adressräume nach ungepatchten Instanzen zu durchsuchen. Sie werden dann selektiv von beliebigen Dateilesevorgängen zu umfassenderen Kompromittierungen eskalieren, wenn wertvolle Telemetriedaten oder Anmeldedaten entdeckt werden.

Nutzung der ESG-Kriterien von Barracuda und deren Auswirkungen auf den belgischen VSSE

Zwischen dem 26. und 27. Februar 2025 berichteten Reuters und Recorded Future News , dass der belgische Staatssicherheitsdienst (VSSE) angeblich von Hackern mit Verbindungen nach China über die Email Security Gateway (ESG)-Appliance von Barracuda Networks kompromittiert wurde, was eine bundesgerichtliche Untersuchung und die Entscheidung der Behörde zur Folge hatte, die Dienste von Barracuda nicht mehr zu nutzen. Diese Aktivität steht in Verbindung mit einer früheren Kampagne , in der die China-nahe Gruppe UNC4841 die Zero-Day Sicherheitslücke von Barracuda ESG ausnutzte , um langfristige Spionage gegen Regierungs- und andere hochrangige Ziele durchzuführen.

Der primäre Ausnutzungspfad nutzte bösartige E-Mail-Anhänge, um die Einschleusung von Remote-Befehlen in die ESG-Komponente zur Überprüfung von Anhängen (CVE-2023-2868) auf betroffenen lokalen ESG-Versionen auszulösen. Erstellte .tar Archives missbrauchte den qx Operator von Perl, um beliebige Systembefehle auf dem Gateway auszuführen, das vor den Mailservern sitzt und einen privilegierten Einblick in die E-Mail-Flüsse bietet. Anschließend setzte UNC4841 maßgeschneiderte Malware ein, darunter SALTWATER (ein trojanisiertes Simple Mail Transfer Protocol [SMTP]-Modul, das die Ausführung von Befehlen und Tunneling ermöglicht), SEASPY (eine Backdoor, die sich als BarracudaMailService ausgibt und durch „Magic Packets“ ausgelöst wird) und SEASIDE (ein Lua-Modul, das SMTP HELO/EHLO-Daten in Reverse Shells umwandelt), um ESGs in persistente Zugriffs- und Knoten zu verwandeln. Barracuda enthüllte später eine weitere Ausnutzung von CVE-2023-7102 in der Spreadsheet::ParseExcel Bibliothek, wiederum über bösartige Excel-Anhänge, um aktualisierte SEASPY- und SALTWATER-Varianten nach der ersten Behebung erneut zu installieren.

Belgian Berichterstattung berichtet, dass diese auf Barracuda fokussierte Angriffskette zwischen 2021 und 2023 die Exfiltration von etwa 10 % des E-Mail-Verkehrs von VSSE über einen externen Mailserver ermöglichte, der für die Kommunikation mit Ministerien, Polizei, Staatsanwaltschaft und ausländischen Partnern genutzt wurde. Obwohl die internen Systeme der VSSE angeblich nicht als vertraulich eingestuft waren, wurde über denselben externen Server die gesamte Korrespondenz im Personalbereich abgewickelt, wodurch persönliche Daten von fast der Hälfte der Mitarbeiter und Bewerber der VSSE offengelegt wurden und die betroffenen Mitarbeiter gezwungen waren, ihre Ausweisdokumente zu erneuern. Der Fall veranschaulicht, wie der Kompromiss eines einzelnen E-Mail-Sicherheitsgateway-Produkts durch die iterative Ausnutzung der Parsing- Sicherheitslücke von Barracuda ESG und den Einsatz maßgeschneiderter Implantate direkt in die strategische Informationsbeschaffung und die Offenlegung sensibler Personendaten für einen europäischen Geheimdienst umgesetzt wurde.

Cloud-Missbrauch

Figur 3: Radardiagramm zur Veranschaulichung von Ausbeutung als Bedrohungsvektoren (Quellen: Recorded Future)

Kosten der Auswirkungen: 4 (hoch)

Der Missbrauch von Cloud-Diensten, insbesondere der Missbrauch von Cloud-Ressourcen von Kompromiss, kann für Cloud-Nutzer hohe finanzielle, betriebliche und reputationsbezogene Kosten verursachen. Wie aus Berichten aus dem vergangenen Jahr hervorgeht, die später in diesem Abschnitt vorgestellt werden, nutzen Bedrohungsakteur häufig die Cloud-Infrastruktur von Kompromiss aus, um innerhalb der Umgebung eines Opfers Legitimität zu wahren und kostspielige Operationen durchzuführen, für die der Mieter verantwortlich gemacht wird. Darüber hinaus müssen die Anbieter in Fällen, in denen Bedrohungsakteur verwaltete Cloud-Dienste registrieren und diese für böswillige Aktivitäten missbrauchen, mit negativen Auswirkungen auf ihren Ruf rechnen.

Gemeinsamkeit: 4 (Hoch)

Cloud-Missbrauch ist eine weit verbreitete Bedrohung, die sowohl von legitimer Infrastruktur als auch von Infrastruktur unter der Kontrolle von Bedrohungsakteur ausgeht. Auf Grundlage der in diesem Bericht präsentierten Beweise identifiziert und entwickelt Bedrohungsakteur neue Methoden, um legitime Cloud-Dienste für Aktivitäten wie Malware-Hosting, C2-Hosting und Datenexfiltration auszunutzen.

Entwicklungspotenzial: 5 (Schwerwiegend)

Die im vergangenen Jahr gemeldeten Fälle von Cloud-Missbrauch zeigen, dass Bedrohungsakteur Cloud-Dienste zunehmend als Teil ihrer C2-Infrastruktur missbrauchen und damit bösartige Nutzlasten hosten und ausliefern. Die Methoden, Bedrohungsakteur zur Durchführung dieser Aktionen einsetzen, haben sich ebenfalls weiterentwickelt, was zeigt, dass Bedrohungsakteur aktiv nach neuen Wegen suchen, um Cloud-Dienste zu missbrauchen.

Aufwand für die Durchführung: 1 (Minimal)

Bedrohungsakteur kann problemlos legitime Cloud-Dienste registrieren, die dann für böswillige Zwecke missbraucht werden können. Viele Cloud-Service-Anbieter benötigen zur Registrierung für ihre Dienste lediglich eine E-Mail-Adresse und eine Zahlungsmethode. Darüber hinaus kann die Infrastruktur eines Kompromittierungsopfers in der Cloud-Umgebung aufgrund einer umfassenderen Kompromittierung der Cloud-Umgebung leicht von einem Bedrohungsakteur missbraucht werden.

Zusammenfassung der Bedrohung

Cloud-Missbrauch bezeichnet die Nutzung legitimer Cloud-Dienste und -Infrastruktur durch einen Bedrohungsakteur zur Durchführung böswilliger Handlungen. Diese Bedrohung lässt sich im Allgemeinen in zwei Hauptgruppen von Aktivitäten einteilen: den Missbrauch von Cloud-Ressourcen, die Bedrohungsakteurkontrolliert werden, und den Missbrauch von Cloud-Ressourcen, die Opfer von Kompromiss sind.

Insikt Group hat im vergangenen Jahr festgestellt, dass der Missbrauch von Cloud-Ressourcen von Kompromittierungsopfern vermehrt gemeldet wird. Berichterstattung, die im Abschnitt Beispiele aus der Praxis näher erläutert wird, zeigt, dass Bedrohungsakteur sich häufig in Cloud-Diensten anmelden oder Cloud-Infrastrukturen mit böswilligen Absichten entwickeln (hauptsächlich zum Hosten von Malware, Phishing-Websites oder Websites, die mit schädlichen Artefakten versehen sind, oder C2-Infrastruktur oder zum Ableiten von Fähigkeiten aus Cloud-Diensten, wie z. B. LLM-Diensten).

Insikt Group stellt fest, dass es im Gegensatz zu früheren Versionen dieses Berichts im vergangenen Jahr kaum öffentlich zugängliche Hinweise darauf gab, dass es entweder zu einem Anstieg oder zum Fortbestehen häufiger Missbrauchsverhaltensweisen von Cloud-Diensten bei Kompromiss-Opfern gekommen ist, wie beispielsweise Cryptojacking und Business Email Kompromiss (BEC).

Ausblick

Bedrohungsakteur wird sich wahrscheinlich weiterhin registrieren und Cloud-Dienste und -Infrastrukturen missbrauchen, um böswillige Aktionen durchzuführen.

Wie bereits in diesem Abschnitt erwähnt, identifiziert Bedrohungsakteur ständig neue Produkte und Methoden für den Missbrauch und demonstriert damit sowohl seine Kreativität bei der Erreichung bösartiger Ziele als auch die verschiedenen Cloud-Produkte, die es beschaffen und ausnutzen kann, um diese Ziele zu erreichen. Bedrohungsakteur erkennt die Anonymität an, die diese Produkte im Vergleich zu ähnlichen traditionellen Lösungen bieten, bei denen bösartiger Datenverkehr für die meisten Sicherheitsprodukte harmlos erscheint.

Bedrohungsakteur wird während einer Angriffskette wahrscheinlich weiterhin die Cloud-Dienste von Kompromiss missbrauchen, anstatt Rechendienste, die die Ausführung von benutzerdefiniertem Code ermöglichen, da der Missbrauch der Cloud-Dienste von Kompromiss-Opfern finanziell lukrativ sein kann oder für Bedrohungsakteur ein Mittel zur Verbreitung während eines Angriffs darstellt. Darüber hinaus hat Bedrohungsakteur im vergangenen Jahr ein Interesse daran gezeigt, cloudbasierte LLMs für Missbrauchszwecke ins Visier zu nehmen. Dieses Verhalten deutet auf eine Weiterentwicklung sowohl TTPs als auch Viktimologie Bedrohungsakteur hin und signalisiert, dass zukünftig auch andere Dienstleistungstypen ins Visier genommen werden könnten. Es deutet ferner darauf hin, dass Bedrohungsakteur es vorziehen, Cloud-Ressourcen zu missbrauchen, anstatt benutzerdefinierten Code in Cloud-Umgebungen auszuführen, um böswillige Ziele zu erreichen.

Minderungsmaßnahmen und Erkennung

Da es zwei unterschiedliche Bereiche im Zusammenhang mit Cloud-Missbrauch gibt, werden diese im Folgenden getrennt behandelt. Abbildung 4 zeigt eine hypothetische Angriffskette im Zusammenhang mit einem Bedrohungsakteurregistrierten Cloud-Missbrauch, während Abbildung 5 eine hypothetische Angriffskette im Zusammenhang mit einem Bedrohungsakteur festgestellten Missbrauch von Cloud-Diensten von Kompromiss-Opfern zeigt. In diesen Visualisierungen hat die Insikt Group jene Abschnitte der Angriffskette identifiziert, in denen Verteidiger am effizientesten nach Verhaltensweisen suchen und diese abmildern können, die mit beiden Bereichen des Cloud-Missbrauchs in Verbindung stehen.

Figur 4: Visuelle Darstellung potenzieller, Bedrohungsakteurregistrierter Cloud-Missbrauchsmethoden (Quelle: Recorded Future)

① Cloud-Infrastruktur für Malware-Hosting missbraucht
Bedrohungsakteur hostet schädliche Assets und Tools in seiner eigenen Cloud-Infrastruktur, wodurch diese während eines Angriffs in die Umgebungen der Opfer geladen werden können. Auch wenn diese Assets am Rande der Infrastruktur eines Bedrohungsakteurnicht immer direkt identifizierbar sind, können einige Bedrohungsakteur Webserver oder Dateisysteme offenlegen, die die schädlichen Assets enthalten, wodurch ein programmatischer Zugriff auf diese ermöglicht wird.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

② Datenexfiltration in vom Angreifer kontrollierte Cloud-Standorte
Im vergangenen Jahr hat Bedrohungsakteur immer wieder demonstriert, wie Cloud-Dienste und -Infrastrukturen bei Angriffen als Ziele für die Datenexfiltration genutzt werden. Ähnlich wie bei der oben diskutierten Bedrohung nutzen Bedrohungsakteur diese Dienste zur Datenexfiltration, da der während der Exfiltration erzeugte Datenverkehr harmlos erscheint und sich daher in gängige Netzwerkverkehrsmuster einfügen kann.

Obwohl diese Exfiltrationstaktiken TTPs aufgrund der harmlosen Natur dieses Datenverkehrs Erkennungs- und Abwehrprobleme darstellen, gibt es Methoden zur Erkennung und Abwehr dieser Bedrohung, die im Folgenden aufgeführt sind:

Wenn Bedrohungsakteur Daten aus einer Cloud-Umgebung exfiltrieren, nutzen sie bekanntermaßen Cloud-Service-Funktionen, um Exfiltrationskanäle einzurichten, anstatt traditionelle Exfiltrationsmethoden anzuwenden. Zur Erkennung und Beseitigung dieser Bedrohung können folgende Maßnahmen ergriffen werden:

Abbildung 5: Visuelle Darstellung potenzieller Missbrauchsmethoden von Cloud-Diensten (Quelle: Recorded Future)

① Missbrauch von Cloud-Diensten

Bedrohungsakteur kann Cloud-Dienste missbrauchen, um ressourcenintensive Operationen durchzuführen, ohne die damit verbundenen Kosten zu tragen und um es schwieriger zu machen, böswillige Operationen sich selbst zuzuordnen. Im Folgenden werden Möglichkeiten zur Erkennung und Abwehr dieser Bedrohungen erörtert:

② Missbrauch für On-Premises-Pivot

Bedrohungsakteur nutzt die Cloud-Dienste von Kompromiss, um in lokale Arbeitsstationen und Infrastrukturen einzudringen, oft indem er sich als legitime Cloud-Nutzer oder -Dienste ausgibt oder bestehende Verbindungen zwischen der Cloud-Umgebung und diesen Ressourcen ausnutzt. Zu den Methoden, mit denen diese Bedrohung erkannt und beseitigt werden kann, gehören folgende:

③ Missbrauch zur externen Verbreitung

Ähnlich wie oben beschrieben, versucht Bedrohungsakteur auch, Cloud-Dienste zu missbrauchen, um weitere Ziele zu infizieren, indem er sich als Mitglied der Organisation ausgibt, der die betroffene Cloud-Umgebung gehört. Im Folgenden werden Möglichkeiten zur Erkennung und Abschwächung dieses Verhaltens erläutert:

Beispiele aus der Praxis

Die Insikt Group hat eine Liste von Ereignissen zusammengestellt, die im vergangenen Jahr veröffentlicht wurden und die die Bedrohungen durch Cloud-Missbrauch verdeutlichen. Diese Ereignisse werden im Folgenden erläutert.

Der Infostealer LameHug von APT28 wurde beim Missbrauch von Qwen LLM während der Post-Kompromiss-Aktionen beobachtet.

Am 10. Juli 2025 berichtete CERT-UA, dass die russische staatlich geförderte Bedrohungsgruppe APT28 (auch bekannt als UAC-0001) Spear-Phishing-Angriffe gegen ukrainische Regierungsbehörden und Einheit im Verteidigungs- und Sicherheitssektor durchgeführt hatte. Die Kampagne beinhaltete den Einsatz eines neuen Python-basierten Infostealers namens LameHug. Dies ist der erste öffentlich dokumentierte Fall von Malware, die ein LLM integriert, um während der Laufzeit dynamisch Befehle zu generieren.

Die Kampagne begann mit E-Mails, die den Anschein erweckten, von einem Regierungsministerium zu stammen, und die ZIP-Archive mit Namen wie Appendix.pdf.zip oder Dodatok.pdf.zip enthielten. Diese enthielten .pif Dateien. Ausführbare Dateien, getarnt als PDFs, die mit PyInstaller gepackt sind, um LameHug im Speicher auszuführen. Die Schadsoftware nutzte ein gehacktes E-Mail-Konto (boroda70@meta[.]ua) zur Auslieferung von Schadsoftware und missbrauchte die Infrastruktur von Kompromiss, einschließlich der Domain stayathomeclasses[.]com. und IP-Adresse 144[.]126[.]202[.]227, für C2- und Exfiltrationsaktivitäten.

LameHug accessed Alibaba Cloud's Qwen 2.5-Coder-32B-Instruct LLM via Hugging Face API to generate system commands based on Base64-encoded prompts. This allowed it to evade static detection signatures and tailor its execution to victim environments in real time. Commands generated by the LLM performed reconnaissance using native Windows utilities, including systeminfo, wmic, tasklist, ipconfig, and dsquery. The collected data was stored locally at %PROGRAMDATA%\info\info.txt, and document files from user directories were staged for exfiltration.

Die beiden LameHug-Varianten verwendeten unterschiedliche Exfiltrationsmethoden: Die eine sendete Daten via HTTP POST an eine Kompromiss-Website, während die andere Secure File Transfer Protocol (SFTP) mit fest codierten Anmeldedaten nutzte. Beide Methoden exfiltrierten sensible Dateien wie Office-Dokumente und Systemaufklärungsergebnisse. Bemerkenswerterweise konnte die Malware keine Persistenz aufbauen, was mit der „Smash-and-Grab“-Taktik übereinstimmt, die auf kurzlebige Spionageoperationen ausgerichtet ist.

Mehrstufiger Cyberangriff „Operation SalmonSlalom“ zielt mit FatalRAT, der über Youdao Cloud Notes und MyQcloud CDN ausgeliefert wurde, auf Industrieunternehmen im asiatisch-pazifischen Raum ab.

Am 24. Februar 2025 veröffentlichte das Cybersicherheitsunternehmen Kaspersky einen Bericht, in dem die Operation SalmonSlalom detailliert beschrieben wird, eine mehrstufige Kampagne , die die FatalRAT-Hintertür in Industrieunternehmen in der APAC-Region einbringt. Die Operation zielt in erster Linie auf chinesischsprachige Nutzer in den Bereichen Fertigung, Telekommunikation und Energie in Taiwan, Malaysia, China, Japan, den Philippinen und anderen Ländern der Asien-Pazifik-Region ab. Die Bedrohungsakteur setzen stark auf legitime Cloud-Dienste, insbesondere Youdao Cloud Notes und das MyQcloud Content Delivery Network (CDN)/Objektspeicher von Tencent, um Konfigurationsdaten und Nutzdaten zu hosten. Dies ermöglicht es ihnen, ihre Infrastruktur zu rotieren und sich schnell in den regulären Datenverkehr einzufügen.

Die Angriffskette beginnt mit Phishing-E-Mails und WeChat- oder Telegram-Nachrichten, die ZIP-Archive als Steuerdokumente getarnt an Mitarbeiter von anvisierten Industrieunternehmen übermitteln. Diese Archive enthalten einen gepackten Loader der ersten Stufe (unter Verwendung von Packern wie UPX, AsProtect oder NSPack), der Youdao Cloud Notes kontaktiert, um eine aktualisierte Liste von URLs zu erhalten, die die Komponenten der zweiten Stufe, Before.dll (Konfigurator) und Fangao.dll (Loader), hosten. Before.dll ruft zusätzliche Konfigurationen aus den von Youdao gehosteten Notizen ab, einschließlich C2- und Payload-URLs, schreibt diese Daten in eine lokale Konfigurationsdatei und sendet grundlegende Systemprofilierungsdaten an den C2-Server. Fangao.dll liest dann diese Konfiguration, führt Umgebungsprüfungen durch (sie sucht nach Systemsprache und Dateipfaden und stellt sicher, dass die Zeitzone auf „UTC+8“ eingestellt ist), um sicherzustellen, dass sie auf einem Opfersystem ausgeführt wird. Im Erfolgsfall wird FatalRAT heruntergeladen und entschlüsselt.

Von dort aus nutzt die Kampagne eine Mischung aus GUI-gesteuertem Gruppenrichtlinienmissbrauch und DLL-Sideloading, um Persistenz herzustellen und FatalRAT aus der Cloud-Infrastruktur bereitzustellen. Fangao.dll automatisiert den Windows-Gruppenrichtlinien-Editor, um ein Anmeldeskript hinzuzufügen, das eine mit einem Trojaner infizierte Mediaplayer-Binärdatei startet. Dadurch wird eine direkte Änderung der Registrierung vermieden und die Erkennung erschwert. Anschließend nutzt es ein legitimes Treiber-Utility (DriverAssistant) zum DLL-Sideloading, indem es eine bösartige Loader-DLL platziert, die mit auf MyQcloud gehosteten Inhalten in Kontakt tritt, um FatalRAT herunterzuladen. Sobald FatalRAT aktiv ist, führt es Aufklärungs- und Anti-VM-Prüfungen durch, etabliert seine eigene Persistenz und unterstützt dann Keylogging, Dateiexfiltration, Befehlsausführung, Server Message Block (SMB) Brute Forcing zur lateralen Bewegung, optionale destruktive Aktionen (wie z. B. MBR-Überschreibungen) und die Bereitstellung von Fernzugriffstools wie UltraViewer und AnyDesk, um die interaktive Kontrolle über Kompromiss-Industrienetzwerke zu erweitern.

Die Cyber- Kampagne von APT41 nutzt das mehrstufige Malware-Framework TOUGHPROGRESS, das Google Kalender für die C2-Kommunikation verwendet.

Am 29. Mai 2025 veröffentlichte Insikt Group ein Validated Intelligence Event (VIE), das die Analyse der Google Bedrohungsinformationen Group (GTIG) über eine Cyber- Kampagne der APT41, einer staatlich geförderten chinesischen Bedrohungsakteur, zusammenfasst . Laut GTIG verwendet die Kampagne, die erstmals im Oktober 2024 beobachtet wurde, ein mehrstufiges Malware-Framework namens TOUGHPROGRESS, das Google Calendar als verdeckten Kanal für C2 ausnutzt. Die Kampagne zielt mit einer Phishing-Methode, die eine gefälschte Regierungswebsite nutzt, auf globale Regierungsorganisationen ab.

Basierend auf der Analyse von Mandiant sendet APT41 Spearphishing-E-Mails, die einen Link zu einem ZIP-Archiv namens 出境海關申報清單.zip enthalten. gehostet auf einer Kompromiss-Regierungswebsite. Dieses Archiv enthält eine Verknüpfungsdatei (LNK) mit dem Namen 申報物品清單.pdf.lnk. Es ist als PDF getarnt und verwendet die doppelte Dateierweiterung TTPs sowie ein Verzeichnis, das sieben Bilddateien enthält. Unter diesen scheinbar harmlosen Bilddateien enthält 6.jpg eine verschlüsselte Nutzlast, und 7.jpg ist eine DLL, die die Nutzlast entschlüsselt und ausführt. Wenn ein Opfer die LNK-Datei öffnet, führt diese die DLL aus, löscht sich selbst, um einer Erkennung zu entgehen, und öffnet eine gefälschte PDF-Datei, die einem Zollanmeldungsdokument ähnelt, um den Verdacht abzulenken.

Die entschlüsselte Nutzlast initiiert den folgenden dreistufigen Ausführungsprozess:

  1. PLUSDROP: In dieser Phase wird das nächste Modul entschlüsselt und in den Speicher geladen, wodurch ein unauffälliger, dateiloser Fortschritt ermöglicht wird.
  2. PLUSINJECT: In dieser Phase wird ein legitimer Windows-Prozess (svchost.exe) gekapert. durch Prozessaushöhlung zur Ausführung der endgültigen Nutzlast, TOUGHPROGRESS.
  3. TOUGHPROGRESS: Diese Phase führt die Kernfunktionalität auf dem Kompromiss-Host aus. Es verwendet ausgefeilte TTPs darunter registerbasierte indirekte Aufrufe, dynamische Kontrollflussverschleierung und 64-Bit-Arithmetiküberläufe. Es bettet Shellcode in die .pdata ein. einen Teil seines Codes, entschlüsselt ihn mit einem fest codierten sechzehn Byte langen XOR-Schlüssel und dekomprimiert ihn mit Hilfe des Lempel-Ziv NT Version 1 (LZNT1)-Algorithmus.

Nach der Aktivierung auf einem Komprom-System stellt TOUGHPROGRESS eine Bedrohungsakteurkontrollierte C2-Kommunikation über Google Kalender her. Es erstellt Kalenderereignisse ohne Dauer, um Daten zu exfiltrieren, und fragt den Kalender nach verschlüsselten Bedrohungsakteur -Befehlen ab, die für den 30. und 31. Juli 2023 geplant sind. TOUGHPROGRESS entschlüsselt diese Befehle mithilfe eines zweischichtigen XOR-Verfahrens, das einen statischen Zehn-Byte-Schlüssel mit einem dynamischen Vier-Byte-Schlüssel kombiniert, der für jede Nachricht generiert wird. Nach Ausführung der Befehle verschlüsselt TOUGHPROGRESS die Ergebnisse und lädt sie in neue Kalenderereignisse hoch, wodurch eine Vollduplex-Kommunikation über eine legitime Plattform hergestellt wird.

Dem Bericht zufolge störten Mandiant und GTIG die Infrastruktur von APT41, indem sie den Zugriff auf die bösartigen Workspace-Projekte entzogen und zugehörige URLs wie word[.]msapp[.]workers[.]dev blockierten. resource[.]infinityfreeapp[.]com, und hxxps://my5353[.]com/nWyTf, über Google Safe Browsing.

ACR-Stealer nutzt Dead Drop Resolver, um seine C2-Infrastrukturen zu verschleiern.

Am 1. März 2025 meldete Trend Micro Research einen Anstieg der Aktivitäten im Zusammenhang mit ACR Stealer, begleitet von einem neuen TTP-Update. ACR Stealer ist ein Malware-as-a-Service (MaaS)-Informationsdiebstahlprogramm, das von einem Bedrohungsakteur namens „SheldIO“ betrieben wird. Laut Trend Micro Research nutzt ACR Stealer fortschrittliche Dead-Drop-Resolver, um seine C2-Infrastruktur zu verschleiern, indem es legitime Plattformen wie Steam und Google Docs verwendet. Darüber hinaus berichtete Trend Micro Research über aktive Infektionen in mehreren Ländern, darunter die Vereinigten Staaten, Kanada, Deutschland, Frankreich, die Tschechische Republik, Brasilien, Peru, Schweden, Finnland und Indonesien in den letzten 30 Tagen.

Laut einer Analyse von Trend Micro Research verbreitet Bedrohungsakteur ACR Stealer über gecrackte Software-Downloads und nutzt die Cloudflare Web Application Firewall (WAF), um ihre Vertriebsdomains vor Erkennung zu schützen. Nach der Ausführung führt ACR Stealer die folgenden Aktionen auf dem Rechner des Opfers aus:

Missbrauch von AWS LLM-Diensten in Angriffsketten, die auf die Lieferkette für maschinelles Lernen abzielen

Am 27. Februar 2025 veröffentlichte Trend Micro einen Bericht, der einen mehrstufigen Machine-Learning-Lieferkettenangriff beschreibt, bei dem cloudbasierte AI -Dienste, insbesondere Amazon SageMaker und Amazon Bedrock, missbraucht werden, um LLM-gesteuerte Anwendungen zu kompromittieren. Die Quellen heben hervor, dass Fehlkonfigurationen, übermäßig privilegierte Rollen und ungeprüfte ML-Komponenten von Drittanbietern es einem Angreifer ermöglichen, von einem einzelnen exponierten SageMaker-Notebook in einem Entwicklungskonto zur vollständigen Kontrolle über Bedrock-basierte LLM-Workflows, Schutzmechanismen und auf Retrieval-Augmented Generation (RAG) basierende Wissensbasen in der Produktion zu gelangen.

Der Angriff beginnt im AWS-Konto des Entwicklers, wo eine SageMaker-Notebook-Instanz mit direktem Internetzugang und einer Standardausführungsrolle von Entwicklern verwendet wird, um Erweiterungen von Drittanbietern zu installieren. Der Angreifer veröffentlicht ein bösartiges Python-Paket, das ein Entwickler installiert und innerhalb dieses Notebooks ausführt. Dadurch wird dem Angreifer eine umgekehrte Shell geöffnet, die ihm die Ausführung von Befehlen auf der ML-Workstation ermöglicht. Von dort aus listet der Angreifer über die AWS CLI die SageMaker- und IAM-Ressourcen auf, entdeckt, dass die Rolle des Notebooks über weitreichende SageMaker- und iam:PassRole Berechtigungen verfügt, und verwendet sagemaker:CreateNotebookInstance plus sagemaker:CreatePresignedNotebookInstanceUrl um ein neues Notebook zu erstellen, das an eine administrative Rolle gebunden ist. Durch diese Rechteausweitung erlangt der Angreifer die effektive Kontrolle über das Entwicklerkonto und nutzt CloudTrail-Protokolle, um über sts:AssumeRole eine kontoübergreifende Bedrock-Rolle im Produktionskonto zu identifizieren und anzunehmen, wodurch er direkt in die LLM-Umgebung eindringt.

Sobald der Angreifer Zugriff auf das Produktionskonto erlangt hat, missbraucht er Bedrock Guardrails und nachgelagerte Automatisierungsmechanismen, um LLM-Interaktionen zu instrumentalisieren. Zunächst aktualisieren sie eine Schutzvorrichtung, die an einen Bedrock-Dialogagenten angehängt ist, sodass Eingabeaufforderungen, die Wörter wie „Wie“ oder „Was“ enthalten, blockiert und durch eine bösartige Blocknachricht ersetzt werden, die die Benutzer anweist, eine PDF-Datei von einer vom Angreifer kontrollierten URL herunterzuladen. Dabei wird die LLM-Chat-Oberfläche verwendet, um Malware durch eine ansonsten „sichere“ Infrastruktur zu verbreiten.

In einer eng verwandten Variante zielt der Angreifer auf ein Codegenerierungsmodell ab, dessen Ausgaben von einer AWS Lambda-Funktion ausgeführt werden; er vergiftet die Blocknachricht der Schutzvorrichtung mit Python-Code, der, wenn er weitergeleitet und ausgeführt wird, Anmeldedaten der Lambda-Rolle an eine vom Angreifer kontrollierte IP-Adresse exfiltriert und dem Gegner so die vollständige Kontrolle über die Geschäftslogikschicht der LLM-Anwendung ermöglicht. Mithilfe dieser Cloud- Anmeldedaten listet der Angreifer Bedrock-Agenten, Wissensdatenbanken und Datenquellen auf, leitet die RAG-Wissensdatenbank auf einen vom Angreifer kontrollierten Simple Storage Service (S3)-Bucket um, um die LLM-Antwort mit manipulierten Inhalten zu vergiften, und nutzt schließlich den S3-Zugriff (z. B. über aws s3 sync), um sensible Inferenzdaten zu exfiltrieren, darunter Benutzeraufforderungen und proprietäre Informationen, die das Verhalten des LLM steuern.

Cloud-Ransomware

Abbildung 6: Radardiagramm, das Cloud-Ransomware als Bedrohungsvektoren veranschaulicht (Quellen: Recorded Future)

Kosten der Auswirkungen: 5 (Schwerwiegend)

Die Opfer der Cloud-Ransomware Angriff erleiden hohe Kosten in finanzieller, betrieblicher und reputationsbezogener Hinsicht. Selbst wenn die Opfer sich weigern zu verhandeln, werden kritische Daten und Systeme effektiv unbrauchbar, je nachdem, welche Methode angewendet wird, um den Zugriff auf diese Ressourcen zu verweigern.

Häufigkeit: 3 (Mittel)

Ein Vergleich der im vergangenen Jahr beobachteten Cloud-Ransomware-Vorfälle mit früheren Berichten zeigt, dass Cloud-Ransomware-Vorfälle zwar weiterhin regelmäßig überwacht werden, aber nicht in großer Zahl auftreten.

Evolutionspotenzial: 4 (Hoch)

Bedrohungsakteur haben im vergangenen Jahr bewiesen, dass sie ständig neue Methoden zur Durchführung von Cloud-Ransomware-Angriffen identifizieren. Während die meisten dieser Angriffe nach wie vor auf die Nutzung nativer Cloud-Dienste durch Bedrohungsakteurangewiesen sind, lassen die von ihnen angewandten Methoden (und die von Bedrohungsforschern gemeldeten theoretischen Methoden) darauf schließen, dass in Zukunft wahrscheinlich weitere Angriffsmethoden auftauchen werden.

Aufwand für die Durchführung: 4 (Hoch)

Ähnlich wie Insikt Groupin früheren Berichten festgestellt hat, stellt die Abhängigkeit von Bedrohungsakteurvon Cloud-Diensten zur Durchführung von Cloud-Ransomware-Operationen sicher, dass ein tiefgreifendes Wissen über Cloud-Service-Provider-Umgebungen (CSP) weiterhin notwendig sein wird, um Cloud-Ransomware-Angriffe durchzuführen.

Zusammenfassung der Bedrohung

Bei Cloud-Ransomware-Angriffen wird der vertrauenswürdige Zugriff auf Cloud-Umgebungen ausgenutzt, um Cloud-Ressourcen zu verschlüsseln oder unzugänglich zu machen; dazu gehören Objektspeicher, virtuelle Festplatten, Datenbanken und Backups. Anstatt große Mengen an Binärdateien einzusetzen, verwendet Bedrohungsakteur Komprom-Konten, Rollen, Token und Schlüssel, um Verschlüsselungseinstellungen zu ändern, Schlüsselmaterial zu rotieren oder zu vernichten oder gespeicherte Daten massenhaft über Cloud-APIs und Konsolen zu modifizieren. Dadurch beschränkt sich die Aktivität hauptsächlich auf typische administrative Pfade und zwingt die Verteidiger, sich auf Verhaltensindikatoren zu verlassen, wie etwa ungewöhnliche Spitzenwerte bei der Verschlüsselung, Änderungen an Momentaufnahmen oder Massenspeicheroperationen.

Ausblick

Cloud-Ransomware wird auch weiterhin auf native Cloud-Dienste zurückgreifen, um große Mengen an Cloud-Daten schnell zu verschlüsseln oder unzugänglich zu machen.

Aufgrund der verwalteten Natur von CSP-Umgebungen, die im vergangenen Jahr die einzigen in der Berichterstattung über Cloud-Ransomware identifizierten Ziele waren, muss Bedrohungsakteur auf native Dienste zurückgreifen, um Daten während einer Cloud-Ransomware Kampagne zu verschlüsseln oder zu zerstören. Da diese nativen Dienste Bedrohungsakteur die Funktionalität bieten, die für die Durchführung destruktiver Aktionen gegen anvisierte Assets erforderlich ist, benötigt Bedrohungsakteur auch weiterhin privilegierten Zugriff innerhalb der Cloud-Umgebungen der Opfer, um Cloud-Ransomware-Angriff effektiv durchzuführen.

Minderungsmaßnahmen und Erkennung

Abbildung 7 veranschaulicht eine hypothetische Cloud-Ransomware-Angriff-Kette und identifiziert Teile der Angriffskette, in denen die Verteidiger am effizientesten nach damit verbundenen Verhaltensweisen suchen und diese abmildern können.

Abbildung 7: Visuelle Darstellung potenzieller Cloud-Ransomware-Angriff-Vektoren (Quelle: Recorded Future)

① Bedrohungsakteur Zugriff auf die Cloud-Umgebung des Opfers

In allen im Laufe des letzten Jahres beobachteten Ereignissen musste Bedrohungsakteur sich zunächst einen vertrauenswürdigen Zugang zur Umgebung des Opfers verschaffen. Dieser Zugriff, der dem Bedrohungsakteur erhöhte Berechtigungen innerhalb der Umgebung gewährt, ist für die Durchführung von Cloud-Ransomware-Angriffen notwendig, da Cloud-Ransomware-Angriffsketten auf den Missbrauch von Cloud-Diensten für Verschlüsselungs-, Exfiltrations- und Persistenzaktionen angewiesen sind.

Strategien zur Eindämmung und Bekämpfung dieses Verhaltens werden im Abschnitt „ Zugangsdatenmissbrauch, Kontoübernahme und unberechtigter Zugriff“ erörtert.
② Erkennung zur Unterstützung von Cloud-Ransomware-Aktivitäten

Nach der ersten Zugriffserstellung erstellt Bedrohungsakteur ein Profil der Cloud-Umgebung und führt eine Erkennung durch, um Assets für die Verschlüsselung und Dienste zu identifizieren, die missbraucht werden können, um Funktionen zu unterstützen, die für den Erfolg der Cloud-Ransomware-Angriff erforderlich sind.

Gängige Abwehr- und Bedrohungsabwehrmaßnahmen für dieses Verhalten umfassen Folgendes:

③ Missbrauch von Cloud-Diensten zur Verschlüsselung oder Zugriffsverweigerung

Ausgehend von den später in diesem Abschnitt erörterten Ereignissen greift Bedrohungsakteur auf native Cloud-Dienste zurück, um die Verschlüsselung von Cloud-Ressourcen durchzuführen oder Benutzern den Zugriff auf diese Ressourcen zu verweigern.

Da die Insikt Group beobachteten Methoden nur AWS- und Azure-Umgebungen betrafen, werden im Folgenden spezifische Abhilfemaßnahmen und Jagd-Vorschläge für jede Plattform aufgeführt:

Azurblau:

④ Einrichtung von Exfiltrations- und Persistenzkanälen

Vor Verschlüsselungs- oder Löschvorgängen versucht Bedrohungsakteur häufig, Kanäle zwischen der Umgebung des Opfers und seiner eigenen Infrastruktur herzustellen, über die er die Daten, die er unzugänglich macht, exfiltrieren kann, um eine doppelte Erpressung zu ermöglichen. Zusätzlich wird Bedrohungsakteur entweder vor oder nach der Verschlüsselung oder Löschung von Daten einen Persistenzkanal einrichten, der dazu dient, den Zugriff auf die Kompromittierungsdaten wiederherzustellen und in einigen Fällen die Kommunikation mit dem Opfer zu Verhandlungszwecken aufrechtzuerhalten.

Gängige Abwehr- und Bedrohungsabwehrmaßnahmen für dieses Verhalten umfassen Folgendes:

Beispiele aus der Praxis

Insikt Group hat eine Liste von Ereignissen zusammengestellt, die im Laufe des Jahres 2025 veröffentlicht wurden und die die Bedrohungen durch Cloud-Ransomware-Angriff verdeutlichen. Diese Ereignisse werden im Folgenden erläutert.

Aufschlüsselung der beobachteten TTPs von S3- Ransomware in AWS

Am 18. November 2025 veröffentlichte das Trend Research Team von Trend Micro einen Bericht, der untersucht, wie Ransomware-Betreiber von traditioneller, lokal installierter Verschlüsselungs-Malware zu Cloud-zentrierten TTPs übergehen, die native AWS-Funktionen ausnutzen, mit einem besonderen Fokus auf realen S3-Ransomware-Verhaltensweisen. Der Bericht hebt hervor, dass Angreifer zunehmend auf falsch konfigurierte Berechtigungen und gestohlene IAM- Anmeldedaten zurückgreifen, um Schreibzugriff auf S3-Buckets zu erlangen, geschäftskritische Speicher aufzulisten und die Daten anschließend unwiederbringlich zu machen (ohne unbedingt herkömmliche Binärdateien einzusetzen).

Eine der beobachteten TTPs konzentriert sich auf den Bedrohungsakteur Codefinger, der serverseitige S3-Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln (SSE-C) verwendete, um S3-Daten zu erpressen. Nachdem der Bedrohungsakteur über durchgesickerte Anmeldedaten für IAM-Rollen oder ein kompromittiertes AWS-Konto Schreibzugriff erlangt hat, durchsucht er S3-Buckets, um wertvolle Ziele zu finden, denen Schutzfunktionen wie Versionierung, Objektsperre und MFA-Löschfunktion fehlen. Anschließend wird SSE-C initiiert, indem ein lokal gespeicherter AES-256-Schlüssel über den Mechanismus x-amz-server-side-encryption-customer-algorithm (via REST API/HTTP oder AWS SDKs) bereitgestellt wird. Dadurch werden alle betroffenen Objekte von AWS verschlüsselt, ohne dass der Schlüssel selbst jemals gespeichert wird. Es wird lediglich ein Hash-basierter Methodenauthentifizierungscode (HMAC) in CloudTrail gespeichert, der nicht zur Entschlüsselung verwendet werden kann. Sobald die Verschlüsselung abgeschlossen ist, wird eine Lösegeldforderung im Bucket hinterlegt, sodass weder der Kunde noch AWS ohne den Schlüssel des Angreifers den Zugriff wiederherstellen können.

Der Bling Libra Bedrohungsakteur nutzte außerdem gestohlene AWS- Anmeldedaten , um auf S3 zuzugreifen, Bucket-Inhalte auf die vom Angreifer kontrollierte Infrastruktur zu exfiltrieren und anschließend die Daten oder den gesamten Bucket zu löschen. Manchmal hinterließ er Lösegeldforderungen im ursprünglichen Bucket oder in neu erstellten, mit Lösegeld gekennzeichneten Buckets. Trend Micro weist darauf hin, dass dieses Exfiltrations- und Löschmodell in der Praxis besonders wahrscheinlich ist, da es operativ einfach ist und eine Wiederherstellung unmöglich macht, wenn keine Versionierung oder Backups vorhanden sind. Im Einklang mit diesen TTPs hat Trend Vision One mithilfe von Telemetriedaten CloudTrail-basierte Verhaltensweisen im Zusammenhang mit der S3-Ransomware- Kampagne aufgezeichnet, darunter die Aufzählung von S3-Buckets, Massen-Downloads mit anschließender Löschung, Uploads von Lösegeldforderungen sowie Änderungen an IAM-Richtlinien oder administrativen Funktionen, die die Berechtigungen für S3-Ressourcen erweitern. All dies trägt zu effektiven Cloud-nativen Ransomware-Operationen gegen AWS-Umgebungen bei.

Storm-0501 Cloudbasierte Ransomware in hybriden Azure-Umgebungen

Am 27. August 2025 veröffentlichte Microsoft Bedrohungsinformationen einen Bericht, der detailliert beschreibt, wie die finanziell motivierte Bedrohungsakteur Storm-0501 von der traditionellen Endpunktverschlüsselung zu Cloud-basierten Ransomware-Operationen übergegangen ist, die auf Hybridumgebungen abzielen, welche lokale Active Directory-, Microsoft Entra ID- und Azure-Ressourcen integrieren. Der Bericht beschreibt eine Kampagne gegen ein großes Unternehmen mit mehreren Tochtergesellschaften, bei der Storm-0501 bereits bestehende Domänenadministratorrechte nutzte, um von einer fragmentierten lokalen Abdeckung in mehrere Entra ID-Mandanten zu gelangen, globale Administratorrechte zu erlangen und dann ausschließlich native Cloud-Funktionen für Datendiebstahl, -zerstörung und -verschlüsselung zu verwenden, bevor das Opfer erpresst wurde.

Die Aktivitäten vor Ort begannen in einer bereits kompromissbehafteten Active Directory-Domäne, in der nur ein Teil der Umgebung durch Microsoft Defender for Endpoint geschützt war. Storm-0501 listete die Sicherheitsabdeckung mit Befehlen wie sc query sense und sc query windefend auf und nutzte dann Evil-WinRM von einem nicht registrierten Entra Connect Sync-Server aus, um sich lateral zu bewegen und Tunnel zu weiteren Systemen zu bilden. Der Bedrohungsakteur führte DCSync gegen Domänencontroller durch, um Zugangsdaten zu erhalten, und missbrauchte dann mehrere Entra Connect Sync-Server und deren Verzeichnissynchronisierungskonten, um mithilfe von AzureHound Identitäten und Ressourcen über mehr als einen Entra ID-Mandanten hinweg aufzulisten. Sie stießen auf blockierte Anmeldeversuche, als bedingter Zugriff und MFA für privilegierte Konten erzwungen wurden.

Storm-0501 eskalierte Berechtigungen in der Cloud, indem er ein synchronisiertes, nicht-menschliches Konto mit der Rolle des globalen Administrators identifizierte, das keine MFA hatte, dessen lokales Passwort zurücksetzte und sich auf die Passwort-Hash-Synchronisierung verließ, um das neue Passwort an Entra ID weiterzugeben, und anschließend die vom Angreifer kontrollierte MFA registrierte, um den bedingten Zugriff zu erfüllen. Da für den Zugriff auf das Azure-Portal Microsoft Entra-Hybrid-verbundene Geräte erforderlich waren, bewegte sich der Angreifer lateral, bis er sich erfolgreich von einem Hybrid-verbundenen Server aus beim Portal anmelden konnte. Mit globalen Administratorrechten erstellte Storm-0501 mithilfe von AADInternals und einem benutzerdefinierten Zertifikat eine bösartige föderierte Vertrauensstellung zu einem vom Angreifer kontrollierten Mandanten, wodurch die Fälschung von Security Assertion Markup Language (SAML)-Tokens ermöglicht wurde. Dies ermöglichte es dem Angreifer, sich anhand der ImmutableId als beliebige Benutzer auszugeben und deren Rollen zu übernehmen, wodurch eine dauerhafte, identitätsunabhängige Persistenz im Mandanten des Opfers hergestellt wurde.

Von diesem Entra-ID-Einstiegspunkt aus erweiterte Storm-0501 den Zugriff in Azure, indem er Microsoft.Authorization/elevateAccess/action aufrief, um Benutzerzugriffsadministrator zu werden und sich dann selbst Besitzer für alle Abonnements zuzuweisen, wodurch er die vollständige Kontrolle über Azure Storage, virtuelle Maschinen und Backup-Infrastruktur erlangte. Der Angreifer entdeckte Speicherkonten, Snapshots, Wiederherstellungspunktsammlungen und Konfigurationen des Recovery Services Vault; legte interne Speicherkonten dem Internet offen; erlangte Speicherzugriffsschlüssel; und exfiltrierte Daten in großem Umfang mithilfe von AzCopy in vom Angreifer kontrollierte Cloud-Speicher. Anschließend wurden VM-Snapshots, Wiederherstellungspunktsammlungen, Speicherkonten und Sicherungscontainer gelöscht, wobei gegebenenfalls Ressourcensperren und Unveränderlichkeitsrichtlinien entfernt wurden. Für die verbleibenden Speicherkonten konfigurierten sie die Verschlüsselungsbereiche so, dass ein vom Angreifer kontrollierter Azure Key Vault-Schlüssel verwendet wurde, bevor dieser Schlüssel gelöscht wurde. Dies führte zu einer cloudbasierten Verschlüsselung für Impact. Nach der Datenexfiltration und den destruktiven Aktionen nutzte Storm-0501 die Identitäten von Kompromiss, um über Microsoft Teams Kontakt zum Opfer aufzunehmen und Lösegeldforderungen zu übermitteln.

Missbrauch von Zugangsdaten, Kontoübernahme und unbefugter Zugriff

Abbildung 8: Radardiagramm zur Veranschaulichung des unbefugten Zugriffs als Bedrohungsvektoren (Quellen: Recorded Future)

Kosten der Auswirkungen: 4 (hoch)

Diese Bedrohung besteht darin, dass Bedrohungsakteur privilegierten Zugriff auf Cloud-Umgebungen erlangen. Auch wenn dieser privilegierte Zugriff nicht zwangsläufig bedeutet, dass Bedrohungsakteur in einer Cloud-Umgebung böswillige Aktionen ausführen können, sind die Möglichkeiten, die Bedrohungsakteur dieser Zugriff bietet, potenziell äußerst schädlich.

Häufigkeit: 5 (Schwerwiegend)

Nahezu alle in diesem Bericht beschriebenen Ereignisse beinhalten den Missbrauch gültiger Anmeldedaten an irgendeiner Stelle ihrer Angriffskette. Aufgrund des Wertes gültiger Cloud-Authentifizierungsmaterialien und ihrer Notwendigkeit, den eingeschränkten Zugriff in Cloud-Umgebungen zu gewährleisten, werden diese Materialien wahrscheinlich bei den meisten Angriffen auf Cloud-Umgebungen beobachtet werden.

Evolutionspotenzial: 1 (Minimal)

Die Methoden, die einen unberechtigten Zugriff ermöglichen, sind starr. Um diese Methoden anzuwenden, muss Bedrohungsakteur Authentifizierungsmaterialien ausschließlich in der dafür vorgesehenen Weise missbrauchen; daher besteht für Bedrohungsakteur nur ein geringes Potenzial, diese Angriffsmethoden zu erneuern.

Aufwand für die Durchführung: 1 (Minimal)

Aus demselben Grund, aus dem sich die Komplexität dieser Bedrohung wahrscheinlich nie weiterentwickeln wird, wird auch der Aufwand für die Durchführung entsprechender Angriffe entsprechend gering bleiben. Bedrohungsakteur haben Zugriff auf eine Vielzahl von Lösungen zum Sammeln gültiger Anmeldedaten, die dann direkt zur Authentifizierung in und innerhalb von Cloud-Umgebungen verwendet werden können.

Zusammenfassung der Bedrohung

Bedrohungsakteur müssen Zugang zu einem Umfeld erlangen können, bevor sie ihre übergeordneten Ziele verfolgen oder erreichen können. Wie die in diesem Abschnitt besprochenen Ereignisse zeigen, beschaffen sich Bedrohungsakteur häufig legitime Anmeldedaten und missbrauchen diese, um sich diesen Zugang zu verschaffen.

Eine der häufigsten Methoden, mit denen Bedrohungsakteur unbefugten Zugriff erlangen, ist der Missbrauch gültiger Anmeldedaten die mit einer vertrauenswürdigen Einheit innerhalb der Cloud-Umgebung verknüpft sind. Diese gültigen Anmeldedaten gewähren implizite Berechtigungen oder ermöglichen den Zugriff innerhalb der Umgebung des Opfers durch Kontoübernahme. Es gibt mehrere Möglichkeiten, wie Bedrohungsakteur gültige Anmeldedaten erlangen können: Password Spray und Stuffing-Angriffe, Phishing und Gegner-in-the-Middle (AitM)- oder Man-in-the-Browser (MitB)-Angriffe sowie der Kauf gültiger Anmeldedaten von einem Initial Access Broker (IAB), neben anderen Methoden.

Der Begriff „gültige Anmeldedaten“ wird oft synonym mit Benutzernamen und Passwort verwendet; Bedrohungsakteur haben jedoch gezeigt, dass auch andere Formen von Authentifizierungsmaterial verwendet werden können, um Zugang zu oder innerhalb von Cloud-Umgebungen zu erlangen. Von Cloud-Umgebungen generierte und gespeicherte geheime Schlüssel und Token können auch zur Authentifizierung bei bestimmten Cloud-Diensten verwendet werden, wodurch Bedrohungsakteur Daten aus der Umgebung sammeln oder anderweitig nicht autorisierte Aktionen durchführen kann, während er sich als legitime Einheit ausgibt. Darüber hinaus reichen Benutzername und Passwortkombinationen oft nicht aus für eine Cloud-Umgebung, und Bedrohungsakteur muss MFA-Codes abfangen, um Zugriff zu erhalten.

Gültige Anmeldedaten werden auch von Bedrohungsakteur sehr geschätzt, da sie häufig die Kontoübernahme erleichtern. Sobald ein Bedrohungsakteur Zugriff auf ein gültiges Konto erlangt hat, das von der Cloud-Umgebung eines Opfers als vertrauenswürdig eingestuft wird, kann er sich als dieses Konto ausgeben, sodass seine Aktionen innerhalb der Umgebung legitim erscheinen. Oftmals besteht für die Verteidiger die einzige Möglichkeit, eine Kompromittierung eines Kontos zu erkennen, in Verhaltensindikatoren, die die Verteidiger möglicherweise nicht sofort auf das aktive Risiko in ihrer Umgebung aufmerksam machen, sei es am Rand einer Cloud-Umgebung oder intern.

Ausblick

Bedrohungsakteur wird auch in absehbarer Zukunft weiterhin gestohlene gültige Anmeldedaten einsetzen, um sich Zugang zu Cloud-Umgebungen zu verschaffen. Darüber hinaus wird Bedrohungsakteur weiterhin Kampagne zur Sammlung gültiger Anmeldedaten durchführen, die bei zukünftigen Angriffen auf Cloud-Umgebungen verwendet werden können. Wie bereits erwähnt, werden gültige Accounts von Bedrohungsakteur sehr geschätzt, da sie den Zugang zu Cloud-Umgebungen ermöglichen und zudem die Fähigkeit besitzen, bösartige Aktivitäten zu verschleiern und als harmlose Ereignisse darzustellen.

Minderungsmaßnahmen und Erkennung

Abbildung 9 veranschaulicht eine hypothetische Angriffskette, die auch unberechtigten Zugriff beinhaltet. In dieser Visualisierung hat die Insikt Group jene Abschnitte der Angriffskette identifiziert, in denen Verteidiger am effizientesten nach Verhaltensweisen suchen und diese abmildern können, die mit Cloud-Missbrauch in Verbindung stehen.

Abbildung 9: Visuelle Darstellung potenzieller Angriffsvektoren für unautorisierten Zugriff (Quellen: Recorded Future)

① Erkennung unautorisierter Zugriffe am Netzwerkrand

Bedrohungsakteur wird mehrere Methoden einsetzen, um sich unbefugten Zugriff auf eine Cloud-Umgebung zu verschaffen. Daher ist die Fähigkeit, diese Bedrohungen am Rande einer Cloud-Umgebung zu erkennen und abzuwehren, von entscheidender Bedeutung für die Sicherheit der Umgebung. Im Folgenden werden einige Methoden zur Erkennung unautorisierter Erstzugriffe auf eine Cloud-Umgebung beschrieben:

Darüber hinaus können diese Bedrohungen auf folgende Weise gemildert werden:

② Unbefugter Zugriff auf Cloud-Dienste und Ressourcen

Wenn ein Bedrohungsakteur mithilfe von kompromittierten gültigen Anmeldedaten Zugang zu einer Cloud-Umgebung erlangt, erbt er die Berechtigungen, die dem mit diesen Anmeldedaten verknüpften Konto gewährt wurden. Bedrohungsakteur wird versuchen, mit diesen Berechtigungen nach dem Zugriff auf eine Cloud-Umgebung Folgeaktionen durchzuführen, einschließlich der Ermittlung des Umfangs seiner bestehenden Berechtigungen. Einige Methoden für Jagd- und Abmilderungsmaßnahmen, Bedrohungsakteur in dieser Phase ergreifen können, werden im Folgenden erläutert:

③ Zugriff auf verknüpfte Cloud-Ressourcen

Diese Bedrohung steht in engem Zusammenhang mit der oben beschriebenen Bedrohung durch unautorisierten Zugriff, und die Gegenmaßnahmen sind ähnlich. Nach dem Zugriff auf eine Cloud-Umgebung versucht Bedrohungsakteur häufig, sich darin auszubreiten und Zugriff auf möglichst viele Ressourcen und Artefakte zu erlangen. Wichtig ist, dass Bedrohungsakteur auch versuchen kann, auf Teile der Infrastruktur der Cloud-Umgebung zuzugreifen, die in anderen Rechenzentren oder in völlig anderen Cloud-Umgebungen gehostet werden, die sich im Besitz derselben Einheit befinden und von dieser verwaltet werden.

Wie bereits erwähnt, eignen sich die zuvor in diesem Abschnitt besprochenen Abschwächungsmaßnahmen und Jagdstrategien auch zur Identifizierung dieses Verhaltens. Insbesondere ist sicherzustellen, dass das Prinzip der minimalen Berechtigungen eingehalten wird und dass Cloud-Zugriffsprotokolle in allen Cloud-Umgebungen, die einer einzigen einheitlichen Einheit gehören und von dieser verwaltet werden, aufbewahrt werden.

Beispiele aus der Praxis

Die Insikt Group hat eine Liste von Ereignissen zusammengestellt, die im vergangenen Jahr veröffentlicht wurden und die die Bedrohungen durch unberechtigten Zugriff, Missbrauch gültiger Zugangsdaten und Kontoübernahmen aufzeigen. Diese Ereignisse werden im Folgenden erläutert.

Silk Typhoon: Kampagne zum Erstzugriff und Missbrauch von Zugangsdaten in der IT-Lieferkette

Am 5. März 2025 veröffentlichte Microsoft Bedrohungsinformationen eine Studie über Silk Typhoon, eine chinesische staatliche Bedrohungsakteur, in der detailliert beschrieben wird, wie die Gruppe IT-Dienstleister, Plattformen für Identitäts- und Privileged-Access-Management sowie andere Infrastrukturen der Lieferkette ins Visier nimmt, um sich ersten Zugriff zu verschaffen und dann systematisch gestohlene Anmeldedaten, Schlüssel und Cloud-Identitäten zu missbrauchen, um Spionage gegen nachgelagerte Kunden zu betreiben. Nachdem Kompromiss-Edge-Geräte oder Drittanbieter ausgenutzt wurden, geht Silk Typhoon einen anderen Weg: Anstatt sich ausschließlich auf maßgeschneiderte Malware zu verlassen, verwendet Silk Typhoon gültige, aber gestohlene Authentifizierungsmaterialien, um in Kundenumgebungen einzudringen und auf Daten zuzugreifen, die mit strategischen Interessen in China, der Politik der US-Regierung sowie sensiblen Rechts- und Strafverfolgungsinformationen übereinstimmen.

Die erste Zugriffsphase von Silk Typhoon kombiniert die Ausnutzung von Sicherheitslücke im Internet mit dem direkten Missbrauch von Zugangsdaten. Die Gruppe setzt Zero-Day-Exploits gegen gängige Edge-Geräte schnell in die Praxis um, darunter CVE-2025-0282 in Ivanti Pulse Connect VPN, CVE-2024-3400 in Palo Alto Networks GlobalProtect Gateway, CVE-2023-3519 in Citrix NetScaler ADC/Gateway und die Microsoft Exchange „ProxyLogon“-Kette (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065), um Systemzugriff auf öffentlich zugängliche Dienste zu erlangen. Parallel dazu führt Silk Typhoon Password-Spray-Angriffe und andere TTPs zum Missbrauch von Passwörtern durch, indem es durchgesickerte Unternehmenspasswörter aus öffentlichen Repositories wie GitHub sammelt und diese verwendet, um sich direkt bei Unternehmenskonten zu authentifizieren. Diese Angriffe zielen in erster Linie auf IT-Anbieter, Identitätsmanagement, Privileged Access Management sowie Fernüberwachungs- und -verwaltungslösungen ab, wobei ein erfolgreicher Kompromittierungsversuch zu wertvollen Anmeldedaten und Vertrauensbeziehungen führt, die von mehreren Kunden genutzt werden können.

Sobald erste Fuß gefasst sind, geht Silk Typhoon dazu über, systematisch Authentifizierungsmaterialien zu stehlen und wiederzuverwenden, um den Zugang zu vertiefen und nachgelagerte Nutzer zu erreichen. Seit Ende 2024 ist der Bedrohungsakteur bei Lieferkette-Einbrüchen aktiv. Er hat API-Schlüssel und Anmeldedaten von Anbietern von Privileged Access Management, Cloud-Anwendungsanbietern und Cloud-Datenmanagement-Unternehmen gestohlen und diese Schlüssel anschließend verwendet, um sich als Administrator bei nachgelagerten Kundenmandanten zu authentifizieren, Aufklärung zu betreiben, Daten zu sammeln, Standard-Administratorkonten zurückzusetzen, Web-Shells bereitzustellen, zusätzliche Benutzer zu erstellen und Protokolle zu löschen, um die Aktivitäten zu verbergen.

Innerhalb der Opferumgebungen extrahiert Silk Typhoon Active Directory-Daten, stiehlt Passwörter und Geheimnisse aus Schlüsseltresoren und zielt auf AADConnect- und Entra Connect-Server ab, um Berechtigungen zu erlangen, die sich sowohl auf lokale als auch auf Cloud-Identitätsebenen erstrecken. Die Gruppe missbraucht dann legitime Cloud-Identitäten durch Kompromittierung oder die Erstellung von Dienstprinzipalen und OAuth-Anwendungen mit administrativen Berechtigungen, das Hinzufügen eigener Anmeldedaten zu bereits genehmigten Anwendungen, Kompromittierung von Mandantenanwendungen und die Entwicklung neuer Entra-ID-Anwendungen, die so benannt werden, dass sie sich in die Umgebung einfügen. Mithilfe dieser vertrauenswürdigen Identitäten greift Silk Typhoon auf Microsoft Graph- und Exchange Web Services-APIs zu, um große Mengen an E-Mail-, OneDrive- und SharePoint-Daten über mehrere Mandanten hinweg zu exfiltrieren.

Scattered Spider: Nutzung gültiger Anmeldedaten bei einem Einbruch in ein Logistikunternehmen

Am 27. Juni 2025 veröffentlichte die Information Security Media Group einen Teardown von ReliaQuest-Quellen, in dem beschrieben wird, wie Scattered Spider (auch bekannt als Octo-Tempest/UNC3944) ein Logistikunternehmen kompromittiert hat, indem er den CFO ins Visier nahm, gültige Anmeldedaten missbrauchte und MFA sowie privilegierte Passwort-Tresore manipulierte, um Zugriff zu erlangen und erneut zu versuchen.

Die Angreifer begannen damit, Führungskräfte der obersten Ebene ins Visier zu nehmen und öffentlich zugängliche Identitätsdaten des Finanzvorstands zu sammeln, darunter dessen Geburtsdatum und die letzten vier Ziffern seiner Sozialversicherungsnummer. Sie nutzten diese Informationen, um über das öffentlich zugängliche Oracle Cloud-Portal des Unternehmens die Mitarbeiternummer des Finanzvorstands zu bestätigen und versuchten, sich mit gestohlenen Anmeldedaten des Finanzvorstands zu authentifizieren; diese ersten Anmeldeversuche scheiterten jedoch an der erzwungenen Multi-Faktor-Authentifizierung.

Anschließend gab sich Scattered Spider in einem Telefonat mit dem IT-Helpdesk als Finanzvorstand aus und präsentierte ein plausibles Szenario, das die zuvor gesammelten Identitätsdaten nutzte. Die Helpdesk-Mitarbeiter wurden dazu gebracht, sowohl das MFA-Gerät als auch die mit dem Konto des Finanzvorstands verknüpften Anmeldedaten zurückzusetzen. Dadurch wurde die Kontrolle über eine legitime Führungspersonenidentität effektiv an die Angreifer übertragen, und MFA wurde zu einem Werkzeug statt zu einer Barriere. Unter Verwendung des nun als „Kompromiss CFO“ bezeichneten Kontos verschafften sich die Angreifer über Single Sign-On und VMware Horizon Virtual Desktops Zugang zur Umgebung. Anschließend nutzten sie gültige Anmeldedaten , um Identitäten in Microsoft Entra ID aufzulisten, einem Kompromiss-Konto eine Exchange-Administratorrolle zuzuweisen und auf wichtige Dienste zuzugreifen, darunter den CyberArk Privileged Access Vault und das Snowflake Data Warehouse des Unternehmens.

Innerhalb des CyberArk-Tresors nutzte der Bedrohungsakteur gesicherte Geheimnisse, die mit etwa 1.400 Konten verknüpft waren, um sich mit legitimen Anmeldedaten in der Umgebung zu bewegen, schließlich die NTDS.DIT Active Directory-Datenbank zu extrahieren und auf Postfächer des CISO und anderer leitender Angestellter zuzugreifen. Selbst nachdem die Verteidiger den Bedrohungsakteur etwa 62 Stunden nach dem ersten vollständig entfernt hatten, versuchte Scattered Spider weiterhin, den Zugriff wiederzuerlangen, indem er sich mit Passwörtern anmeldete, die aus den zuvor gestohlenen Hashes privilegierter Konten geknackt worden waren; diese späteren Versuche verwendeten gültige (aber jetzt geschützte) Anmeldedaten und lösten MFA-Aufforderungen aus, die einen erneuten Zugriff verhinderten, aber wiederholte Zugriffsversuche auf Basis von Zugangsdaten demonstrierten.

Missbrauch der Authentifizierung durch Nordkorea beim ByBit-Raubüberfall

Am 5. Mai 2025 veröffentlichte Elastic Security Labs einen Bericht, in dem detailliert beschrieben wird, wie Betreiber von TraderTraitor mit Verbindungen zu Nordkorea durch Missbrauch der AWS-Authentifizierung von Safe{Wallet} etwa 400.000 ETH von ByBit gestohlen haben. Der Bericht konzentriert sich darauf, wie Angreifer von einer Kompromiss Safe{Wallet} macOS-Entwickler-Workstation zu einem authentifizierten Zugriff auf das AWS-Konto von Safe{Wallet} gelangten und diese Cloud-Identität dann nutzten, um das Safe{Wallet}-Frontend zu manipulieren, dem die ByBit-Genehmiger für die Transaktionsvalidierung vertrauten.

The attack chain began with the compromise of “Developer1” at Safe{Wallet} through a backdoored crypto-themed Python application on macOS that exploited unsafe PyYAML deserialization to run arbitrary code. The malware dropped a Mythic Poseidon agent and a Python stealer that systematically collected authentication materials and configuration details from the host, including Secure Shell (SSH) private keys, AWS access keys, and secret keys from ~/.aws/credentials, environment-based session tokens, and macOS Keychain data.

Using the stolen AWS access key ID, secret key, and the active session token, the DPRK operators authenticated directly into Safe{Wallet}’s AWS account within the token’s twelve-hour validity window. The cached session token, initially created by the victim via AWS mechanisms using GetSessionToken and AWS SSO, stored in standard AWS configuration locations, was replayed from the attacker's infrastructure using the AWS CLI or Boto3, which handles request signing and token use. The attackers operated entirely as the authenticated Safe{Wallet} user, with the MFA context already satisfied at session creation, and issued AWS API calls under that identity, including attempts to register additional MFA devices and to access storage resources.

With valid AWS authentication materials and an active user session, the operators then explored Safe{Wallet}’s cloud environment and accessed the S3 bucket hosting the statically built Safe{Wallet} Next.js frontend. From there, they downloaded, modified, and redeployed the application bundle so that when ByBit approvers loaded the dApp, transaction details displayed in the interface were silently altered while signatures and on-chain workflows still appeared normal.

Drittanbieter-Kompromiss

Abbildung 10: Radardiagramm, das den Kompromiss Dritter als Bedrohungsvektoren darstellt (Quellen: Recorded Future)

Kosten der Auswirkungen: 5 (Schwerwiegend)

Der Missbrauch von Dienstleistungen und die Beeinträchtigung von Produkten Dritter können schwerwiegende Folgen für das Opfer und die Organisation haben, sowohl finanziell als auch reputationsmäßig. Ein Drittanbieter-Kompromitt kann für das Opfer zum Verlust von Infrastruktur und Informationen führen, aber die potenziellen Reputationsschäden für den Drittanbieter können zu Geschäfts- und Vertragsverlusten führen.

Häufigkeit: 2 (Niedrig)

Kompromittierung und Missbrauch durch Dritte weisen im Vergleich zu anderen in diesem Bericht behandelten Bedrohungen eine relativ geringe Häufigkeit auf. Obwohl diese Angriffe nicht die am weitesten verbreitete Art von Angriffen darstellen, die die Insikt Group beobachtet hat, werden sie eingesetzt, wenn Angreifer einen indirekten, vertrauenswürdigen Zugang benötigen, um ein Opfer zu erreichen.

Entwicklungspotenzial: 5 (Schwerwiegend)

Da die Einführung von Cloud-Lösungen immer schneller voranschreitet und Unternehmen auf ein stetig wachsendes Ökosystem von Anbietern für Hosting, Administration, Speicherung und Datenverarbeitung angewiesen sind, wird das Potenzial für Kompromisse mit Drittanbietern weiter zunehmen und sich weiterentwickeln. Jede neue Integration, jeder neue Management-Service oder jede neue Beziehung zu einem gemeinsam genutzten Rechenzentrum erweitert die Angriffsfläche und schafft zusätzliche Vertrauenswege, die Bedrohungsakteur ausnutzen kann. Als Folge davon ist zu erwarten, dass das Risiko durch Dritte im Laufe der Zeit sowohl häufiger ausgenutzt als auch technisch ausgefeilter wird, wobei Angreifer Cyber- und, wo möglich, physische Angriffsmethoden kombinieren, um über die am wenigsten sichere Einheit Zugang zu wertvoller Cloud-Infrastruktur zu erhalten.

Anstrengung bis zur Leistung: 3 (Mittel)

Der Aufwand, der für die Kompromittierung Dritter erforderlich ist, variiert stark je nach Organisation und den Zielen des Angreifers, sodass der Gesamtaufwand im Allgemeinen moderat ist. Gut ausgestattete oder streng regulierte Anbieter mit ausgereiften physischen und Cybersicherheitskontrollen können einen erheblichen Planungsaufwand, Fähigkeiten und Zeitaufwand erfordern. Im Gegensatz dazu können kleinere oder weniger ausgereifte Anbieter, Legacy-Partner oder eine nur schwach überwachte Integration mit vergleichsweise einfachen TTPs und Standardwerkzeugen einen Kompromiss darstellen.

Zusammenfassung der Bedrohung

Bei der Kompromittierung und dem Missbrauch von Drittanbietern in Cloud-Umgebungen handelt es sich um Bedrohungsaktivitäten, die auf externe Anbieter, Plattformen und Komponenten abzielen, auf die sich Organisationen verlassen, und nicht direkt auf die Organisation selbst. Anstatt von Anfang an in die eigenen Konten des Opfers einzubrechen, nutzt Bedrohungsakteur einen verbundenen Identitätsanbieter, eine SaaS-Plattform, einen MSP, einen CI/CD-Dienst oder einen anderen integrierten Anbieter aus und missbraucht dann diese vertrauenswürdige Verbindung, um auf Cloud-Workloads und Daten zuzugreifen. Da diese Beziehungen zu Drittanbietern tief in Authentifizierung, Überwachung, Bereitstellung und Geschäftsprozesse eingebettet sind, verfügen sie oft über weitreichende Berechtigungen und implizites Vertrauen, die für Zugriff, Persistenz und die Verfolgung von Zielen innerhalb der betroffenen Cloud-Umgebungen missbraucht werden können.

Im Kontext des Missbrauchs von Drittparteirisiken (TPR) konzentrieren sich Bedrohungsakteur auf das Vertrauen und die Berechtigungen, die externen Diensten und Anwendungen gewährt werden. Kompromiss-Anbieterportale, Supportkonten oder Verwaltungskonsolen können verwendet werden, um legitim aussehende Anmeldesitzungen, API-Aufrufe und Konfigurationsänderungen in den Cloud-Mandanten des Kunden durchzuführen. OAuth-Anwendungen, Marktplatzintegrationen und mit Drittanbietern verknüpfte Dienstkonten können übermäßig privilegiert oder mandantenweit eingesetzt sein, wodurch ein Angreifer, der die Kontrolle über den Drittanbieter hat, gleichzeitig Zugriff auf mehrere Kunden erlangen kann. Von dort aus kann der Bedrohungsakteur Ressourcen auflisten, Identitäten und Richtlinien manipulieren oder weitere Tools einsetzen, während er als standardmäßige, vertrauenswürdige Integration erscheint.

Der Kompromiss in der Lieferkette in Cloud-Umgebungen erweitert dieses Modell auf die Software- und Build-Pipelines, die Code für Cloud-basierte Systeme produzieren und bereitstellen. Bedrohungsakteur kann Quellcode-Repositories, CI/CD-Plattformen, Artefakt-Registries oder Aktualisierungsmechanismen angreifen, die von Cloud-nativen Anwendungen und Diensten verwendet werden. Durch Manipulation von Build-Konfigurationen oder Einschleusen bösartiger Logik in Abhängigkeiten, Images oder Update-Kanäle können sie sicherstellen, dass Kompromiss-Komponenten automatisch erstellt, signiert und in Produktions-Workloads bereitgestellt werden. Dadurch erhalten sie einen verdeckten und skalierbaren Zugang, der die Berechtigungen und die Reichweite der betroffenen Dienste und Anwendungen über Cloud-Konten und Regionen hinweg erbt.

Der Missbrauch von Paketen konzentriert sich insbesondere auf öffentliche oder interne Paketökosysteme, die in Cloud-Anwendungen und Automatisierung einfließen. Bedrohungsakteur veröffentlichen oder modifizieren Bibliotheken, Container oder Infrastructure-as-Code-Module auf eine Weise, die dazu führt, dass diese durch normale Entwicklungs- und Bereitstellungsprozesse in die Zielumgebungen der Angreifer gelangen. TTPs wie Typosquatting, Abhängigkeitsverwirrung oder das Hijacking verlassener Pakete ermöglichen es bösartigem Code, in Build-Pipelines und Laufzeitumgebungen einzudringen, ohne direkt in die Zielorganisation einzudringen. Sobald diese Pakete in Cloud-Workloads ausgeführt werden, können sie auf Anmeldedaten zugreifen, Cloud-APIs aufrufen, Daten exfiltrieren oder zusätzliche Nutzdaten unter dem Deckmantel des Standard-Anwendungsverhaltens bereitstellen, wodurch Drittanbieter-Kompromisse, Lieferketten-Kompromisse und Paketmissbrauch eng miteinander verknüpfte Risiken für cloudzentrierte Organisationen darstellen.

Ausblick

Bedrohungsakteur wird auch weiterhin der Kompromittierung und dem Missbrauch durch Dritte Priorität einräumen, da dies ein effizientes Mittel ist, um über einen einzigen, vertrauenswürdigen Kanal mehrere Cloud-Umgebungen zu erreichen. Missbrauch von TPR, Lieferkettenkompromittieren und Paketmissbrauch ermöglichen es Bedrohungsakteur , die Privilegien, Reichweite und das implizite Vertrauen zu erben, die Anbietern, Plattformen und Komponenten gewährt werden, die tief in Cloud-Identität, -Bereitstellung und -Betrieb verwoben sind. Da Unternehmen zunehmend auf SaaS, MSPs, CI/CD-Plattformen und externe Integrationen angewiesen sind, wächst auch das potenzielle Risiko eines einzelnen Kompromisses in der vorgelagerten Wertschöpfungskette.

Da diese Angriffe auf legitimer Integration, signierten Artefakten und erwarteter Paketnutzung basieren, bleiben sie schwer von regulären Aktivitäten in Cloud-Umgebungen zu unterscheiden. Die Kombination aus breitem Zugriff, automatischer Weitergabe über Pipelines und der Möglichkeit, sich als vertrauenswürdiger Dritter auszugeben, stellt sicher, dass TPR-Missbrauch, Lieferkettenkompromittierung und Paketmissbrauch weiterhin wertvolle Strategien für Bedrohungsakteur bleiben, die einen skalierbaren, reibungslosen Zugriff auf Cloud-Workloads und -Daten anstreben.

Minderungsmaßnahmen und Erkennung

Abbildung 11 veranschaulicht eine hypothetische Angriffskette im Zusammenhang mit Angriffsmethoden und Verhaltensweisen von Drittanbietern. In dieser Visualisierung hat die Insikt Group jene Teile der Angriffskette identifiziert, in denen Verteidiger am effizientesten nach Verhaltensweisen suchen und diese abmildern können, die mit Cloud-Missbrauch in Zusammenhang stehen.

Abbildung 11: Visuelle Darstellung potenzieller Drittparteirisiken und Erkennung (Quelle: Recorded Future)

① Vertrauensbeziehungen zu Drittanbietern von SaaS-Lösungen, Identitätsanbietern (IdP) und Managed Service Providern (MSP)

Bedrohungsakteur zielt auf Drittanbieter von SaaS-Lösungen, Identitätsanbietern und Managed-Service-Anbietern (wie SSO-Plattformen, Fernüberwachungstools oder IT-Service-Management-Systeme) ab, um indirekten Zugriff auf Cloud-Kunden zu erlangen. Der Nachteil dieser Anbieter besteht darin, dass Angreifer über vertrauenswürdige Kanäle authentifizierte Sitzungen einrichten, Konfigurationen manipulieren oder Änderungen in Kundenumgebungen vornehmen können.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

  1. Führen Sie strenge Onboarding- und Risikobewertungsverfahren für Drittanbieter ein, einschließlich Anforderungen an MFA, Protokollierung, Benachrichtigungs-Service-Level-Agreements (SLAs) und eine klare Abgrenzung ihres Zugriffs auf Ihre Cloud-Mandanten.
  2. Alle SSO-, Federation- und API-basierten Vertrauensbeziehungen (wie SAML, OpenID Connect [OIDC] und herstellerspezifische Integrationen) sollten überwacht und regelmäßig überprüft werden. Dabei ist besonderes Augenmerk auf neu hinzugefügte Verbindungen, neu gewährte Bereiche oder erweiterte Berechtigungen im Laufe der Zeit zu legen.
  3. Korrelieren Sie vom Anbieter ausgehende Aktivitäten (wie Support-Logins, Remote-Sitzungen oder automatisierte Behebungsaktionen) in Cloud- und IdP-Protokollen und geben Sie eine Warnung aus, wenn Aktivitäten außerhalb vereinbarter Wartungsfenster, Standorte oder erwarteter Muster auftreten.

② Drittanbieterintegration innerhalb des Cloud-Tenants

Bedrohungsakteur wird übermäßig privilegierte Drittanbieterintegrationen, wie z. B. OAuth-Anwendungen, Marketplace-Add-ons, Dienstprinzipale und API-Schlüssel, missbrauchen, um Operationen direkt in Cloud-Umgebungen durchzuführen. Sobald diese Integrationen vorgelagert beeinträchtigt sind, können Angreifer in mehrere Mandanten vordringen und unter dem Deckmantel legitimer Anwendungen Aufklärungs-, Datenzugriffs- oder Konfigurationsänderungen durchführen.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

  1. Implementieren Sie einen formalen Genehmigungsprozess für Cloud-Anwendungen und Dienstprinzipale von Drittanbietern, der eine Begründung, eine Überprüfung des Geltungsbereichs und eine Sicherheitsvalidierung erfordert, bevor mandantenweite oder hochprivilegierte Berechtigungen erteilt werden.
  2. Überwachen Sie kontinuierlich neue App-Zustimmungen, erweiterte Berechtigungsbereiche oder eine ungewöhnliche Nutzung bestehender Dienstprinzipale und geben Sie eine Warnung aus, wenn eine Integration auf Ressourcen zugreift oder Aktionen außerhalb ihres dokumentierten Zwecks durchführt.
  3. Setzen Sie das Prinzip der minimalen Berechtigungen für alle Drittanbieterintegrationen durch, indem Sie diese auf bestimmte Rollen, Ressourcengruppen und APIs beschränken und den Zugriff regelmäßig neu zertifizieren, um sicherzustellen, dass ungenutzte oder unnötige Berechtigungen entfernt werden.

③ CI/CD-Pipelines, Artefaktregister und Paketmissbrauch

Bedrohungsakteur nutzt die Software-Lieferkette aus, indem er CI/CD-Pipelines, interne Artefaktregister oder Paketfeeds sowie öffentliche Paketökosysteme manipuliert. Durch das Einschleusen bösartiger Abhängigkeiten, Images oder Build-Schritte können sie sicherstellen, dass Kompromiss-Komponenten automatisch erstellt, signiert und im Rahmen routinemäßiger Entwicklungs- und Release-Prozesse in Cloud-Workloads bereitgestellt werden.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

  1. Härten Sie CI/CD-Plattformen ab, indem Sie MFA für Pipeline-Administratoren erzwingen, den Zugriff auf Build-Konfigurationen einschränken und Audit-Logs für alle Pipeline- und Zugangsdatenänderungen führen.
  2. Verlangen Sie Herkunftsnachweis und Signatur für Artefakte (wie Container-Images, Binärdateien und Infrastructure-as-Code-Vorlagen) und erzwingen Sie, dass in Produktionsumgebungen nur Artefakte ausgeführt werden, die die Signatur- und Integritätsprüfung bestehen.
  3. Beschränken Sie die Nutzung öffentlicher Paketquellen auf geprüfte Quellen, führen Sie Abhängigkeits- und Softwarekompositionsanalysen durch und warnen Sie vor der Einführung neuer, nicht geprüfter Abhängigkeiten, insbesondere wenn diese bestehenden internen oder populären Paketen ähneln (z. B. Typosquatting oder Abhängigkeitsverwirrungsmuster).

④ Workloads und Datenebene: Ausführen von Drittanbieterkomponenten

Bedrohungsakteur wird auf Drittanbietercode von Kompromiss zurückgreifen, der in Cloud-Workloads, Anwendungen, Containern, serverlosen Funktionen und Hintergrundprozessen ausgeführt wird, um seine Ziele zu erreichen. Nach ihrer Bereitstellung können diese Komponenten unbemerkt Daten exfiltrieren, Workload-Identitäten missbrauchen, um Cloud-APIs aufzurufen, Ransomware einschleusen oder verdeckte Kanäle erstellen, die sich in das normale Anwendungsverhalten einfügen.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

  1. Implementieren Sie Laufzeitsicherheit sowie EDR- und Cloud Workload Schutz Platform (CWPP)-Funktionen auf Workloads, um anomales Verhalten von Anwendungsprozessen zu erkennen, wie z. B. unerwartete ausgehende Verbindungen, abnormale API-Aufrufe oder den Zugriff auf sensible Geheimnisse und Datenspeicher.
  2. Wenden Sie das Prinzip der minimalen Berechtigungen auf Workload-Identitäten und Geheimnisse an, um sicherzustellen, dass selbst wenn eine Drittanbieterkomponente Kompromiss ist, sie nur mit einem minimalen Satz von Ressourcen interagieren kann und nicht direkt Schlüssel, Backups oder umfassendere Mandantenkonfigurationen verwalten kann.
  3. Erzwingen Sie Netzwerksegmentierung und Ausgangskontrollen für Workloads, indem Sie die ausgehende Konnektivität auf genehmigte Ziele (wie bekannte APIs, Registries und Partner-Endpunkte) beschränken und bei Verbindungen von Produktions-Workloads zu unbekannten IPs oder Domains eine Warnung ausgeben.

⑤ Sicherheits- und Überwachungsebene: Telemetrie und Überwachung durch Anbieter

Bedrohungsakteur wird versuchen, die Sicherheits- und Überwachungsebene auszunutzen oder zu beeinträchtigen, einschließlich der Integration mit Sicherheitstools und Überwachungsdiensten von Drittanbietern. Durch Manipulation der Protokollweiterleitung, Deaktivierung von Agenten oder Missbrauch des gemeinsamen Vertrauensverhältnisses mit Sicherheitsanbietern können Angreifer die Sichtbarkeit ihrer Aktivitäten verringern oder irreführende Signale erzeugen.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

  1. Zentralisieren Sie die Protokollerfassung von Cloud-Diensten, IdPs, Anbietern und der lokalen Infrastruktur in gehärteten, kontrollierten Protokollierungsumgebungen und überprüfen Sie, ob die vom Anbieter bereitgestellten Protokolle vollständig, zeitnah und mit der internen Telemetrie korreliert sind.
  2. Überwachen Sie Änderungen an Protokollierungskonfigurationen, der Integration von Sicherheitstools und der Bereitstellung von Agenten und generieren Sie eine Warnung mit hohem Schweregrad, wenn kritische Datenquellen deaktiviert, herabgestuft oder plötzlich nicht mehr verfügbar sind, ohne dass eine genehmigte Änderung vorliegt.
  3. Überprüfen Sie, ob Erkennungs- und Benachrichtigungen von Managed Security Providern wie erwartet zugestellt und bearbeitet werden, und simulieren Sie regelmäßig vom Anbieter stammende Testfälle, um zu bestätigen, dass die Integrations- und Antwort-Workflows ordnungsgemäß funktionieren.

⑥ Physische Rechenzentren, Colocation und On-Premise-Pivots

Bedrohungsakteur kann physische Sicherheitslücken in Rechenzentren, Colocation-Einrichtungen oder On-Premises-Umgebungen ausnutzen, die über Direct Connect, VPN oder Multiprotocol Label Switching (MPLS) mit der Cloud verbunden sind. Durch den Missbrauch von Vertragstechnikern, gestohlenen Ausweisen, ungesicherten Netzwerkschränken oder schlecht kontrolliertem Smart-Hands-Zugriff können sie lokale Switches, Querverbindungen oder Managementkonsolen manipulieren und so einen Übergang in Cloud-Umgebungen ermöglichen oder die Konnektivität unterbrechen.

Verteidiger können diese Bedrohungen auf folgende Weise abmildern:

  1. Strenge physische Zugangskontrollen an On-Premise- und Colocation-Standorten sind erforderlich, darunter Zugangskontrollen mit Ausweis und biometrischen Daten, Besucherregistrierung, Begleitrichtlinien für externe Techniker und strikte Trennung von Kunden-Cages oder Racks.
  2. Die Netzwerk- und Recheninfrastruktur in Rechenzentren lässt sich durch das Verriegeln von Racks, das Sichern von Konsolenports, das Aktivieren der Port-Sicherheit und der Netzwerkzugriffskontrolle an Switches sowie durch die Überwachung auf unautorisierte Geräte oder Verbindungsänderungen an Uplinks und Cross-Connects absichern.
  3. Von Cloud- und Rechenzentrumsanbietern ist zu verlangen, dass sie festgelegte physische Sicherheitsstandards und Audit-Anforderungen erfüllen und dass die Verbindungswege zwischen On-Premise-Systemen und der Cloud (wie z. B. Direktverbindungen, VPN-Gateways und SD-WAN-Appliances) auf Konfigurationsänderungen, Verbindungsunterbrechungen oder unerwartetes Routing-Verhalten überwacht werden, das auf Manipulationen hindeuten könnte.

Beispiele aus der Praxis

Insikt Group hat eine Liste von Veranstaltungen zusammengestellt, die im Laufe des Jahres 2025 veröffentlicht wurden und die die von Drittanbieter-Kompromissen ausgehenden Bedrohungen aufzeigen. Diese Ereignisse werden im Folgenden erläutert.

Kampagnegegen Datendiebstahl durch Drittanbieter im Zusammenhang mit Zero-Day-Angriffen auf Oracle E-Business Suite

Am 28. Oktober 2025 beschrieb SecurityWeek (Eduard Kovacs) eine Kampagne bei der die Ransomware Cl0p Bedrohungsakteur, die von der Sicherheitsgemeinschaft mit einem unbekannten Cluster der profitorientierten Bedrohungsgruppe FIN11 in Verbindung gebracht wird, eine Zero-Day- Sicherheitslücke in der Oracle E-Business Suite (EBS) ausnutzte, um Daten von Oracle-Kunden zu stehlen, darunter Schneider Electric, Emerson, Logitech, GlobalLogic und das Dartmouth College. Diese Quellen schildern gemeinsam ein Drittparteienrisikoszenario, in dem sich der Kompromiss einer gemeinsam genutzten Oracle EBS-Plattform auf der Anbieterebene auf branchenübergreifende Daten auswirkt wobei betroffene Organisationen betonen, dass die von Oracle gehostete oder andere Drittsysteme und nicht ihre Kern-IT- oder Produktionsumgebungen betraf.

Die Angriffskette begann mit der Ausnutzung mindestens einer Zero-Day- Sicherheitslücke in Oracle EBS, die unter CVE-2025-61882 geführt wird, gegen Oracle EBS-Instanzen ab Anfang August 2025 und ermöglichte den unberechtigten Zugriff auf EBS-Plattformen, die von mehreren Organisationen genutzt werden. Laut BleepingComputer ereigneten sich die Bedrohungsakteur Aktivitäten von GlobalLogic in der Oracle-Umgebung zwischen dem 10. Juli und dem 20. August 2025. Der Zugriff auf Oracle und die Datenexfiltration wurden am 9. Oktober 2025 bestätigt, woraufhin mehr als 10.000 aktuelle und ehemalige Mitarbeiter benachrichtigt wurden, deren Informationen in der EBS-Bereitstellung gespeichert waren. In der Mitteilung von GlobalLogic heißt es, dass der Vorfall keine Systeme außerhalb der Oracle-Plattform betraf und dass die betroffenen Daten auf in Oracle gespeicherte HR-Informationen beschränkt waren. SecurityWeek merkt an, dass auf der Leak-Website von Cl0p bisher über 50 Opfer identifiziert wurden und dass die Gruppe gestohlene Informationen in großen Archivsätzen und Torrents veröffentlicht, was auf eine systematische Datenexfiltration aus Oracle-Umgebungen über mehrere Organisationen hinweg hindeutet.

GlobalLogic berichtet , dass Angreifer eine Zero-Day- Sicherheitslücke in Oracle EBS ausnutzten, um persönliche Daten von 10.471 Mitarbeitern zu stehlen, darunter von der Personalabteilung erfasste Daten wie Namen, Adressen, Telefonnummern, E-Mail-Adressen, Geburtsdaten, Passinformationen, nationale oder Steueridentifikationsnummern (einschließlich Sozialversicherungsnummern) und Bankkontodaten. Das Dartmouth College hat bekannt gegeben , dass ein unbefugter Bedrohungsakteur zwischen dem 9. und 12. August 2025 auf Dateien seiner Oracle EBS-Server zugegriffen hat. Bei einer anschließenden Überprüfung wurden Dateien mit Namen und Sozialversicherungsnummern sowie Dokumente mit Finanzkontoinformationen für mindestens 1.494 Personen gefunden, die bis dato benachrichtigt wurden. In beiden Fällen besteht das Vorgehen des Gegnerdarin, die gemeinsam genutzte Oracle EBS-Plattform auszunutzen, dort gespeicherte sensible Identitäts- und Finanzdaten zu sammeln und anschließend die Cl0p-Leak-Website als Druckmittel in einem Erpressungsmodell zu verwenden, das auf Datendiebstahl und nicht auf die Störung der primären Geschäftssysteme der Opfer abzielt.

Logitech meldet , dass ein unbefugter Dritter eine Zero-Day- Sicherheitslücke in einer Softwareplattform eines Drittanbieters ausgenutzt hat, um begrenzte Daten über Mitarbeiter, Verbraucher, Kunden und Lieferanten aus einem internen IT-System zu extrahieren. Das Unternehmen versichert, dass keine nationalen Identifikationsnummern, Kreditkartendaten, Produkte, Geschäftsabläufe oder Produktionssysteme betroffen waren. SecurityWeek bringt diese Aktivität mit der gleichen Oracle EBS- Kampagne in Verbindung, die von Cl0p behauptet wird. Diese Kampagne listete Logitech auf ihrer Leak-Website auf und veröffentlichte 1,8 TB an angeblichen Logitech-Archiven sowie große Oracle-Quellen-Datensätze für Emerson (2,7 TB), Schneider Electric (116 GB), die Harvard University und Envoy Air. Dies unterstreicht die systematische Offenlegung von Daten durch Dritte in verschiedenen Sektoren.

Bösartiges npm-Paket „@acitons/artifact“ zielt über eine durch Typosquatting verursachte Abhängigkeit auf GitHub Actions ab

Am 10. November 2025 veröffentlichte Veracode Threat Research eine Analyse eines bösartigen npm-Pakets mit dem Namen „@acitons/artifact“, das die legitime GitHub Actions-Abhängigkeit „@actions/artifact“ durch Typosquatting missbraucht und GitHub-eigene Repositories angreift, die die GitHub Actions CI/CD-Plattform nutzen. Der Bericht stellt fest, dass sechs bösartige Versionen dieses Pakets einen Post-Install-Hook enthielten, der zusätzliche Malware herunterlud und ausführte, die zum Zeitpunkt der Analyse von gängigen Antivirenprodukten nicht erkannt wurde. Des Weiteren wurden die schädlichen Versionen entfernt, während der Paketname selbst auf npm erhalten blieb. Veracode kam zu dem Schluss, dass die Kampagne beabsichtigte, während der Erstellung von GitHub-eigenen Repositories ausgeführt zu werden, Build-Umgebungstoken zu exfiltrieren und diese Token dann zu verwenden, um neue bösartige Artefakte auf GitHub zu veröffentlichen. Dies unterstreicht das Risiko einer Software-Lieferkette, das mit den OWASP Top 10 2025 „A03:2025 – Software-Lieferkettenausfälle“ übereinstimmt.

Die Angriffskette beginnt mit Lieferkettenkompromittieren über eine manipulierte package.json-Datei, die die legitimen Metadaten „@actions/artifact“ detailgetreu nachbildet, einschließlich derselben Homepage, Repository-URL und Beschreibung. Allerdings werden die Buchstaben „ti“ im Paketnamen durch „it“ ersetzt, sodass „@actions/artifact“ entsteht. Die manipulierten Versionen (4.0.12 bis 4.0.17) Definiere ein Postinstall-Skript, das curl gegen eine GitHub Gist-URL unter dem Benutzer „jmasdg“ ausführt, um eine Binärdatei namens harness abzurufen, die dann im Rahmen der npm-Installation auf dem GitHub Actions Runner ausgeführt wird. Im Blog wird darauf hingewiesen, dass VirusTotal zunächst keine gängigen harness als bösartig einstufte.

Die Analyse der Binärdatei des harness zeigt, dass es sich um ein verschleiertes Shell-Skript handelt, das mit dem Shell Script Compiler kompiliert wurde und einen fest codierten Ablaufmechanismus enthält, um die Ausführung nach dem 6. November 2025 UTC zu verhindern. Eine zugehörige Probe (tester) verfällt einen Tag später. Bei der Ausführung startet harness -Programm sich selbst unter Bash neu, nachdem es eine Umgebungsvariable gesetzt hat, um sein Laufzeitverhalten zu ändern. Anschließend gibt es ein eingebettetes Knoten.js-Paket aus, extrahiert es und führt es aus, das ein verschleiertes verify.js -Skript enthält. verify.js prüft die Umgebung von GitHub Actions, indem es die Umgebungsvariablen GITHUB_ untersucht und nur dann fortfährt, wenn der Repository-Inhaber GitHub ist; andernfalls wird der Vorgang abgebrochen. Das Skript schreibt nach dem Sammeln von Umgebungsdaten, einschließlich der für den Build-Job verfügbaren Token, einen verschlüsselten Datenblock (env.enc).

Die Nutzlast bezieht einen AES-Verschlüsselungsschlüssel von hxxps://83hfhjasksn.hopto[.]org:443/kljkalsd/ajkl12389/slkj1n_189n, wird als Dienst beschrieben, der zur Auflösung von DNS-Namen verwendet wird, verschlüsselt die gesammelten Daten und exfiltriert die verschlüsselte Datei nach hxxps://laughing-space-capybara-x5g6rjxq7jwvfp6q6-443.app.github[.]dev/sllkjdsss_user-dasd.txt. Die Kampagne scheint sich auf die eigenen Repositories von GitHub und ein wenig aktives Benutzerkonto mit der Bezeichnung „y8793hfiuashfjksdhfjsk“ zu konzentrieren, das möglicherweise zu Testzwecken verwendet wird. Bei einer Überprüfung der historischen Daten wurden Anfang des Monats auch zwölf Versionen eines weiteren bösartigen npm-Pakets, 8jfiesaf83, identifiziert und blockiert. GitHub gab später eine Erklärung ab, in der es hieß, die genannten Pakete seien Teil einer streng kontrollierten Red-Team-Übung gewesen, und versicherte, dass die Systeme und Daten von GitHub nicht gefährdet seien.

whoAMI Cloud Image Name Confusion Attack Against AWS AMIs

Am 12. Februar 2025 veröffentlichte Datadog Security Labs eine Studie, die den „whoAMI“-Cloud-Image-Namensverwechslungsangriff beschreibt. Dabei handelt es sich um ein Fehlkonfigurationsmuster bei der Art und Weise, wie viele Softwareprojekte Amazon Machine Image (AMI)-IDs abrufen. Dieses Muster ermöglicht es Angreifern, die speziell präparierte AMIs veröffentlichen, Code in anfälligen Amazon Web Services (AWS)-Konten auszuführen. Die Untersuchung zeigt, dass dieses anfällige Muster – das Abrufen von AMIs anhand des Namens über ec2:DescribeImages ohne Einschränkung des Eigentümers und die anschließende Verwendung des zuletzt zurückgegebenen Images – in privaten und OpenSource-Repositories auftritt; Datadog schätzt, dass etwa 1 % der Organisationen, die AWS nutzen, betroffen sind und dass die TTPs im großen Maßstab den Zugriff auf Tausende von AWS-Konten ermöglichen. Das Team bestätigte außerdem, dass interne AWS-Systeme, die nicht für den Produktiveinsatz geeignet sind, vor der Behebung des Problems durch AWS im Rahmen des Sicherheitslücke Disclosure Program (VDP) für das gleiche Muster anfällig waren.

Aus Sicht des Opfers beginnt die Angriffskette, wenn der Code mithilfe der ec2:DescribeImages API und einem Namensfilter eine AMI-ID abruft, die Parameter owner, owner-alias oder owner-id weglässt und dann das neueste Image aus den Ergebnissen auswählt. Dieselbe AMI-ID wird anschließend verwendet, um EC2-Instanzen zu erstellen, Vorlagen zu starten und andere Infrastruktur bereitzustellen. Datadog veranschaulicht dies anhand eines gängigen Terraform-Datenmusters aws_ami , das most_recent = true setzt und nach ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-* filtert, aber keinen Besitzer angibt. Dies führt dazu, dass der AWS-API-Aufruf öffentliche Community-AMIs aus jedem Konto zurückgibt, und Terraform wählt automatisch das neueste AMI aus dieser Liste aus. Ähnliche Anti-Patterns treten in Go und anderen Sprachen auf, wo die Code-Logik DescribeImages nur mit einem Namensfilter aufruft (z. B. Werte, die mit amzn2-ami-hvm-2.0.*-x86_64-gp2 übereinstimmen) und dann die erste zurückgegebene ImageId direkt an RunInstances übergibt.

Ein Angreifer, der diese Konfiguration ausnutzt, veröffentlicht oder klont ein AMI, dessen Name dem Suchmuster des Opfers entspricht und das neuer ist als alle legitimen Images. Anschließend veröffentlicht der Angreifer entweder das AMI oder teilt es privat mit dem angegriffenen AWS-Konto. Datadogs Beispiel verwendet ein bösartiges AMI mit dem Namen ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-whoAMI, Diese Option wird immer dann ausgewählt, wenn anfälliger Terraform- oder API-Code über eine Namenssuche „latest Ubuntu Focal“ auflöst. Wenn ein solcher Code ausgeführt wird, wird die EC2-Instanz vom AMI des Angreifers anstatt vom Image des vorgesehenen Anbieters gestartet. Dies ermöglicht es dem Angreifer, Remote-Code auf der Instanz des Opfers auszuführen und alle nachfolgenden Aktivitäten nach der Ausnutzung zu ermöglichen, die von der im AMI eingebetteten Hintertür unterstützt werden. Um dies sicher zu demonstrieren, erstellte Datadog ein AMI mit einer C2-Backdoor, teilte es privat mit einem kontrollierten „Opfer“-Konto und zeigte, dass das anfällige Muster zuverlässig das AMI des Angreifers instanziierte.

Das anfällige AMI-Lookup-Muster beschränkt sich nicht auf Terraform. Es tritt in mehreren Ökosystemen auf, darunter Python, Go, Java, Pulumi und Bash-Skripte, die die AWS CLI verwenden, immer dann, wenn DescribeImages nur nach Namen gefiltert und das „neueste“ Bild ausgewählt wird. Datadog berichtet, dass etwa 1 % der überwachten Organisationen dieses Anti-Pattern aufwiesen, was Tausende von verschiedenen AWS-Konten betraf. Nachdem der Angriff in einer kontrollierten Umgebung validiert worden war, arbeitete Datadog mit AWS zusammen, um zu testen, ob interne AWS-Systeme harmlose „Doppelgänger“-AMIs mit dem Präfix amzn2-ami-hvm-2.0 verbrauchen würden; Zehntausende SharedSnapshotVolumeCreated-Ereignisse zeigten, dass AWS-Dienste diese AMIs tatsächlich abriefen, was darauf hindeutet, dass einige interne Nicht-Produktionsumgebungen unsichere AMI-Abruflogik verwendeten, bevor das Problem behoben wurde. Die Untersuchung hebt außerdem eine Schwachstelle in einem von AWS bereitgestellten Tool hervor, aws-simple-ec2-cli. Dessen fest codierte Wildcard-Namensmuster für AMIs (wie z. B. amzn2-ami-hvm-2.?.????????.?-*-gp2) und das Fehlen von Eigentümerprüfungen in getDescribeImagesInputs ermöglichten das Klonen eines AMIs mit der Adresse amzn2-ami-hvm-2.0.20241014.0-RESEARCH-x86_64-gp2 (AMI ID ami-08b96120f4ae90485) sollte gegenüber dem offiziellen Image ausgewählt werden, bis das Tool aktualisiert wurde.

Allgemeine Maßnahmen und Empfehlungen

Während für jede der in diesem Bericht beschriebenen Cloud-Bedrohungen spezifische Abwehrstrategien erörtert wurden, hat die Insikt Group allgemeine Abwehrstrategien identifiziert, die auf der Grundlage der in diesem Bericht beschriebenen Ereignisse umgesetzt werden können. Die folgenden Strategien zur Bedrohungsabwehr und -minderung können in jeder Cloud-Umgebung implementiert werden, um den Sicherheitsstatus der Umgebung zu erhöhen:

Sicherheitslücke und Ausstellungsmanagement durch Dritte

  1. Aggressives Patching und Konfigurationsmanagement für Cloud- und Hybrid-Dienste mit Internetanbindung durchsetzen und Herstellerwarnungen zu kritischen CVEs als Auslöser für das Patchen von Produkten betrachten, die Cloud-Workloads oder Identitätsinfrastrukturen vorgelagert sind.
  2. Strenge Kontrollen des Lieferanten- und Drittanbieterrisikos für gemeinsam genutzte Cloud-Plattformen (z. B. Oracle EBS, Barracuda ESG Appliances, Cloud-E-Mail-Gateways) sind durchzusetzen, einschließlich vertraglicher Sicherheitsanforderungen, Patch-Service-Level-Agreements (SLA), Segmentierung der gehosteten Daten und eines klaren Verständnisses darüber, wessen Protokollierung und Erkennung die gemeinsam genutzte Umgebung abdeckt.
  3. Beschränken Sie die in Cloud-Plattformen von Drittanbietern gespeicherten sensiblen Daten auf das für den Geschäftsbetrieb erforderliche Minimum und segmentieren Sie HR-, Finanz- und Identitätsdaten so, dass der Kompromittierung eines einzelnen gehosteten Systems nicht automatisch vollständige Identitäts- und Bankdatensätze im gesamten Unternehmen offenlegt.

Netzwerk- und Perimeterkontrollen

  1. Minimieren Sie die direkte Internetanbindung von Management- und Überwachungsebenen, indem Sie diese hinter Cloud-VPNs, privaten Zugriffstools oder Zero-Trust-Produkten platzieren und den Zugriff auf die interne Cloud-Infrastruktur einschränken.
  2. Strenge Ausgangskontrollen für Cloud-Workloads und Benutzergeräte durchsetzen und den Datenverkehr zu allgemeinen SaaS-Plattformen, die als verdeckte C2- oder Dead-Drop-Kanäle fungieren können, explizit prüfen oder einschränken.
  3. Setzen Sie detaillierte Netzwerkkontrollen für Cloud-Speicher- und Backup-Dienste (S3, Azure Storage, Recovery Services Vaults, Snapshots, EBS-Volumes) ein, um einen breiten Zugriff zu verhindern, und fordern Sie erhöhte Arbeitsabläufe für Vorgänge wie das Bereitstellen von Speicher im Internet, das Abrufen von Zugriffsschlüsseln oder das Löschen von Backups und Wiederherstellungspunkten.
  4. Stellen Sie sicher, dass der DDoS-Schutz für alle mit dem Internet verbundenen Cloud-Endpunkte aktiviert und korrekt ausgelegt ist, und üben Sie regelmäßig die Einsatzbereitschaft durch simulierte groß angelegte volumetrische Angriffe, um zu bestätigen, dass die Workloads auch bei Angriffen durch IoT-Botnetze und ähnliche Infrastrukturen verfügbar bleiben.

IAM-Härtung

  1. Setzen Sie das Prinzip der minimalen Berechtigungen in der Cloud-IAM sowohl für menschliche als auch für nicht-menschliche Cloud-Konten um, indem Sie umfassende Rollen und mächtige Berechtigungen, wie z. B. globale Administrator- und Eigentümerrollen, explizit von Alltags- und Entwicklerkonten entfernen.
  2. Für alle privilegierten und verzeichnissynchronisierten Konten ist eine starke, durchsetzbare Multi-Faktor-Authentifizierung (MFA) erforderlich. Außerdem ist es verboten, dass Konten mit hohen Berechtigungen ohne MFA betrieben werden, einschließlich Dienstkonten, bei denen die Synchronisierung von Passwort-Hashes verwendet wird.
  3. Die MFA- und Helpdesk-Workflows müssen so gehärtet werden, dass für hochkarätige Identitäten (wie z. B. C-Suite-Konten, Cloud-Administratoren und andere Root-Konten) die MFA oder das Zurücksetzen von Passwörtern nicht ausschließlich auf der Grundlage statischer persönlicher Daten erfolgen kann. Außerdem muss sichergestellt werden, dass die Helpdesk-Tools privilegierte Konten eindeutig kennzeichnen und zusätzliche Verifizierungsschritte erzwingen, bevor die Authentifizierungsfaktoren geändert werden.
  4. Beschränken Sie mandantenübergreifende und kontoübergreifende Vertrauensbeziehungen in Cloud-Identitätsplattformen und erlauben Sie sts:AssumeRole, SAML-Federation und Multi-Tenant-OAuth-Apps nur dort, wo dies explizit erforderlich ist. Überprüfen Sie diese regelmäßig auf Missbrauchsmuster, die denen in Storm-0501 und der Silk Typhoon Kampagne ähneln.
  5. Implementieren Sie eine starke Governance für Service Principals und OAuth-Anwendungen in Cloud Identity (z. B. Entra ID), einschließlich der Überprüfung von App-Zustimmungen, der Überwachung neuer Apps mit hohen Berechtigungen oder Anmeldedaten , die bestehenden Apps hinzugefügt werden, und der Validierung, dass Multi-Tenant-Anwendungen für den Systembetrieb erforderlich sind.
  6. Beschränken Sie die Gültigkeitsdauer von Sitzungstoken und überwachen Sie die Verwendung zwischengespeicherter Token von ungewöhnlichen Standorten aus, insbesondere dort, wo ein Angreifer die bestehende authentifizierte Sitzung eines Entwicklers wiedergeben könnte, um auf AWS oder andere Cloud-Steuerungsebenen zuzugreifen, ohne erneut eine MFA-Abfrage durchzuführen.
  7. Implementieren Sie robuste Prozesse zur Kontolöschung und zum Zugriffsentzug, um zu verhindern, dass Konten ehemaliger Mitarbeiter oder Auftragnehmer als Zugangspunkte zu Cloud-Tenants oder -Repositories wiederverwendet werden. Überprüfen Sie regelmäßig, ob in der Umgebung keine gemeinsam genutzten oder verwaisten Administrator- Anmeldedaten mehr vorhanden sind.
  8. Überwachung von Privileged Access Vaults und Key Stores (z. B. CyberArk, Cloud Key Vaults, PAM-Plattformen) und Warnung bei Aktionen wie Massenzugriff auf geheime Daten, Export großer Mengen von Zugangsdaten und neuen Zugriffsrechten, die eine laterale Bewegung in Cloud-Dienste in großem Umfang ermöglichen könnten.

Härtung der Software-Lieferkette und CI/CD

  1. Behandeln Sie alle API-Schlüssel, Cloud-Zugriffsschlüssel und Sitzungstoken als hochgradig vertrauliche Informationen. Scannen Sie öffentliche und interne Repositories nach offengelegten geheimen oder sensiblen Schlüsseln, rotieren Sie alle gefundenen Schlüssel und stellen Sie sicher, dass Entwicklertools keine langlebigen Anmeldedaten an vorhersehbaren Dateisystemorten oder in Klartext-Konfigurationsdateien hinterlassen.
  2. Beschränken Sie die Workflows zur Auswahl von Cloud-Images, indem Sie AMI-Abfragen stets auf vertrauenswürdige Eigentümer und Konten beschränken und Plattformkontrollen wie AWS „Allowed AMIs“ sowie regelmäßige Scans (z. B. mit Tools ähnlich wie whoAMI-scanner) verwenden, um Workloads zu erkennen und zu verhindern, die von nicht verifizierten oder öffentlichen AMIs gestartet wurden.
  3. Überprüfen Sie die Nutzung von Infrastructure-as-Code, Skripten und Software Development Kits (SDKs) auf unsichere AMI-Lookup-Muster und setzen Sie Codierungsstandards durch, die explizite Eigentümerfilter für Cloud-Images in Terraform, CLI-Tools und Automatisierungscode erfordern.
  4. Isolieren und härten Sie Cloud-ML- und LLM-Dienste, indem Sie Entwickler- und Produktionskonten trennen, den Internet-Ausgang von Notebooks einschränken, die Ausführungsrollen auf die erforderlichen Aktionen beschränken und verhindern, dass Entwickler-Notebooks administrative oder kontoübergreifende Rollen in Produktions-LLM-Umgebungen übernehmen.
  5. Behandeln Sie LLM-Schutzmechanismen, Agenten und durch Abruf erweiterte Generierungswissensbasen als sensible Konfigurationsoberflächen. Diese Ressourcen müssen durch Änderungskontrollen geschützt werden. Es müssen Änderungen an den Guardrail-Block-Meldungen oder den Datenquellen der Wissensdatenbank überwacht werden. Außerdem muss eine Überprüfung aller Änderungen verlangt werden, die schädliche Download-Links oder ausführbaren Code in für den Benutzer sichtbare Antworten einfügen könnten.
  6. Schützen Sie in der Cloud gehostete statische Frontends und Anwendungsbündel (z. B. S3-basierte Webanwendungen) mit strenger Änderungskontrolle, Codesignierung oder Integritätsprüfungen. Überwachen Sie Objekte oder Buckets, die Benutzeroberflächen bereitstellen, auf unerwartete Änderungen.
  7. Die Sicherheit von Continuous Integration und Continuous Delivery bzw. Continuous Development (CI/CD)-Umgebungen (z. B. GitHub Actions) kann durch die Überprüfung von Abhängigkeitsdeklarationen auf typosquatte Pakete, das Festlegen von Versionen, wo dies möglich ist, und die Implementierung automatisierter Prüfungen zur Blockierung oder Kennzeichnung verdächtiger Pakete, die Postinstall-Hooks hinzufügen oder Binärdateien von nicht vertrauenswürdigen Domains abrufen, erhöht werden.
  8. Beschränken Sie CI/CD-Job-Tokens und andere kurzlebige Anmeldedaten auf die engstmöglich erforderlichen Gültigkeitsbereiche und Lebensdauern und überwachen Sie Pipeline-Hosts auf ausgehende Verbindungen zu ungewöhnlichen Domains oder verschlüsselte Daten-Uploads, die auf einen Token-Exfiltration aus Build-Umgebungen hindeuten könnten.
  9. Schützen Sie unternehmenseigene und Cloud-Anbieter-Code-Repositories (z. B. GitHub) mit starker MFA, Zugriffsüberprüfungen für ehemalige Mitarbeiter und Auftragnehmer sowie Backup-/Archivierungsstrategien, die eine schnelle Wiederherstellung ermöglichen, falls ein destruktiver Akteur Repositories oder Branches löscht.

Überwachung, Erkennung und Antwort

  1. Achten Sie auf Identitätsoperationen, die auf typische Vorgehensweisen von Cloud-Ransomware hindeuten, wie z. B. die Ausweitung des Zugriffs (z. B. Azure elevateAccess), die massenhafte Zuweisung von Besitzer- oder gleichwertigen Rollen über Abonnements hinweg, die Erstellung neuer föderierter Vertrauensstellungen sowie die groß angelegte Speicheraufzählung und den Schlüsselabruf.
  2. Stellen Sie sicher, dass die Protokollierung von Identitäts-, Steuerungs- und Datenebenenaktionen über alle Cloud-Anbieter hinweg umfassend ist und aufrechterhalten wird. Integrieren Sie diese Protokolle in analytische Arbeitsabläufe, die in der Lage sind, Missbrauch von Zugangsdaten, mandantenübergreifende Pivot-Operationen und Massenabflüsse zu erkennen.

Härtung von Endgeräten und administrativen Arbeitsstationen

  1. Die Entwickler- und Administrationsendpunkte, die mit Cloud-Steuerungsebenen verbunden sind, werden durch das Verbot von gecrackter oder raubkopierter Software, die Durchsetzung von Endpunktschutz und Anwendungskontrolle sowie die Behandlung jedes Systems mit Cloud-Zugriffsschlüsseln oder SSO-Tokens als wertvolles Gut, das einer stärkeren Überwachung und Einschränkung bedarf, gehärtet.

Backup- und Wiederherstellungshärtung

  1. Nutzen Sie Cloud-native Schutzmechanismen wie Unveränderlichkeit (z. B. Leseberechtigungen), Sperren und Aufbewahrungsrichtlinien für Backup-Container, Snapshots und Tresore. Dadurch wird sichergestellt, dass selbst hochprivilegierte Rollen bei Ransomware- oder zerstörerischen Cloud-Angriffen nicht einfach in einem einzigen Schritt Wiederherstellungsdaten löschen oder verändern können.

Die gängigsten CSPs bieten native Cloud-Dienste an, die die oben genannten Abhilfemaßnahmen ermöglichen, darunter das Scannen der Umgebung auf potenzielle Fehlkonfigurationen, die Überwachung des grundlegenden Kontoverhaltens, die Überwachung des Netzwerkverkehrs, rollenbasierte Zugriffskontrolle oder IAM-Suiten und Datenschutz. In Cloud-Umgebungen, in denen es weniger verwaltete Cloud-Dienste gibt und die Verantwortung für die Verteidigung stärker bei den Cloud-Verteidigern und -Architekten liegt, ist es jedoch von größter Bedeutung sicherzustellen, dass klare Richtlinien und Baselines für die Erstellung, Verwaltung und Instandhaltung der Cloud-Infrastruktur einer Organisation festgelegt werden.

Ausblick

Die in diesem Bericht aus dem Jahr 2025 diskutierten Ereignisse deuten darauf hin, dass Bedrohungsakteur ein zunehmendes Verständnis sowohl von Cloud-Umgebungen als auch deren Nutzen als Teil einer Angriffskette besitzt. Ereignisse im Zusammenhang mit Cloud-Ransomware, dem Missbrauch von Cloud-LLM- und ML-Diensten Bedrohungsakteur sowie dem Missbrauch verschiedener Cloud-Dienste für C2-Infrastrukturen untermauern diese Behauptung und zeigen darüber hinaus, dass legitime Cloud-Ressourcen missbraucht werden können, um böswillige Ziele zu erreichen. Bedrohungsakteur wird mit ziemlicher Sicherheit auch weiterhin zusätzliche Cloud-Plattformen und -Produkte identifizieren, die für böswillige Aktionen missbraucht werden können. Ebenso wird Bedrohungsakteur weiterhin Cloud-native Dienste als Methoden in Angriffsketten gegen Cloud-Umgebungen nutzen, insbesondere da diese Methoden für Bedrohungsakteur die effektivste Option darstellen, um Cloud-Umgebungen zu stören und Daten zu stehlen.

Um diese Aktionen durchzuführen, muss Bedrohungsakteur weiterhin unbefugten Zugriff erlangen, sowohl am Rand von Cloud-Umgebungen als auch innerhalb dieser. Die häufigsten Wege, auf denen dieser Zugriff gewährt wird, sowohl extern als auch intern, bleiben Fehlkonfiguration und Missbrauch gültiger Zugangsdaten, in dieser Reihenfolge. Allerdings demonstrieren Bedrohungsakteur , dass die Ausnutzung von Produkten, die am Rande von Cloud-Umgebungen oder in Fällen von Private Clouds eingebettet sind, eine praktikable Option für Cloud-Kompromiss darstellt. Mit der zunehmenden Verbreitung von Cloud-Computing steigt auch die Anzahl neuer Produkte und Dienstleistungen, was zu einem Anstieg potenzieller Sicherheitslücke und Fehlkonfigurationen führt. Bedrohungsakteur wird diese Schwächen daher auch weiterhin ausnutzen. Da in Cloud-Ökosystemen immer mehr Programme und Dienste mit KI-gesteuertem Code entstehen, steigt auch die Zahl der Sicherheitslücke durch ungeprüften Code. Dies eröffnet Bedrohungsakteur Möglichkeiten, Cloud-Nutzer und -Dienste auszunutzen.

Letztendlich bleibt der Datendiebstahl die bedeutendste Folge von Angriffen auf Cloud-Umgebungen; Bedrohungsakteur verfolgen jedoch zunehmend zusätzliche Ziele, darunter TTPs in der Cloud und verschiedene Formen der Ressourcenentführung. Daher kann sich die Gesamtdauer der Angriffe auf Cloud-Umgebungen verlängern, da Bedrohungsakteur möglicherweise zusätzliche Zeit und Ressourcen benötigen, um eine Angriffskette zum Erfolg zu führen oder den Nutzen ihrer Angriffe zu maximieren. Während diese Verweildauer den Verteidigern mehr Zeit gibt, um schädliche Aktionen in ihren Umgebungen zu erkennen und zu beheben, bietet sie Angreifern auch mehr Möglichkeiten, sensible Informationen zu identifizieren. Je länger diese Einheit den Zugriff aufrechterhalten können, desto größer ist das Risiko einer Kompromittierung der gesamten Cloud-Umgebung.