AWS Germany – Amazon Web Services in Deutschland

Die Anatomie eines Ransomware-Angriffs auf Daten in Amazon S3

Ransomware-Ereignisse haben in den letzten Jahren deutlich zugenommen und weltweit Aufmerksamkeit erregt. Traditionelle Ransomware-Ereignisse betreffen hauptsächlich Infrastrukturressourcen wie Server, Datenbanken und angeschlossene Dateisysteme. Es gibt jedoch auch nicht-traditionelle Ereignisse, mit denen Sie möglicherweise weniger vertraut sind, wie zum Beispiel Ransomware-Ereignisse, die auf in Amazon Simple Storage Service (Amazon S3) gespeicherte Daten abzielen. Es gibt wichtige Schritte, die Sie unternehmen können, um diese Ereignisse zu verhindern und mögliche Ransomware-Ereignisse frühzeitig zu erkennen, damit Sie Maßnahmen zur Wiederherstellung ergreifen können. Ziel dieses Beitrags ist es, Ihnen die AWS-Dienste und -Funktionen näherzubringen, die Sie zum Schutz vor Ransomware-Ereignissen in Ihrer Umgebung und zur Untersuchung möglicher Ransomware-Ereignisse einsetzen können, sollten diese eintreten.

Ransomware ist eine Art von Malware, die böswillige Akteure zur Erpressung von Geld von Unternehmen einsetzen können. Die Akteure können eine Reihe von Taktiken anwenden, um sich unbefugten Zugang zu den Daten und Systemen ihres Ziels zu verschaffen, einschließlich, aber nicht beschränkt auf die Ausnutzung nicht behobener Softwarefehler, den Missbrauch schwacher Anmeldedaten oder die vorherige unbeabsichtigte Offenlegung von Anmeldedaten sowie Social Engineering. Bei einem Ransomware-Ereignis wird der Zugriff eines legitimen Unternehmens auf seine Daten und Systeme von den böswilligen Akteuren eingeschränkt, und es wird eine Lösegeldforderung für die sichere Rückgabe dieser digitalen Assets gestellt. Es gibt mehrere Methoden, die Akteure verwenden, um den autorisierten Zugriff auf Ressourcen einzuschränken oder zu deaktivieren, darunter a) Verschlüsselung oder Löschung, b) Änderung von Zugriffskontrollen und c) netzwerkbasierte Denial-of-Service (DoS)-Angriffe. In einigen Fällen fordern böswillige Akteure, die eine Kopie der Daten besitzen, nach Wiederherstellung des Datenzugriffs des Ziels durch Bereitstellung des Verschlüsselungsschlüssels oder Rückübertragung der Daten ein zweites Lösegeld. Sie versprechen dann, die Daten nicht zu behalten, um sie zu verkaufen oder öffentlich freizugeben.

In den folgenden Abschnitten beschreiben wir mehrere wichtige Phasen Ihrer Reaktion auf ein Ransomware-Ereignis in Amazon S3, einschließlich Erkennung, Reaktion, Wiederherstellung und Schutz.

Beobachtbare Aktivität

Das häufigste Ereignis, das zu einem Ransomware-Ereignis führt, das auf Daten in Amazon S3 abzielt, wie vom AWS Customer Incident Response Team (CIRT) beobachtet, ist die unbeabsichtigte Offenlegung von Identity and Access Management (IAM) Zugangsschlüsseln. Eine weiterer wahrscheinlicher Auslöser ist, wenn es eine Anwendung mit einem Softwarefehler gibt, die auf einer Amazon Elastic Compute Cloud (Amazon EC2)-Instanz mit einem angehängten IAM-Instanzprofil und zugehörigen Berechtigungen gehostet wird. Die Instanz verwendet Instance Metadata Service Version 1 (IMDSv1). In diesem Fall könnte ein unbefugter Benutzer möglicherweise AWS Security Token Service (AWS STS) Sitzungsschlüssel aus dem IAM-Instanzprofil für Ihre EC2-Instanz verwenden, um Objekte in S3-Buckets zu bedrohen. In diesem Beitrag konzentrieren wir uns auf das häufigste Szenario, nämlich die unbeabsichtigte Offenlegung statischer IAM-Zugangsschlüssel.

Erkennung

Nachdem ein böswilliger Akteur Anmeldedaten erlangt hat, verwendet er AWS-API-Aktionen, die er durchläuft, um die Art des Zugriffs zu ermitteln, der dem exponierten IAM-Prinzipal gewährt wurde. Böswillige Akteure können dies auf verschiedene Weise tun, was zu unterschiedlichen Aktivitätsniveaus führen kann. Diese Aktivität könnte Ihre Sicherheitsteams alarmieren, da die Anzahl der API-Aufrufe, die zu Fehlern führen, zunimmt. In anderen Fällen, wenn das Ziel eines böswilligen Akteurs darin besteht, S3-Objekte zu bedrohen, werden die API-Aufrufe spezifisch für Amazon S3 sein. Wenn der Zugriff auf Amazon S3 über den exponierten IAM-Prinzipal erlaubt ist, können Sie möglicherweise eine Zunahme von API-Aktionen wie s3:ListBuckets, s3:GetBucketLocation, s3:GetBucketPolicy und s3:GetBucketAcl beobachten.

Analyse

In diesem Abschnitt beschreiben wir, wo Sie die Protokoll- und Metrikdaten finden, die Ihnen bei der detaillierteren Analyse dieser Art von Ransomware-Ereignis helfen.

Wenn ein Ransomware-Ereignis auf in Amazon S3 gespeicherte Daten abzielt, werden oft die in S3-Buckets gespeicherten Objekte gelöscht, ohne dass der böswillige Akteur Kopien erstellt. Dies ähnelt eher einem Datenvernichtungsereignis als einem Ransomware-Ereignis, bei dem Objekte verschlüsselt werden.

Es gibt mehrere Protokolle, die diese Aktivität erfassen. Sie können AWS CloudTrail-Ereignisprotokollierung für Amazon S3-Daten aktivieren, was Ihnen ermöglicht, die Aktivitätsprotokolle zu überprüfen, um Lese- und Löschaktionen zu verstehen, die für bestimmte Objekte durchgeführt wurden.

Wenn Sie zudem Amazon CloudWatch-Metriken für Amazon S3 vor dem Ransomware-Ereignis aktiviert haben, können Sie die Summe der BytesDownloaded-Metrik verwenden, um Einblicke in abnormale Übertragungsspitzen zu gewinnen.

Eine weitere Möglichkeit, Informationen zu gewinnen, besteht darin, die Metrik region-DataTransfer-Out-Bytes zu verwenden, die die Menge der von Amazon S3 ins Internet übertragenen Daten anzeigt. Diese Metrik ist standardmäßig aktiviert und ist mit Ihren AWS-Abrechnungs- und Nutzungsberichten für Amazon S3 verknüpft.

Weitere Informationen finden Sie im Incident Response Playbook: Ransom Response for S3[EXTERN,EN] des AWS CIRT-Teams sowie in den anderen öffentlich verfügbaren Reaktions-Frameworks im AWS customer playbooks[EXTERN,EN] GitHub-Repository.

Reaktion

Als Nächstes gehen wir durch, wie man auf die unbeabsichtigte Offenlegung von IAM-Zugangsschlüsseln reagiert. Je nach Geschäftsauswirkung können Sie sich entscheiden, einen zweiten Satz Zugangsschlüssel zu erstellen, um alle legitimen Verwendungen dieser Anmeldedaten zu ersetzen, damit legitime Systeme nicht unterbrochen werden, wenn Sie die kompromittierten Zugangsschlüssel deaktivieren. Sie können die Zugangsschlüssel über die IAM-Konsole oder durch Automatisierung deaktivieren, wie in Ihrem Vorfallreaktionsplan definiert. Sie müssen auch spezifische Details des Vorfalls in Ihrer sicheren und vertraulichen Incident-Response-Dokumentation festhalten, damit Sie später darauf zurückgreifen können. Wenn die Aktivität mit der Verwendung einer IAM-Rolle oder temporären Anmeldedaten zusammenhing, müssen Sie einen zusätzlichen Schritt unternehmen und alle aktiven Sitzungen widerrufen. Dazu wählen Sie in der IAM-Konsole die Schaltfläche Aktive Sitzung widerrufen, wodurch eine Richtlinie angehängt wird, die Benutzern, die die Rolle vor diesem Moment angenommen haben, den Zugriff verweigert. Im Anschluss können Sie die exponierten Zugangsschlüssel löschen.

Darüber hinaus können Sie das AWS CloudTrail-Dashboard und den Ereignisverlauf (der 90 Tage Protokolle enthält) verwenden, um die IAM-bezogenen Aktivitäten dieses kompromittierten IAM-Benutzers oder dieser Rolle zu überprüfen. Ihre Analyse kann potenziell dauerhaften Zugriff aufzeigen, der möglicherweise vom Angreifer erstellt wurde. Zusätzlich können Sie die IAM-Konsole verwenden, um den IAM-Anmeldeinformationsbericht (dieser Bericht wird alle 4 Stunden aktualisiert) einzusehen und Aktivitäten wie zuletzt verwendeter Zugriffsschlüssel, Zeitpunkt der Benutzererstellung und zuletzt verwendetes Passwort zu überprüfen. Alternativ können Sie Amazon Athena verwenden, um die CloudTrail-Protokolle abzufragen. Sehen Sie sich das folgende Beispiel einer Athena-Abfrage an, welche eine Amazon-Ressourcennummer (ARN) eines IAM-Benutzers verwendet, um Aktivitäten für einen bestimmten Zeitraum anzuzeigen:

SELECT eventtime, eventname, awsregion, sourceipaddress, useragentFROM cloudtrailWHERE useridentity.arn = 'arn:aws:iam::1234567890:user/Name' AND-- Enter timeframe(event_date >= '2022/08/04' AND event_date <= '2022/11/04')ORDER BY eventtime ASC
Plain text

Wiederherstellung

Nachdem Sie dem Angreifer den Zugriff entzogen haben, haben Sie mehrere Möglichkeiten zur Datenwiederherstellung, die wir in den folgenden Abschnitten besprechen. Beachten Sie, dass es derzeit keine Wiederherstellungsfunktion für Amazon S3 gibt und AWS nicht in der Lage ist, Daten nach einem Löschvorgang wiederherzustellen. Darüber hinaus erfordern viele der Wiederherstellungsoptionen eine Konfiguration bei der Bucket-Erstellung.

S3-Versionierung

Die Verwendung der Versionierung in S3-Buckets ist eine Möglichkeit, mehrere Versionen eines Objekts im selben Bucket zu speichern, was Ihnen die Möglichkeit gibt, während des Wiederherstellungsprozesses eine bestimmte Version wiederherzustellen. Sie können die S3-Versionierung verwenden, um jede Version jedes in Ihren Buckets gespeicherten Objekts zu erhalten, abzurufen und wiederherzustellen. Mit der Versionierung können Sie sich leichter von unbeabsichtigten Benutzeraktionen und Anwendungs-Fehlfunktionen erholen. Versionierte Buckets können Ihnen helfen, Objekte vor versehentlichem Löschen oder Überschreiben zu schützen. Wenn Sie beispielsweise ein Objekt löschen, fügt Amazon S3 eine Löschmarkierung ein, anstatt das Objekt dauerhaft zu entfernen. Die vorherige Version bleibt im Bucket und wird zu einer nicht aktuellen Version. Sie können die vorherige Version wiederherstellen. Die Versionierung ist standardmäßig nicht aktiviert und verursacht zusätzliche Kosten, da Sie mehrere Kopien desselben Objekts aufbewahren. Weitere Informationen zu den Kosten finden Sie auf der Seite Amazon S3-Preise.

AWS Backup

Die Verwendung von AWS Backup gibt Ihnen die Möglichkeit, separate Kopien Ihrer S3-Daten unter separaten Zugriffsberechtigungen zu erstellen und zu verwalten, die zur Wiederherstellung von Daten während eines Wiederherstellungsprozesses verwendet werden können. AWS Backup bietet eine zentralisierte Sicherung für mehrere AWS-Dienste, sodass Sie Ihre Sicherungen an einem Ort verwalten können. AWS Backup für Amazon S3 bietet Ihnen zwei Optionen: kontinuierliche Sicherungen, die es Ihnen ermöglichen, zu jedem beliebigen Zeitpunkt innerhalb der letzten 35 Tage wiederherzustellen; und periodische Sicherungen, die es Ihnen ermöglichen, Daten für eine bestimmte Dauer, einschließlich unbegrenzt, aufzubewahren. Weitere Informationen finden Sie unter Verwendung von AWS Backup für Amazon S3.

Schutz

In diesem Abschnitt beschreiben wir einige der präventiven Sicherheitskontrollen, die in AWS verfügbar sind.

S3 Object Lock

Sie können eine zusätzliche Schutzebene gegen Objektänderungen und -löschungen hinzufügen, indem Sie S3 Object Lock für Ihre S3-Buckets aktivieren. Mit S3 Object Lock können Sie Objekte mithilfe eines Write-Once-Read-Many (WORM)-Modells speichern und verhindern, dass Objekte für einen festgelegten Zeitraum oder auf unbestimmte Zeit gelöscht oder überschrieben werden.

AWS Backup Vault Lock

Ähnlich wie S3 Object Lock, das zusätzlichen Schutz für S3-Objekte bietet, können Sie, wenn Sie AWS Backup verwenden, die Aktivierung von AWS Backup Vault Lock in Betracht ziehen, das die gleiche WORM-Einstellung für alle Sicherungen erzwingt, die Sie in einem Backup-Vault speichern und erstellen. AWS Backup Vault Lock hilft Ihnen, versehentliche oder böswillige Löschvorgänge durch den AWS-Konto-Root-Benutzer zu verhindern.

Amazon S3 Inventory

Um sicherzustellen, dass Ihre Organisation die Sensibilität der in Amazon S3 gespeicherten Objekte versteht, sollten Sie Ihre kritischsten und sensiblesten Daten in Amazon S3 inventarisieren und sicherstellen, dass die entsprechende Bucket-Konfiguration vorhanden ist, um Ihre Daten zu schützen und deren Wiederherstellung zu ermöglichen. Sie können Amazon S3 Inventory verwenden, um zu verstehen, welche Objekte sich in Ihren S3-Buckets befinden und welche bestehenden Konfigurationen, einschließlich Verschlüsselungsstatus, Replikationsstatus und Object Lock-Informationen, vorhanden sind. Sie können Ressourcen-Tags verwenden, um die Klassifizierung und den Besitzer der Objekte in Amazon S3 zu kennzeichnen und automatisierte Aktionen durchzuführen sowie Kontrollen anzuwenden, die der Sensibilität der in einem bestimmten S3-Bucket gespeicherten Objekte entsprechen.

MFA-Löschung

Eine weitere präventive Kontrolle, die Sie verwenden können, ist die Durchsetzung der Multi-Faktor-Authentifizierung (MFA) Löschung in S3 Versionierung. MFA-Löschung bietet zusätzliche Sicherheit und kann versehentliche Bucket-Löschungen verhindern, indem der Benutzer, der die Löschaktion initiiert, den physischen oder virtuellen Besitz eines MFA-Geräts mit einem MFA-Code nachweisen muss. Dies fügt der Löschaktion eine zusätzliche Sicherheitsebene hinzu.

Verwendung von IAM-Rollen für kurzfristige Anmeldeinformationen

Da viele Ransomware-Ereignisse durch unbeabsichtigte Offenlegung statischer IAM-Zugriffsschlüssel entstehen, empfiehlt AWS die Verwendung von IAM-Rollen, die kurzfristige Anmeldeinformationen bereitstellen, anstatt langfristige IAM-Zugriffsschlüssel zu verwenden. Dazu gehört die Verwendung von Identitätsföderation für Ihre Entwickler, die auf AWS zugreifen, die Verwendung von IAM-Rollen für System-zu-System-Zugriff und die Verwendung von IAM Roles Anywhere für Hybrid-Zugriff. Für die meisten Anwendungsfälle sollten Sie keine statischen Schlüssel oder langfristigen Zugriffsschlüssel verwenden. Jetzt ist ein guter Zeitpunkt, um die Verwendung dieser Arten von Schlüsseln in Ihrer Umgebung zu überprüfen und zu eliminieren. Erwägen Sie die folgenden Schritte:

  1. Erstellen Sie ein Inventar über alle Ihre AWS-Konten und identifizieren Sie den IAM-Benutzer, wann die Anmeldeinformationen zuletzt rotiert und verwendet wurden und welche Richtlinie angehängt ist.
  2. Deaktivieren und löschen Sie alle Root-Zugriffsschlüssel des AWS-Kontos.
  3. Rotieren Sie die Anmeldeinformationen und wenden Sie MFA auf den Benutzer an.
  4. Gestalten Sie die Architektur neu, um temporären rollenbasierten Zugriff zu nutzen, wie IAM-Rollen oder IAM Roles Anywhere.
  5. Überprüfen Sie angehängte Richtlinien, um sicherzustellen, dass Sie den Zugriff mit den geringsten Privilegien durchsetzen, einschließlich der Entfernung von Platzhaltern aus der Richtlinie.

Serverseitige Verschlüsselung mit kundenverwalteten KMS-Schlüsseln

Ein weiterer Schutz, den Sie verwenden können, ist die Implementierung der serverseitigen Verschlüsselung mit AWS Key Management Service (SSE-KMS) und die Verwendung von kundenverwalteten Schlüsseln zur Verschlüsselung Ihrer S3-Objekte. Die Verwendung eines kundenverwalteten Schlüssels erfordert, dass Sie eine spezifische Schlüsselrichtlinie anwenden, die festlegt, wer die Daten in Ihrem Bucket verschlüsseln und entschlüsseln darf, was einen zusätzlichen Zugriffssteuerungsmechanismus zum Schutz Ihrer Daten bietet. Sie können AWS KMS-Schlüssel auch zentral verwalten und deren Verwendung mit einem Prüfprotokoll überwachen, das anzeigt, wann und von wem der Schlüssel verwendet wurde.

GuardDuty-Schutzmaßnahmen für Amazon S3

Sie können den Amazon S3-Schutz in Amazon GuardDuty aktivieren. Mit dem S3-Schutz überwacht GuardDuty API-Operationen auf Objektebene, um potenzielle Sicherheitsrisiken für Daten in Ihren S3-Buckets zu identifizieren. Dies umfasst Erkenntnisse zu anomaler API-Aktivität und ungewöhnlichem Verhalten im Zusammenhang mit Ihren Daten in Amazon S3 und kann Ihnen helfen, ein Sicherheitsereignis frühzeitig zu erkennen.

Fazit

In diesem Beitrag haben Sie etwas über Ransomware-Ereignisse gelernt, die auf in Amazon S3 gespeicherte Daten abzielen. Durch proaktive Maßnahmen können Sie potenzielle Ransomware-Ereignisse schnell identifizieren und zusätzliche Schutzmaßnahmen einrichten, um das Risiko dieser Art von Sicherheitsereignissen in Zukunft zu reduzieren.

Wenn Sie Fragen zu diesem Beitrag haben, starten Sie einen neuen Thread im Security, Identity and Compliance re:Post[EN] oder kontaktieren Sie den AWS Support.

Möchten Sie mehr AWS Security-Neuigkeiten? Folgen Sie uns auf Twitter.

Über die Autor:innen

Megan O’Neil ist Principal Specialist Solutions Architect mit Schwerpunkt auf Bedrohungserkennung und Vorfallreaktion. Megan und ihr Team ermöglichen es AWS-Kunden, hochentwickelte, skalierbare und sichere Lösungen zu implementieren, die ihre geschäftlichen Herausforderungen lösen.
Karthik Ram ist Senior Solutions Architect bei Amazon Web Services mit Sitz in Columbus, Ohio. Er verfügt über einen Hintergrund in IT-Netzwerken, Infrastrukturarchitektur und Sicherheit. Bei AWS hilft Karthik Kunden, sichere und innovative Cloud-Lösungen zu entwickeln und ihre Geschäftsprobleme mithilfe datengesteuerter Ansätze zu lösen. Karthiks Spezialgebiet ist Cloud-Sicherheit mit Schwerpunkt auf Bedrohungserkennung und Vorfallreaktion (TDIR).
Kyle Dickinson ist Senior Security Solution Architect, spezialisiert auf Bedrohungserkennung und Vorfallreaktion. Er konzentriert sich darauf, mit Kunden zusammenzuarbeiten, um auf Sicherheitsereignisse mit Zuversicht zu reagieren. Er moderiert auch AWS on Air: Lockdown, eine Live-Stream-Sicherheitsshow. In seiner Freizeit genießt er Hockey, BBQ und versucht, seinen Shitzu davon zu überzeugen, dass er tatsächlich kein großer Hund ist.