So nutzt Ransomware Cloud-Dienste ausCloud-native Ransomware und ihre Gefahren

Angesichts der zunehmenden Verbreitung der Cloud droht mittlerweile die Gefahr, dass Ransomware auch Cloud-basierte Workloads beeinträchtigen könnte. Nach Meinung von Experten bei Vectra AI stellt sich die Frage, ob es einen evolutionären Druck auf Angreifer geben wird, ihre Taktiken weiterzuentwickeln.

Wo auch immer kritische Daten liegen, wird früher oder später Ransomware auftauchen. Wenn Geschäftsdaten in der Cloud und nicht etwa in einer lokalen Datenbank gespeichert sind, werden Angreifer ihre Taktik so anpassen, dass sie Cloud-Systeme ebenso angreifen wie lokale Systeme.

Hier werden die Wege aufgezeigt, die ein Angreifer in der Cloud einschlagen könnte, um die Verfügbarkeit von Daten mit Hilfe der vom Cloud Service Provider (CSP) bereitgestellten Tools zu beeinträchtigen. Zusätzlich zu den Verhaltensweisen der Angreifer werden proaktive Schritte zur Sicherung von Cloud-APIs, die kryptografische Dienste bereitstellen, skizziert. Weitere Themen sind architektonische Muster, um die Sicherung dieser Systeme zu vereinfachen, und Methoden zur Erkennung von Cloud-nativer Ransomware.

Angriffe auf die Verfügbarkeit in der Cloud

In den ersten mehr als zehn Jahren der Cloud-Transformation haben sich die Cloud-Migration und die Ablage immer größerer Datensätze in der Cloud beschleunigt. Trotz dieses offensichtlichen Wandels stehen bei Überlegungen zu Ransomware oft nur an lokale Umgebungen im Fokus, wobei die Bedrohung auf die Cloud nur grob projiziert wird.

In der Cloud sind die verfügbaren Tools, die Entwickler und Kunden zur Bewältigung alltäglicher Aufgaben benötigen, bereits integriert und werden von den Serviceprovidern als Funktionen bereitgestellt. Angreifer greifen häufig auf dieselben Tools und Funktionen zurück, um Sicherheitskontrollen zu überwinden, eine Entdeckung zu vermeiden und bestimmte Ziele zu erreichen. Die Nutzung dieser Funktionen in böser Absicht wird oft als Funktionsmissbrauch bezeichnet.

Die Offenheit von Cloud-nativen Diensten über APIs macht es Angreifern leicht, Tools zu missbrauchen. APIs, die von jedem CSP erstellt werden, sind leicht auffindbar, lassen sich schnell verstehen und auf unbeabsichtigte Weise nutzen. Der Missbrauch von Funktionen stellt ein zusätzliches Risiko zu Code-Schwachstellen dar.

Anders als bei der Ausnutzung einer Schwachstelle gibt es keinen zu manipulierenden Code-Fehler, der durch Musterabgleich entdeckt oder durch Patches gesichert werden könnte. Stattdessen nutzen Angreifer die vom CSP zur Verfügung gestellten Tools für die Bereitstellung oder Wartung der Produktionssoftware und -infrastruktur, um bösartige Aktivitäten durchzuführen.

In gewisser Weise wird Ransomware in der Cloud durch den Missbrauch öffentlicher APIs den Trend des „Living off the Land“ fortsetzen, bei dem die „LOL Binaries“ der Cloud ihre APIs sind, die reich an Funktionen und öffentlich sind. Im Gegensatz zu ausführbaren Windows-Programmen, die als überflüssige Software deinstalliert werden können, sind die AWS-Cloud-APIs immer aktiv. Offenheit, Zugriff und Verfügbarkeit sind weiterhin das, was die Dienste benötigen, bieten aber auch die Möglichkeit für verheerende Ransomware-Angriffe.

Wo werden Cloud-Daten gehostet?

Um die Missbrauchstechniken zu verstehen, die Ransomware-Betreiber einsetzen könnten, gilt es zunächst die Systeme zu verstehen, auf denen die Daten gespeichert sind. On-Premises-Daten werden wahrscheinlich in verschiedenen Technologien gespeichert, von Oracle-Datenbanken bis hin zu Microsoft SQL-Servern. Diese Systeme haben gemeinsam, dass es sich um physische Hosts handelt, die vollständig unter der Kontrolle der Unternehmen stehen.

Bei lokalen Data-Warehouse-Servern handelt es sich in der Regel um physische Hosts, die in einer Full-Stack-Umgebung implementiert sind und aufgrund der großen Angriffsfläche ein leichtes Ziel für Malware darstellen. Full-Stack-Umgebungen profitieren jedoch von robusten Datenschutzstrategien. Hier kommen Sicherheitskontrollen zum Einsatz, die sich in den letzten 20 Jahren bei der Modellierung netzwerkbasierter Bedrohungen entwickelt haben. So sind herkömmliche lokale Datenbanken hinter Schichten von Netzwerkkontrollen versteckt, in den Tiefen von Unternehmensnetzwerken eingeschlossen und werden mit agentenbasierter Bedrohungserkennung streng überwacht.

Der ortsgebundene Ansatz zur Sicherung herkömmlicher Datenspeicher lässt sich nicht auf die Cloud übertragen und sollte es auch nicht. Daten, die in die Cloud migriert werden, befinden sich in Systemen, in denen alle Endbenutzer, einschließlich böswilliger, einen begrenzten, eingeschränkten Zugriff auf das zugrundeliegende System haben. Das bedeutet, dass Cloud-Datenspeicher ganz andere Angriffsflächen bieten.

Jeder der großen Cloud-Betreiber (z. B. AWS, Azure, GCP) hat eine eigene Version eines verteilten, hochverfügbaren Allzweck-Datenspeichers: AWS S3, Azure Blob Storage und GCP Storage Buckets. Jeder von ihnen ist ein zentraler Speicher für unstrukturierte Daten und ein allgegenwärtiger, stabiler und hochverfügbarer Dienst. Dieser lässt sich mit vielen anderen Diensten auf den jeweiligen Plattformen integrieren und erfüllt nahezu alle Datenspeicheranforderungen der Kunden. Die Cloud-Betreiber nutzen Speicherdienste zum Aufbau von Pipelines und als Backing-Datenspeicher für Big-Data-Plattformen oder als öffentliche Repositories für Webinhalte. Als AWS-Kunde beispielsweise ist es schwer, auf S3 zu verzichten. Genau dies macht es zu einem wahrscheinlichen Ziel für Cloud-native Ransomware-Autoren.

Erkennung von Cloud-nativer Ransomware

Es gibt mehrere Möglichkeiten, die Angreifer nutzen könnten, um die Verfügbarkeit von auf S3 gehosteten Daten zu beeinträchtigen. Ein fiktiver Angreifer könnte eine Methode zur Sperrung von Schlüsselrichtlinien nutzen, um die Verfügbarkeit eines neuen KMS-Schlüssels zu beeinflussen.

Es besteht auch die Möglichkeit, ebenso bei einem vorhandenen Schlüssel vorzugehen. Möglich wäre auch die böswillige Verschlüsselung von S3-Daten mit einem externen KMS-Schlüssel, der sich in einem vom Angreifer kontrollierten Konto befindet.

Die drei Methoden im Detail:

• Sperrung der Schlüsselrichtlinie mit neuem Schlüssel: Wenn ein Angreifer diese Technik anwendet, gibt es zwei kritische Punkte, auf die während der Exploitation-Phase reagiert werden könnte – die Beobachtung der Verwendung eines neuen KMS-Schlüssels und die Erfassung der Ereignisse im Zusammenhang mit der Aktualisierung der Schlüsselrichtlinie. Wenn ein Unternehmen eine klare Vorstellung davon hat, welche Schlüssel für die Verschlüsselung verwendet werden sollten, sollte die Verwendung von nicht genehmigten KMS-Schlüsseln einen Alarm auslösen. Darüber hinaus sollte die Aktualisierung der Schlüsselrichtlinie, um einen der in diesem Dokument erwähnten globalen Bedingungsschlüssel einzubeziehen, ebenfalls ein Follow-up rechtfertigen.
• Sperrung der Schlüsselrichtlinie mit bestehendem Schlüssel. Ein Angreifer kann sich darauf konzentrieren, einen bestehenden KMS-Schlüssel zu beschädigen. Dies lässt nur begrenzte Möglichkeiten zur Erkennung während der Exploitation-Phase. Benutzerdefinierte Warnungen könnten dennoch erstellt werden, um Sicherheitsfachkräfte zu benachrichtigen, wenn die Schlüsselrichtlinie aktualisiert wird, um einen der globalen Bedingungsschlüssel (bei AWS aws:PrincipalArn, aws:PrincipalAccount, aws:sourceVPC und aws:SourceVPCe) einzuschließen. Dies könnte auf einen Cloud-nativen Ransomware-Angriff hindeuten.
• Verschlüsselung mit externem KMS-Schlüssel. Dieses Szenario soll hier nicht näher erläutert werden, ist aber dennoch ein praktikabler Mechanismus für die böswillige Verschlüsselung von Daten. Sicherheitsteams sollten benachrichtigt werden, wenn Verschlüsselungsvorgänge mit KMS-Schlüsseln durchgeführt werden, die sich nicht in einem Konto unter ihrer Kontrolle befinden.

Cloud-Betreiber stellen kryptografische Tools zur Verfügung. Wenn diese nicht ordnungsgemäß gesichert sind, können Ransomware-Banden diese missbrauchen, um die Verfügbarkeit von Daten in der Cloud zu beeinträchtigen.
Eine erfolgreiche Ransomware-Kampagne in der Cloud nutzt Cloud-native Dienste zur schnellen Verschlüsselung von Daten und integrierte Zugriffskontrollmechanismen, um das Opfer von wichtigen Geschäftsdaten auszusperren. Der Entwurf zentralisierter Architekturmuster für die Schlüsselverwaltung ist der erste Schritt zur Verhinderung von Cloud-nativer Ransomware.

Eine zentralisierte Schlüsselverwaltung ermöglicht sowohl eine effektivere Vorbeugung gegen Ransomware als auch ein konsistenteres Bild davon, wie ein normales kryptografisches Muster in einer Cloud-Umgebung aussieht.

Obwohl eine präventive Haltung ideal ist, ist es unwahrscheinlich, dass die Mehrheit der Unternehmen diese architektonischen Kontrollmaßnahmen vom ersten Tag an einsetzen kann. Darüber hinaus obliegt es jedem Unternehmen, selbst denen mit sehr restriktiven Umgebungen, für den Tag zu planen, an dem die „Leitplanken“ versagen.

Daher sollte die Erkennung, ob in der Cloud gehostete Daten von Ransomware betroffen sind, die oberste Priorität sein. Die Erkennungsstrategien variieren je nach der vom Angreifer verwendeten Technik, basieren jedoch auf dem Konzept, zu wissen, was Aktivitäten von externer Seite für die Cloud-Umgebung bedeuten.

Andreas Riepen ist Head Central & Eastern Europe bei Vectra AI.

Vectra AI