Was Sie über AWS-Ransomware wissen müssen

So gravierend das Problem Ransomware in Rechenzentren ist, so skeptisch war ich, dass es in der Cloud eine große Rolle spielt. Mir persönlich war noch kein Vorfall begegnet, und ich hielt das Thema eher für theoretisch als für real. Es stellte sich heraus, dass ich damit etwas falsch lag. Gut, völlig falsch. Das Problem ist nicht nur größer, als ich dachte, das Angriffsmuster unterschied sich innerhalb von Amazon Web Services (AWS) auch von dem, was ich erwartet hatte.

Auf der Konferenz AWS re:Inforce habe ich eine hervorragende Session von Kyle Dickinson, Megan O’Neil und Karthik Ram besucht. Sie war komplett ausgebucht, und die Saalaufsicht musste Dutzende Interessierte abweisen. Dieser Beitrag ist eine Art Zusammenfassung der Session, ergänzt um meine eigenen Erfahrungen und Empfehlungen zum Thema AWS-Ransomware. Etwaige Fehler und Auslassungen gehen auf mein Konto, nicht auf ihres.

Die wichtigsten Punkte:

• Ransomware-Akteure nehmen zunehmend Amazon-Web-Services-(AWS-)Umgebungen ins Visier und nutzen dabei häufig Lücken bei Identitätszugriffen, Storage-Konfigurationen und der Sichtbarkeit über Dienste hinweg aus.
• Amazon-S3-Buckets sind ein häufiger Einstiegspunkt: Angreifer verschlüsseln oder löschen kritische Daten, weil Richtlinien zu schwach sind oder die Verschlüsselung nicht durchgesetzt wird.
• Eine wirksame Ransomware-Abwehr in der Cloud erfordert eine mehrschichtige Strategie mit Zugriffskontrolle, Echtzeitüberwachung und schnellen Reaktionsabläufen.
• FireMon verbessert die Data Security Posture, indem es kontinuierlich auf Fehlkonfigurationen überwacht, Richtlinien in großem Maßstab durchsetzt und die Sichtbarkeit schafft, mit der Teams schneller auf cloudbasierte Ransomware-Bedrohungen reagieren können.

Ist Ransomware in Amazon AWS ein Problem?

Ja. AWS-Ransomware ist ein größeres Problem, als ich ursprünglich angenommen hatte. Reale Kunden sind betroffen, es ist nicht bloß theoretisch.

Wie läuft ein Amazon-Ransomware-Angriff ab?

Auf den ursprünglichen Angriffsvektor gehe ich bei der nächsten Frage ein, doch es gibt vier mögliche Techniken für Amazon-Ransomware-Angriffe:

• Angreifer kompromittieren eine Instanz (häufig durch Phishing bei einem Benutzer oder Administrator, nicht immer durch direkte Kompromittierung) und installieren dann ihre Malware, um die Daten zu verschlüsseln und sich auf weitere erreichbare Instanzen auszubreiten. Das unterscheidet sich kaum von Ransomware in einem Rechenzentrum, da hier nichts Cloud-Spezifisches im Spiel ist.
• Der Angreifer kopiert Daten aus einem S3-Bucket und löscht anschließend die Originaldaten. Das ist die am häufigsten beobachtete cloud-native Amazon-Ransomware.
• Ein böswilliger Akteur verschlüsselt S3-Daten mit einem KMS-Schlüssel, den er kontrolliert. Das ist aus mehreren Gründen eher theoretisch als real. Es ist deutlich einfacher, ein Objekt oder einen Bucket zu löschen, als es nachträglich zu verschlüsseln.
• Ein Angreifer manipuliert Daten in einem anderen Storage-Dienst, um sie zu sperren oder zu löschen. Ich bleibe bewusst vage, weil dies nicht beobachtet wird und die meisten dieser Dienste interne Beschränkungen und eine eingebaute Resilienz besitzen, die Ransomware schwer umsetzbar machen.

Ransomware zielt am häufigsten auf AWS-S3-Buckets, wobei die Angreifer die Daten kopieren und anschließend löschen. Auch Instanzen und Server können Ziel derselben Malware sein, die für Angriffe auf Rechenzentren eingesetzt wird. Einige theoretische Angriffe werden in freier Wildbahn kaum beobachtet.

Ein neuer Amazon-Ransomware-Angriff gewinnt jedoch an Verbreitung: Ransomware-Banden haben begonnen, Daten direkt vor Ort zu verschlüsseln – mithilfe der serverseitigen Verschlüsselung von AWS mit kundenseitig bereitgestellten Schlüsseln (SSE-C). Mit dieser Technik können Angreifer Dateien unmittelbar in Ihren S3-Buckets verschlüsseln, ohne sie zu entfernen oder Standardwarnungen auszulösen; eine Wiederherstellung ohne den individuellen Verschlüsselungsschlüssel des Angreifers ist unmöglich.

Wie erlangen Bedrohungsakteure Zugriff für Ransomware-Angriffe auf Amazon Web Services?

Über offengelegte Zugangsdaten. Fast immer statische Access Keys, möglicherweise aber auch Schlüssel aus einer kompromittierten Instanz (über den Metadatendienst). Also im Grunde so, wie nahezu alle cloudbasierten Sicherheitsangriffe funktionieren.

Wie verläuft ein S3-Ransomware-Angriff?

Ich konzentriere mich auf das Szenario der S3-Bucket-Ransomware, da dies der cloud-native Fall ist, auf den es hier ankommt.

• Der Angreifer erlangt Zugangsdaten.
• Der Angreifer nutzt die Zugangsdaten zur Aufklärung, um zulässige API-Aufrufe zu ermitteln und zugängliche Ressourcen zu identifizieren.
• Der Angreifer stellt fest, dass er über S3-Schreibrechte sowie List- und Lesezugriff zur Identifizierung von Buckets verfügt. Beachten Sie: Der Angreifer verfügt möglicherweise nicht über List-Rechte, kann die Bucket-Namen aber aus anderen Quellen beziehen, etwa DNS, GitHub oder anderen Orten. Das ist deutlich unwahrscheinlicher.
• Der Angreifer kopiert oder verschiebt Daten an einen anderen Ort, der nicht zwingend in AWS liegt.
• Der Angreifer löscht die Quellobjekte bzw. -dateien.
• Der Angreifer lädt eine Lösegeldforderung hoch (oder verschickt sie per E-Mail).

In jüngsten Kampagnen setzen Angreifer zudem S3-Object-Lifecycle-Management-Richtlinien ein, um verschlüsselte Dateien innerhalb von sieben Tagen zur Löschung vorzumerken und so den Druck zur Zahlung des Lösegelds zu erhöhen. Häufig hinterlassen sie im betroffenen Verzeichnis eine Datei warning.txt mit einer Bitcoin-Wallet-Adresse und einer eindeutigen Opfer-ID.

Da dies vollständig automatisiert abläuft, kann der Prozess innerhalb einer Minute nach Offenlegung der Zugangsdaten beginnen.

Wie lässt sich Amazon-S3-Ransomware erkennen?

Nun, falls Sie nicht direkt zur Prävention von S3-Ransomware springen können …

Der Angreifer hinterlässt in der Regel eine Nachricht mit Kontaktinformationen, damit Sie ihm Bitcoin senden können – praktisch. Aber vermutlich möchten die meisten von Ihnen ein Problem schon vorher erkennen. Gehen wir die Angriffsabfolge bei Amazon-S3-Ransomware durch, um zu sehen, an welchen Stellen wir ansetzen können.

Zunächst sollten Sie eine tiefergehende Überwachung Ihrer sensiblen Buckets aktivieren. Da dieser Beitrag ohnehin länger wird, als mir lieb ist, überspringe ich alle Details dazu, wie sich diese Buckets identifizieren und verwalten lassen, und konzentriere mich stattdessen auf einige wichtige Quellen. Aus Kostengründen sollten Sie nicht davon ausgehen, diese für alles aktivieren zu können:

• CloudTrail, selbstverständlich.
• CloudTrail Data Events für alle relevanten Buckets. Das kostet extra.
• GuardDuty.
• Optional: Security Hub. Dies ist der beste Weg, um GuardDuty und weitere AWS-Sicherheitsdienste über alle Ihre Konten hinweg zusammenzuführen.
• Eventuell: S3 Server Access Logs. Mit CloudTrail Data Events erhalten Sie bereits das Meiste, was Sie brauchen. S3-Logs lassen sich jedoch kostenlos erstellen (Sie zahlen nur für den Speicher) und erfassen einige Ereignisse, die CloudTrail möglicherweise übersieht (z. B. fehlgeschlagene Authentifizierungen). Sie sind allerdings erst nach Stunden sichtbar und damit in einem laufenden Vorfall nicht nutzbar. Mehr dazu in diesem Benutzerhandbuch.

Nachdem wir die Überwachung behandelt haben, sehen wir uns die sieben Schritte des Erkennungsprozesses an:

1. Offengelegte Zugangsdaten und Aufklärungsaktivitäten erkennen

Der Erkennungsprozess beginnt damit, dass Sie selbst oder Dritte öffentlich zugängliche oder kompromittierte AWS-Schlüssel sowie verdächtige Aktivitäten identifizieren. Meist durch das Scannen eines verbreiteten Repositorys wie GitHub. Amazon Web Services hat einmal einen meiner Schlüssel gefunden und mir eine E-Mail geschickt. Hoppla.

Ihre Erkennungen für die Aufklärung von Kontozugangsdaten greifen hier. Einige Möglichkeiten:

• GuardDuty-Findings, etwa zur Exfiltration von Zugangsdaten. Allerdings besteht hier eine Verzögerung von etwa 20 Minuten, und es gibt Umgehungstechniken
• Der API-Aufruf GetCallerIdentity ist nicht grundsätzlich bedenklich, sollte in Produktionskonten aber nicht häufig auftreten
• GetAccountAuthorizationDetails sollte jedes Mal einen Alarm auslösen
• Mehrere fehlgeschlagene API-Aufrufe von einer einzelnen IAM-Entität

2. Auf S3-Enumeration achten

Nun richten wir den Blick auf AWS-Ransomware-Erkennungen, die darauf hindeuten, dass der Angreifer sich auf S3 konzentriert. Ihnen wird vermutlich auffallen, dass eine frühe Erkennung in diesen Phasen aufgrund des Rauschens schwierig sein kann. Bedenken Sie jedoch, dass sie in Situationen wie Produktionskonten, die über CI/CD mit begrenztem menschlichem Zugriff verwaltet werden, praktikabler ist. Das mag Sie sogar dazu motivieren, stärker auf cloud-native Muster zu setzen.

Die GuardDuty-S3-Findings für Discovery-Ereignisse müssen – je nach Einrichtung Ihres Kontos und Ihrer Organisation – zusätzlich zur bloßen Aktivierung von GuardDuty eingeschaltet werden. Filtern Sie nach fehlgeschlagenen Read- und List-Management- sowie Data-Events im S3-Dienst. So ertappen Sie den Angreifer womöglich beim Umsehen. Sie können dies in Ihrem SIEM umsetzen, lassen sich dafür aber auch einfach CloudWatch-Metrics-Filter aufbauen.

3. Objektzugriffe und Kopiervorgänge überwachen

Hier kontinuierlich überwachen, um festzustellen, ob der Angreifer die Objekte liest und Kopien anfertigt. Wenn er jedes Objekt liest (kopiert) und anschließend löscht, kann dies mit der nächsten Phase verschmelzen.

4. Massenlöschung und Platzierung der Lösegeldforderung erkennen

Dies ist die Phase, in der es ernst wird. Der Angreifer sieht sich nicht mehr nur um, sondern führt den Angriff aus und löscht die kopierten Daten. Die GuardDuty-Findings zu Exfiltration/Impact für S3 greifen nun. Denken Sie daran: Die Auslösung dauert mindestens 20 Minuten, und je nach Anzahl der Objekte kann dies ein später Indikator sein. CloudTrail Insights warnt Sie, sofern Sie es nutzen, bei der großen Anzahl an Write-Ereignissen, die zum Verschieben der Daten verwendet werden.

Sie können eigene Erkennungen für eine große Anzahl von Delete-Aufrufen erstellen. Je nach Umgebung und üblichen Aktivitätsmustern kann dies ein niedriger Wert sein und schneller auslösen als GuardDuty. Ihr SIEM und CloudWatch Metrics Filters sind dafür gute Optionen.

5. SSE-C-Missbrauch erkennen (stille Verschlüsselung)

Überwachen Sie die plötzliche Verwendung von SSE-C-Headern in API-Aufrufen wie PutObject – ein Anzeichen dafür, dass Daten mit dem Schlüssel des Angreifers verschlüsselt werden könnten. Da AWS nur einen HMAC-Hash der Vorgänge protokolliert, ist eine forensische Wiederherstellung ohne proaktive Überwachung unmöglich.

6. Canary-Buckets und KMS-Erkennung nutzen

Reife Organisationen können Konten mit Canary-Buckets/-Objekten bestücken und bei jedem Vorgang, der diese Buckets betrifft, eine Warnung auslösen. Auch wenn es ein weniger verbreitetes Angriffsmuster ist, können Sie bei der Verwendung eines KMS-Schlüssels von außerhalb Ihres Kontos warnen.

7. Eskalation und Incident Response

Wenn Sie den Angriff erst hier erkennen, sind Sie bereits kompromittiert. Jetzt ist es Zeit zu reagieren. Verständigen Sie die Strafverfolgungsbehörden und ziehen Sie das AWS Customer Incident Response Team hinzu.

Schutz vor AWS-Ransomware: Wie kann ich mein Unternehmen absichern

Für einen erfolgreichen AWS-Ransomware-Angriff benötigt der Angreifer drei Voraussetzungen:

• Zugang zu Anmeldedaten
• Berechtigungen zum Lesen und Schreiben in S3
• Die Möglichkeit, Objekte unwiederbringlich zu löschen

Die erste Ebene bei der Ransomware-Prävention besteht darin, IAM abzusichern und anschließend die integrierten AWS-Werkzeuge für Resilienz zu nutzen. Das ist leicht gesagt und schwer umzusetzen, aber hier ist eine auf S3 fokussierte Checkliste, wobei ich die meisten der üblichen Hygienemaßnahmen und Kontrollen weglasse:

• Lassen Sie IAM-Benutzer mit statischen Zugriffsschlüsseln gar nicht erst zu. Falls das nicht möglich ist, identifizieren Sie mit Ihren Werkzeugen unbedingt alle Benutzer mit S3-Löschberechtigungen.
• Verlangen Sie MFA für SSO-/föderierte Benutzer. Immer und ausnahmslos.
• Lassen Sie Administratoren in eine andere IAM-Rolle wechseln, wenn sie Löschvorgänge durchführen müssen. Sie können Lese- und Löschberechtigungen sogar vollständig auf getrennte Rollen aufteilen.
• Wenn eine Instanz Zugriff auf S3 benötigt, fassen Sie die Berechtigungen so eng wie möglich: auf die minimal erforderlichen API-Aufrufe für die minimal erforderlichen Ressourcen.
• Deaktivieren Sie SSE-C, sofern es nicht zwingend erforderlich ist. Das hilft, stille Verschlüsselungsangriffe zu verhindern, die Sie ohne Wiederherstellungsmöglichkeit von Ihren Daten aussperren können.
• Greifen Sie über einen VPC-Endpunkt auf den Bucket zu und ergänzen Sie eine Ressourcenrichtlinie, die das Löschen nur aus der Quell-VPC erlaubt. Dann kann der Angreifer die Anmeldedaten außerhalb dieser VPC nicht verwenden.
• Aktivieren Sie Versionierung, AWS Backup und/oder Bucket-Replikation. All dies stellt sicher, dass Sie den Zugriff auf Ihre Daten nicht verlieren können. Es sei denn, Sie richten Ihre IAM-Richtlinien WIRKLICH schlecht ein und überlassen sie dem Angreifer. Einige dieser Optionen müssen bereits beim Erstellen des Buckets aktiviert werden, sodass gegebenenfalls eine Migration erforderlich ist.

Sie werden bemerken, dass ich Block Public Access auslasse. Das ist eine hervorragende Funktion, aber viele Organisationen tun sich schwer, sie in großem Maßstab umzusetzen, da sie einige öffentliche Buckets benötigen und die Funktion bei Angriffen mit offengelegten Anmeldedaten nicht hilft.

All das erfordert Aufwand und verursacht Kosten, daher empfehle ich, sich zu Beginn auf die wirklich wichtigen Buckets zu konzentrieren. Es gibt einige fortgeschrittenere Strategien, insbesondere für größere Umgebungen, die den Rahmen eines Beitrags sprengen – schreiben Sie mir, wenn Sie darüber sprechen möchten.

Was haben Sie in der Re:Inforce-Session Neues über S3-Ransomware gelernt

Mir war nicht bewusst, wie verbreitet S3-Ransomware ist. Ebenso wenig wusste ich, dass Kopieren und anschließendes Löschen die bevorzugte Angriffstechnik ist. Ich hatte angenommen, es sei die KMS-Verschlüsselung, und es ergibt vollkommen Sinn, warum diese eher theoretisch und selten ist. Die Detektoren und Abwehrmaßnahmen waren mir vertraut, aber die AWS-Referenten haben sie auf sehr klare und praxistaugliche Weise hervorragend zusammengeführt. Der Vortrag hat meine Erwartungen deutlich übertroffen.

Wie kann FireMon mein Unternehmen beim Schutz vor S3-Ransomware unterstützen

Wir haben ein neues IAM-Produkt in der Beta-Phase für Just-in-Time-Berechtigungen, das bald verfügbar sein wird. Außerdem bieten wir in DisruptOps Posture-Prüfungen und Threat-Detektoren, um riskante Buckets zu identifizieren und bei bösartigen Aktivitäten wie Ransomware-Angriffen zu warnen. Schreiben Sie mir, wenn Sie darüber sprechen möchten – oder auch, wenn Sie nur allgemeinen Rat zu den in diesem Beitrag erwähnten AWS-Optionen wünschen.

Demo Buchen und erfahren Sie, wie FireMon Ihr Unternehmen vor AWS-Ransomware schützen kann.