Wmware Veri Kurtarma ve İlk Müdahale

Merhaba arkadaşlar,

Bugün sabah birçok vmware sunucusunda yaşanan sorunla alakalı genel bi bilgilendirme yapmak istedim. Sektörde geçmiştede yaşadığımız tecrübeler neticesinde aşağıdaki yol haritasını uygulayarak verilerinizi büyük oranda kurtarabilirsiniz.

Şuanda aktif olarak bir firmanın verilerini %90 oranda kurtardık ancak tek başıma herkese destek olamayacağım için nasıl yaptığımız aşağıda anlatıyorum.

Profesyonel destek almak isteyenler ulaşabilir yardımcı olmaya çalışırım. Aşağıya temizlik için örnek bir .py kodum kontrol edip çalıştırabilirsiniz.

https://drive.google.com/file/d/1LIS...ew?usp=sharing bu linkteki script benzeri bir script ile sunucu içerisinde temizlik yapın.

Panikle yapılan hatalar kurtarma şansını yok ediyor. Sırasıyla:

Ödeme yapmayın, saldırganla iletişime geçmeyin (en azından hukuki danışman devreye girmeden)
Datastore'a hiçbir şey yazmayın. Yeni VM oluşturma, dosya kopyalama, log yazma - hepsi kurtarılabilir alanın üstüne biner
Dosyaları rename etmeyin. .babyk uzantısını silmek hiçbir şeyi çözmez
Hâlâ çalışan VM varsa kapatmayın. İçindeki veriyi guest'ten dışarı kopyalamak mümkün olabilir; kapattığınız anda o şans biter
Host'u yeniden başlatmayın. Bellekte kalan bilgiler kaybolur

Bu kısım kritik: şifreleme bitmiş olsa bile saldırının altyapısı hâlâ çalışıyor olabilir.

Bizde /var/run/run.sh adında bir script vardı ve cron'a bağlanmıştı:

*/10 * * * * /bin/sh /var/run/run.sh >/dev/null 2>&1

Yani her 10 dakikada bir tetikleniyordu. Kontrol ettiğimizde dört kopya aynı anda çalışıyordu, hepsi sleep aşamasında bekliyordu.

Script'in yaptıkları:

esxcli system settings advanced set -o /User/execInstalledOnly -i 0 - ESXi'ın imzasız binary çalıştırma korumasını kapatıyor
/var/run/backup adlı binary'yi (asıl şifreleyici, "backup" adı verilmiş) çalıştırılabilir yapıyor
Tüm VM'leri zorla öldürüyor (vCenter hariç - onu ayakta tutuyor ki kurban durumu görebilsin)
Şifreleyiciyi /vmfs/volumes/ üzerine salıyor
esxcli system welcomemsg set ile giriş banner'ını fidye notuyla değiştiriyor
esxcli software vib remove -n vmware-fdm ile HA'yı devre dışı bırakıyor
Döngü halinde tekrar tekrar VM öldürüp şifreliyor

Bunları temizlemeden hiçbir kurtarma işlemine başlamayın. Aksi halde kurtardığınız veri ikinci kez şifrelenir.

Kurtarma stratejisi:

Şifreleyici hız için diski blok blok atlayarak şifreliyor. Ne kadarının vurulduğunu ölçmek için entropi analizi yaptım - dosyayı belirli aralıklarla örnekleyip Shannon entropisi hesaplayan basit bir Python scripti yeterli.

Bizim sonuçlarımız

Farklı VM'lerde şifreli oran:

VM Boyut Şifreli
A 160 GB %1.7
B 50 GB %3.2
C 100 GB %5.7
D 40 GB %6.2
E 250 GB %12.9

AG kontrolü nasıl yapılır

Önce ilk iki XFS superblock'un offsetini bulun (magic: XFSB, sektör hizalı). Aralarındaki fark AG boyutudur. Sonra basit bir döngüyle hepsini kontrol edin:

python
base = ILK_XFS_OFFSET
agsz = IKINCI_OFFSET - ILK_OFFSET
agn = AG_SAYISI # superblock'tan okunur

f = open(imaj, 'rb')
ok = 0
for n in range(agn):
f.seek(base + n * agsz)
if f.read(4) == b'XFSB':
ok += 1
print(f'Saglam: {ok}/{agn}')

Kabaca %70'i sağlamsa xfs_repair işi görür.

İmajı çıkarma

ESXi'da kurtarma araçları yok. Ham imajı bir Linux makineye almak gerekiyor:


ssh -C root@ESXI_IP "cat '/vmfs/volumes/DATASTORE/VM/VM-flat.vmdk.babyk'" > vm.raw

Not: ESXi'ın SSH'ında PasswordAuthentication no varsayılan geliyor ve eski sshd sürümü ed25519 anahtarlarını tanımıyor. RSA kullanın:


ssh-keygen -t rsa -b 4096
# public key'i ESXi'da /etc/ssh/keys-root/authorized_keys içine tek satır olarak yazın

Babuk footer'ını kırpın

truncate -s GERCEK_BOYUT vm.raw # sondaki 32 baytı at
Orijinale yazmadan çalışın

xfs_repair yıkıcı bir işlem. Device-mapper snapshot ile koruma katmanı kurun:

LOOP=$(losetup -r -f --show vm.raw)
truncate -s 40G cow.img
COW=$(losetup -f --show cow.img)
SZ=$(blockdev --getsz $LOOP)
echo "0 $SZ snapshot $LOOP $COW P 8" | dmsetup create rec

Artık /dev/mapper/rec yazılabilir, vm.raw dokunulmaz. Ters giderse:

dmsetup remove rec && rm cow.img

Bölüm tablosunu geri getirin

gdisk /dev/mapper/rec
# r → recovery menüsü
# b → yedek GPT'yi birincil yap
# w → yaz
LVM ve dosya sistemi

kpartx -av /dev/mapper/rec
pvscan --cache && vgscan && vgchange -ay
lvs

xfs_repair -n /dev/VG/root 2>&1 | tee repair_dry.log # önce kuru
xfs_repair -L /dev/VG/root 2>&1 | tee repair.log # sonra gerçek

mkdir -p /mnt/rec
mount -o ro,norecovery /dev/VG/root /mnt/rec

repair_dry.log dosyasını saklayın - hangi inode'ların bozuk olduğunu listeler, yani "hangi dosyalar gitti" listesi odur.

Veriyi çıkarın

rsync -av --info=progress2 /mnt/rec/home/ /kurtarilan/home/
rsync -av --info=progress2 /mnt/rec/var/lib/mysql/ /kurtarilan/mysql/
rsync -av --info=progress2 /mnt/rec/etc/ /kurtarilan/etc/

Okuma hatası veren dosyalar şifreli bloklara denk gelenlerdir.

Umarım herkes olabildiğince az zarar ile atlatır. Geçmiş olsun dileklerimle..

Hocam selamlar, saldırgan içeriye nasıl sızmış ? Vmware paneli dış dünyaya direk açıkmıydı ?

Evet esxi erişimi dışa açıktı firmada. Şanslıydı ama örn x bir ubuntu sunucuda sadece /boot şifrelenmişti.

Kurtarma işlemi uzun sürüyor ama dosyalar db'ler sonuç veriyor çok şükür.

Dışarıya açmanın amacı nedir ? Neden bir vpn arkasına veya ztna ile erişim sağlamamışlar. En çok merak ettiğim şey bu neden dışa açılır.

Haklısınız tabi ama bu saatten sonra tek yapılacak şey veri kurtarmak mümkünse.

pm attım hocam yardımcı olabilirmisiniz

Öncelikle elinize sağlık, harika bir dosya oluşmuş. %90 insanların paylaşmayacağı bir içerik bu.

Açıklamalara rağmen zayıf bilgi sahipleri için zor olacaktır.
Lütfen kimse bilmeden deneme yapmasın, veri kaybetmesin.

Yedekli çalışmanın faydası tam olarak ortada.
Her zaman yedek alın. Ben 4 yedekle çalışıyorum. Sıkıntı yaşamıyorum.

Vm gibi yapılar dışarıdan erişilir olmamalı ve vm yönetici arayüzü de dışarı açık olmamalı.

Ben 2-3 vLan ile çok katmanlı yapı yaparım her zaman. İçeri giren önce çift fw içinden çıkmalı sonra da içine düşeceği vLan da erişim bulursa (bulamaz) erişir bir yerlere. 🙂

Tedbir iyidir.

İletişime geçildi.

Teşekkür ederim yazdıklarınızda çok haklısınız..

Korunmak için ne yapmalı. ESXI firewall arkasında almak yeterli olmuyor deniyor.