Letzten Februar wurden Tausende von ESXi-Servern von einem neuen Ransomware-Angriff („ESXiARGS“) betroffen, der die Server über eine Sicherheitslücke (CVE-2021-21972, CVE-2021-21973 und CVE-2021-21974) angriff, welche durch einen Pufferüberlauf im OpenSLP-Dienst verursacht wurde. Bei den betroffenen Systemen handelt es sich offenbar um ESXi-Hypervisoren in der Version 6.x und vor 6.7.
In diesem Artikel zeigen wir die Schritte zur Wiederherstellung von VMs, die KEINE Snapshots (-delta
oder -sesparse
Dateien) haben, sondern nur eine flat
VMDK-Datei. Zum jetzigen Zeitpunkt scheint es noch kein erfolgreiches Verfahren zu geben, mit dem alle VMs oder deren Daten wiederhergestellt werden können, wenn diese Snapshot-Dateien (-delta
) hatten. Einige Leute scheinen es geschafft zu haben, VMs wiederherzustellen, die -sesparse
Snapshots hatten.
Ich gehe davon aus, dass du den Angriff bereits gestoppt hast und die Kontrolle über deinen ESXi-Hypervisor wiedererlangt hast, und konzentriere mich nur auf die Wiederherstellung der virtuellen Maschinen.
Grundvoraussetzungen
Backup
Als allererstes solltest du ein Backup der VM-Dateien erstellen:
- Entweder du erstellst eine Kopie des Ordners der VM, oder
- du erstellst einen Backup-Ordner innerhalb des VM-Ordners und kopierst alle Dateien darin.
Unnötige Dateien löschen
Die folgenden Dateien sind für diesen Prozess nicht notwendig und können sicher gelöscht werden. Für den Fall der Fälle solltest du trotzdem eine Kopie aller Dateien in dem Backup haben, das du bereits gemacht hast.
- .args
- .vmxf
- .vmsd
- .vmsn
- .vmem
- .nvram
- .vmx – wird aus der
.vmx~
Datei wiederherstellt.
Du kannst diese entfernen und die vmx
Datei mit dem folgenden Befehl wiederherstellen:
[root@esxihost:]$ mv VMNAME.vmx~ VMNAME.vmx [root@esxihost:]$ rm *.args *.vmfx *.vmsd *.vmsn *.vmem *.nvram
Der Ordner sollte jetzt ein bisschen sauberer aussehen.
ESXiArgs – VM-Wiederherstellung
Erstelle eine neue VMDK-Datei
- Notiere dir die Originalgröße der
-flat
Datei mit dem Befehlls -la
:
[root@esxihost:]$ ls -la total 92925984 drwxr-xr-x 1 root root 1120 Feb 26 18:01 . drwxr-xr-t 1 root root 2100 Feb 4 15:56 .. drwxr-xr-x 1 root root 3500 Feb 20 16:31 BKUP -rw------- 1 root root 107374182912 Feb 3 10:18 VMNAME-flat.vmdk -rw------- 1 root root 1045 Feb 3 10:18 VMNAME.vmdk -rwx------ 1 root root 3449 Dec 5 17:12 VMNAME.vmx
- Lösche die existierende .
vmdk
Datei, mit dem Befehlrm -rf xxx.vmdk
:
[root@esxihost:]$ rm VMNAME.vmdk
- Erstelle eine neue „temp“ Festplatte (
-flat.vmdk
und.vmdk
) mitvmkfstools
. Achte darauf, dass die Größe, die du angibst, exakt die Größe der ursprünglichen-flat
Datei ist, die du mitls -la
aufgeschrieben hast:
[root@esxihost:]$ vmkfstools -c 107374182912 -d thin temp.vmdk Create: 100% done.
- Es sollten nun zwei neue Dateien entstehen, eine
temp-flat.vmdk
Datei und eine temp.vmdk Datei. Die ursprüngliche und die neue-flat.vmdk
Datei sollten genau die gleiche Größe haben. - Bearbeite die
temp.vmdk
Datei:- Ersetze in Zeile 9
temp-flat.vmdk
durch den Namen der ursprünglichen-flat
Datei und - Wenn deine Festplatte NICHT Thin Provisioned war, entferne die Zeile 19
ddb.thinProvisioned
oder kommentiere sie aus. Wenn sie Thin-Provisioned war, lass die Zeile so wie sie ist. - Speicher die Datei.
- Ersetze in Zeile 9
# Disk DescriptorFile version=1 encoding="UTF-8" CID=fffffffe parentCID=ffffffff createType="vmfs" # Extent description RW 209715201 VMFS "WebServer_2-flat.vmdk" # The Disk Data Base #DDB ddb.adapterType = "lsilogic" ddb.geometry.cylinders = "13054" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.longContentID = "cf65c0c190124ab5571025d1fffffffe" #ddb.thinProvisioned = "1" ddb.uuid = "60 00 C2 94 74 7b 9f 6f-36 7e b3 ce d1 90 72 2f" ddb.virtualHWVersion = "14"
Jetzt solltest du so etwas Ähnliches wie das hier haben:
[root@esxihost:]$ ls -la total 92925984 drwxr-xr-x 1 root root 1120 Feb 26 18:01 . drwxr-xr-t 1 root root 2100 Feb 4 15:56 .. drwxr-xr-x 1 root root 3500 Feb 20 16:31 BKUP -rw------- 1 root root 107374182912 Feb 3 10:18 VMNAME-flat.vmdk (ORIGINAL) -rw------- 1 root root 1045 Feb 3 10:18 VMNAME.vmdk (Recreated & Edited) -rwx------ 1 root root 3449 Dec 5 17:12 VMNAME.vmx (Recovered from .vmx~)
Jetzt wollen wir diese .vmdk
und -flat.vmdk
Dateien mit einer VM testen. Dazu musst du Folgendes tun:
Erstelle eine neue VM
- Erstelle einen neuen VM-Ordner (außerhalb des ursprünglichen VM-Ordners) mit dem Namen „Test“.
- Du kannst dies entweder über die Shell (SSH) oder den Datastore Browser tun.
- Kopiere die folgenden Dateien in diesen Ordner:
VMNAME.vmdk
VMNAME-flat.vmdk
- Erstelle eine neue VM über die grafische Benutzeroberfläche:
- Gleiche oder ähnliche CPU und RAM (ich glaube nicht, dass es einen großen Unterschied macht).
- Entferne die Standardfestplatte und füge eine neue Festplatte hinzu, indem du
Existing hard disk
auswählst. Navigiere dann zu dem zuvor erstellten „Test“-Ordner und wähle die.vmdk
Datei darin aus. - Unter “ CD/DVD Drive 1″ wählst du Datastore ISO File und wählst eine Linux Live CD aus. In meinem Fall benutzte ich Kali Linux Live CD, was funktioniert hat. Vergewissere dich, dass “ Connect at power on“ ausgewählt ist.
- Starte die VM.
Partition mit Testdisk wiederherstellen
- Starte die Live-CD – in meinem Fall mit grafischer Oberfläche – um zu versuchen, deine Partition wiederherzustellen und Grub neu zu installieren. Diese Schritte können je nachdem, welche Partitionen du auf deiner VM hattest, variieren.
- Öffne ein Terminal und rufe
testdisk
auf, um deine Partitionstabelle wiederherzustellen. Ich bin dieser Anleitung gefolgt, um meineLinux
-Partition wiederherzustellen. NICHT NEU STARTEN, wie in dieser Anleitung angegeben wird.- Installiere
testdisk
, falls es noch nicht installiert ist (es ist standardmäßig in Kali Linux enthalten). - Rufe
testdisk
auf. - Wähle die
No Log
Option und fahre fort. - Markiere die VM-Festplatte (normalerweise
/dev/sda
) und fahre fort. - Wähle den Partitionstyp (
Intel/PC
). - Wähle
Analyse
und drücke die Enter-Taste. - Wähle
Quick Search
und drück die Enter-Taste. - Markiere deine Partition, falls sie gefunden wurde (in meinem Fall
Linux
– je nach Betriebssystem/Setup kann sie anders heißen), und drück die Enter-Taste. - Wenn die Partitionstabelle korrekt aussieht, wähle die
Write
-Option und bestätige sie im nächsten Schritt mit derY
-Taste. - Wenn du fertig bist, beende testdisk mit
Quit
. - Überprüfe mit
fdisk -l
deine Festplatte und Partition. - NICHT NEU STARTEN.
- Installiere
GRUB neu installieren
- Installiere Grub mit den folgenden Befehlen neu:
root@kali-live:~# mount /dev/sda1 /mnt root@kali-live:~# mount --bind /dev /mnt/dev root@kali-live:~# mount --bind /dev/pts /mnt/dev/pts root@kali-live:~# mount --bind /proc /mnt/proc root@kali-live:~# mount --bind /sys /mnt/sys root@kali-live:~# chroot /mnt /bin/bash root@kali-live:~# grub-install /dev/sda
- Beende die
chroot
-Umgebung und starte die VM neu.
Starte die VM
Das Betriebssystem der VM sollte von der -flat.vmdk
Datei starten. Du solltest in der Lage sein, dich einzuloggen und die Dateistruktur zu durchsuchen.
Wenn das funktioniert hat, sollten die Base VMDK und die Flat-Datei in Ordnung sein! ✅ ?
Hoffentlich gelingt es jemandem, eine Möglichkeit zu finden, virtuelle Maschinen mit Snapshots wiederherzustellen. Sollte das geschehen, schreibe ich darüber!
Zusätzliche Informationen/Quellen
Die folgenden Links enthalten nützliche Links für zusätzliche Information: