AWS Ransomware – und was wirklich dahinter steckt

Kürzlich meldete sich ein Kunde beim Computer Security Incident Response Team (CSIRT) der InfoGuard und berichtete, dass ein Angreifer mehrere AWS S3 Buckets gelöscht hatte. Anschliessend hinterliess der Angreifer eine Lösegeldforderung. In diesem Beitrag, welcher auf dem Original vom dfir.ch-Blog basiert, untersuchen wir eine Recovery-Binärdatei im Detail, die der Angreifer nach dem Löschen der Buckets hinterlassen hatte. Ebenso erklärt Ihnen unser Head of Investigations, Stephan Berger, weshalb die Binärdatei nur ein Ablenkungsmanöver ist, um den Druck auf das Opfer zu erhöhen. Doch erst der Reihe nach.

Die Vorgeschichte: Die Meldung erreichte uns, dass der Angreifer mehrere AWS S3 Buckets gelöscht hatte, bevor er angeblich die Daten heruntergeladen hat. Die Original-Lösegeldforderung lautete wie folgt (sensible Informationen haben wir selbstverständlich unkenntlich gemacht):

Eine andere Version dieser Lösegeldforderung, bei der die Wiederherstellungskomponente fehlte, wurde auf VirusTotal hochgeladen. Sie wurde ursprünglich am 29. Januar 2024 von Frankreich aus hochgeladen, was ungefähr im selben Zeitraum liegt wie unser untersuchter Vorfall.

Rückverfolgung des Angriffes und Aufklärung

Wir haben die ersten Aktionen des Angreifers bis zum 18. Januar 2024 zurückverfolgt, als er zwei Standard-Reconnaissance Befehle gegen die AWS Simple Email Solution (SES) und den Amazon Simple Storage Service (S3) ausführte:

• GetSendQuota
• ListBuckets

Invictus-IR hat eine CSV-Datei mit interessanten CloudTrail-Ereignissen aus einem anderen Ransomware-Vorfall in der Cloud erstellt. «Defenders», sprich Verteidiger, und SOC-Mitarbeitenden wird dringend empfohlen, ihre Sicherheitsüberwachung auf diese Ereignisnamen zu überprüfen, da diese Ereignisse darauf hindeuten könnten, dass ein Angreifer Zugriff auf einen AWS-Endpunkt hat.

Abbildung 1: Wichtige CloudTrail-Ereignisprotokolle

Löschung von Buckets

Am 5. Februar löschte der Angreifer alle Buckets mit dem Befehl DeleteBucket und hinterliess die oben genannte Lösegeldforderung. Vor dem Löschen der Buckets wurden folgende Befehle in den CloudTrail-Logs aufgezeichnet:

• GetBucketVersioning (siehe Abbildung 1 – die Versionierung war nicht aktiviert)
• GetBucketReplication
• GetBucketObjectLockCon guration
• GetBucketLogging
• GetBucketRequestPayment
• GetAccelerateCon guration

Sie nennen es Wiederherstellung – wir nennen es Betrug

In der Lösegeldforderung werden die folgenden drei Linux-Befehle erwähnt:

• tar xzvf recoveryBYESZ2ESTHWPWHDRAXZ7.tgz
• chmod +x recovery
• ./recovery

Der Angreifer hat dieses Archiv (recoveryBYESZ2ESTHWPWHDRAXZ7.tgz) in demselben Ordner abgelegt wie die Lösegeldforderung, einschliesslich einer Textdatei namens aws.txt. Das gesamte Archiv enthält zahlreiche individuelle Ordner mit Linux-Bibliotheken, C-Quellcode-Dateien, Python-Dateien usw., um die Grösse des Archivs zu erhöhen und dem Archiv einen «seriöseren» Anstrich zu geben.

Wenn wir uns nur auf den Wiederherstellungsteil, sprich nur aufs Recovery, konzentrieren, lesen wir folgende Aussage in der Lösegeldforderung:

Sie müssen bei AWS-cli authentifiziert sein, um die Wiederherstellung ausführen zu können -> AWS konfigurieren und authentifizieren, wenn Sie es noch nicht sind! Ab dem Start der Wiederherstellung müssen Sie sicherstellen, dass Ihre Verbindung nicht unterbrochen wird und Ihr Computer nicht abstürzt.

In der Original-Sprache:

You need to be authenticated into aws-cli with credentials to perform restore run -> aws configure and authenticate if you are not already ! Once the recovery starts, you need to be sure your connection does not drop, your computer does not crash.

Analyse des Binärcodes

Die Recovery-Binärdatei (einfach Recovery genannt, siehe oben) wurde ursprünglich am 2. Februar 2024 auf VirusTotal hochgeladen. Nach dem Start der Recovery-Binärdatei werden wir aufgefordert, den AWS-Schlüssel einzugeben. Anschliessend informiert uns die Binärdatei, dass es die Kontoinformationen überprüft und dann Details dazu ausgibt.

Nach Eingabe des AWS-Schlüssels zeigt die Binärdatei an, dass sie etwas überprüft. Laut Strace-Ausgabe (siehe Artikel über die Verwendung von Strace zur Analyse von Linux-Malware) geht der Code jedoch einfach fünf Sekunden lang in einen Schlafmodus (die Zahl 5 wurde als Argument an den Syscall clock_nanosleep übergeben)

Bei näherer Betrachtung dieses Verhaltens entdecken wir einen Aufruf der Funktion sleepRandom(), die die Binärdatei für eine zufällige Zeitdauer schlummern lässt. Dies stimmt mit dem Verhalten in der Strace-Ausgabe überein.

Abbildung 2: Willkommen bei AWS Recovery

Die Funktion sleepRandom() nutzt im Hintergrund die Funktion sleep():

Abbildung 3: Funktion sleepRandom()

Die oben genannten Kontoinformationen wurden aus der Datei aws.txt extrahiert, die zusammen mit der Wiederherstellungs-Binärdatei im Wiederherstellungspaket enthalten war. Nachfolgend eine Beispieldatei:

Hier ist ein Ausschnitt aus der strace-Ausgabe, der das Lesen der Datei aws.txt zeigt (openat() gefolgt von read()):

Die Binärdatei erstellt ein neues Verzeichnis (mkdir) und legt darin Dateien mit zufälligen Namen ab. Der Syscall openat() wird erneut verwendet, aber dieses Mal wird der Funktion im Gegensatz zu oben der Parameter O_CREAT übergeben – Wenn der Pfadname nicht existiert, als reguläre Datei erstellen.

Wenn wir uns die Binärdatei in Ghidra noch einmal ansehen, stellen wir fest, dass die folgenden beiden Funktionen für die Erstellung von Dateien und Ordnern zuständig sind:

• createFoldersFromFile();
• displayFileInfo();

Um die Ordner zu erstellen, liest die Binärdatei die Bucket-Namen aus der Datei aws.txt und erstellt für jeden Bucket einen Ordner.

Abbildung 4: createFoldersFromFile()

Die Gesamtzahl der Dateien und die Gesamtgrösse der Dateien werden ausschliesslich anhand der Informationen in der Datei aws.txt berechnet – das Binärprogramm stellt keine Verbindung zum Internet oder zu AWS her.

Abbildung 5: displayFileInfo()

Ähnlich wie bei der Überprüfung des AWS-Zugangsschlüssels ist der Download-Vorgang ein Ablenkungsmanöver, wie das strace-Protokoll beweist:

Während der Ausführung der Binärdatei zeigt das Terminal nach der Meldung «wird heruntergeladen» die Meldung «Download angehalten – bitte zahlen» an. Die Untersuchung der Download-Funktionalität der Binärdatei ergab, dass keine Zeile des Codes eine Netzwerkverbindung initiiert, um Schlüssel, Buckets oder Zugriffsrechte zu überprüfen.

Abbildung 6: Der Download wurde angehalten

Die Meldung «Download angehalten» ist ein weiteres Ablenkungsmanöver, um das Opfer zur Zahlung des Lösegelds zu bewegen. Der Benutzer wird aufgefordert, die Transaktions-ID/den Hash des gezahlten Lösegelds einzugeben, aber auch hier macht das Programm nichts mit den eingegebenen Informationen, ausser den Druck auf das Opfer zu erhöhen.

Schliesslich wird der «Download» der Daten fortgesetzt, wobei dem Benutzer die verbleibende Zeit bis zum Abschluss angezeigt wird.

Abbildung 7: Transaktions-ID/Hash

Die Untersuchung der Binärdatei zeigt, dass hinter den Kulissen nichts überprüft, keine Domain kontaktiert und keine Netzwerkverbindung aufgebaut wird.

Abbildung 8: Zeit bis zum Abschluss der Wiederherstellung

ELF DIGEST, der Non-Profit-Analysedienst für Linux-Malware, findet ebenfalls keine Spuren von Netzwerkverbindungen. Hier der Bericht, aus dem der Screenshot stammt (Hinweis: es erfordert einen Benutzernamen).

Abbildung 9: Bericht von ELF Digest

Unser Fazit 

Die Analyse des Netzwerkverkehrs ergab, dass die Angreifer höchstwahrscheinlich nur 2 GB an Daten gestohlen haben, verglichen mit den über 1 TB an Daten, die auf dem Bucket  lagen. Eine Wiederherstellung wäre also ohnehin nicht möglich gewesen. Die ganze «Recovery»-Binärdatei ist nur ein raffinierter Trick der Angreifer, um die Opfer zur Zahlung des Lösegelds zu bewegen. Die Analyse mit einem dynamischen Ansatz (Strace) und einem statischen Ansatz (Ghidra) erwies sich als erfolgreich und ermöglichte es uns, die Binärdatei schnell zu verstehen.

Mehr über unsere Cyber Defence Services – von Security Operations und Hunting & Intelligence über Managed Detection & Response (MDR) bis hin zu Incident Response & Forensics – erfahren Sie auf unserer Webseite:

Vorsorge ist besser als Nachsorge: Dank unserem Incident Response Retainer sind Sie perfekt auf einen allfälligen Security Incident vorbereitet. Schnell, effizient und wirkungsvoll. Wir freuen uns auf einen unverbindlichen Austausch dazu mit Ihnen.