ESXi Babyk Ransomware Sonrası VM Kurtarma: Header Transplant ile Boot Onarımı

VMware ESXi ortamlarında görülen Babyk ransomware saldırıları, sanal makine dosyalarını hedef alarak VM’lerin açılışını bozar. En sık karşılaşılan tablo şudur: VM power on olur, ancak konsolda Operating system not found, No bootable device veya EFI tarafında No Media benzeri hatalar görünür. Bu yazıda, gerçek bir kurtarma senaryosundan yola çıkarak header transplant yöntemini, dosya yapısını nasıl okuyacağınızı ve inventory’ye güvenli dönüşü detaylı anlatıyorum.

Amaç, fidye ödemeden ve çalışan üretim sunucularını bozmadan boot zincirini geri getirmektir. Bu rehber sistem yöneticileri, hosting ekipleri ve siber olay müdahale (IR) süreçleri için yazılmıştır.

Babyk Ransomware ESXi’de Ne Yapar?

Babyk (ve benzeri ESXi odaklı fidye yazılımları) genelde şu izleri bırakır:

• .babyk uzantılı dosyalar: Özellikle .vmdk.babyk, log ve yardımcı dosyalar yeniden adlandırılır.
• “How To Restore Your Files.txt” gibi fidye notları VM klasörüne bırakılır.
• -flat.vmdk büyük veri dosyası çoğu zaman klasörde kalır; ancak dosyanın baş kısmı (MBR/GPT, EFI System Partition, NTFS boot sector) şifrelenmiş veya bozulmuş olabilir.
• Descriptor (.vmdk) eksik/yanlış CID ve DDB alanlarıyla yeniden yazılmış olabilir.

Kritik nokta şudur: Diskin tamamı her zaman şifreli değildir. Çoğu vakada ilk yüzlerce MB yüksek entropili (şifreli/bozuk) görünürken, daha derinlerde NTFS MFT (FILE0) gibi yapılar sağlam kalabilir. Bu yüzden “disk öldü” diye silmek yerine dosya yapısını okumak kurtarma şansını artırır.

Belirtiler: Bu Sorun mu?

• VM açılıyor ama işletim sistemi bulunamıyor
• EFI firmware ile “No Media”, BIOS ile boot menüsü boş kalıyor
• Datastore’da VM klasörü duruyor, -flat.vmdk boyutu büyük
• Klasörde .babyk ve fidye notu var
• Daha önce kurtarılmış *_restored kopyalar datastore’da duruyor olabilir

Kurtarma Öncesi Güvenlik Kuralları

1. Çalışan restored VM’i kapatmayın. Özellikle production’da ayakta olan kardeş kopyaya power off / disk yazma yapmayın.
2. Önce yedek alın. Hedef -flat.vmdk başından en az 1 GB’ı ayrı dosyaya kopyalayın.
3. Aynı UUID ve IP ile iki VM’i ağa birlikte bağlamayın. Klon/transplant sonrası Windows aynı static IP’yi getirebilir.
4. Fidye ödemeyin. Bu yazıdaki yöntem, ödeme olmadan boot onarımına odaklanır.

Teşhis: Dosya Yapısına Bakmak

ESXi SSH üzerinden hedef klasörü inceleyin:

ls -lah /vmfs/volumes/DiskX/ORNEK-VM/
hexdump -C -n 64 /vmfs/volumes/DiskX/ORNEK-VM/ORNEK-VM-flat.vmdk | head
cat /vmfs/volumes/DiskX/ORNEK-VM/ORNEK-VM.vmdk
cat /vmfs/volumes/DiskX/ORNEK-VM/ORNEK-VM.vmdk.babyk

Ne arıyoruz?

• MBR imzası: Sektör 0 sonunda 55 AA olmalı. Yoksa boot alanı bozuk/şifreli demektir.
• GPT: LBA 1’de EFI PART görülebilir (UEFI disklerde).
• NTFS: Partition başlangıcında OEM alanı NTFS olmalı.
• MFT: Derinde FILE0 görünmesi, veri gövdesinin kısmen sağlıklı olduğunu gösterir.
• Kardeş kopya: Aynı uuid.bios / aynı disk kapasitesi ile çalışan *_restored VM var mı?

Inventory’de klasör adı ile displayName karışmış olabilir. Örneğin klasör 185.x.x.75 iken inventory adı başka bir IP olabilir. Bu yüzden sadece klasör adına değil, VMX içindeki uuid.bios ve scsi disk adına bakın.

Çözüm Yöntemi: Header Transplant

Yöntemin özü şudur: Çalışan ve sağlıklı bir restored kardeş VM’den disk başlığını (header) alıp, bozuk hedefin -flat.vmdk dosyasının başına yazmak. Böylece:

• Bozuk MBR / partition / boot sektörleri onarılır
• Hedef diskteki veri gövdesi korunur
• Çalışan kardeş VM kapatılmaz

Pratikte ilk 1 GB genelde yeterlidir; çünkü şifreleme/bozulma çoğu vakada ilk ~500 MB civarında yoğunlaşır.

Adım Adım Uygulama

1) Çalışan kardeşte geçici snapshot alın

Hedef: Kardeş VM açık kalsın, yazmalar delta’ya gitsin, base disk okunabilir hale gelsin.

vim-cmd vmsvc/snapshot.create <VMID> "hdr_src" "temp header source" 0 0
vim-cmd vmsvc/snapshot.get <VMID>

Önemli: Snapshot sonrası -000001.vmdk ve açık -flat.vmdk çoğu zaman kilitli kalır (Device or resource busy / Failed to lock the file). Klon için parent/base .vmdk descriptor kullanın.

2) Base diskten thin klon alın

mkdir -p /vmfs/volumes/DiskY/tmp_hdr
vmkfstools -i '/vmfs/volumes/DiskX/RESTORED/ORNEK.vmdk' \
  '/vmfs/volumes/DiskY/tmp_hdr/base.vmdk' -d thin

Bu işlem thin provisioning ile görece hızlı tamamlanabilir. Klon bittikten sonra header kaynağı olarak base-flat.vmdk kullanılır.

3) Hedef VM’i kapatıp header yedeği alın

vim-cmd vmsvc/power.off <HEDEF_VMID>
dd if=/vmfs/volumes/.../HEDEF-flat.vmdk \
  of=/vmfs/volumes/.../header_backup_pre.bin \
  bs=1M count=1024 conv=fsync

4) Sağlıklı header’ı hedefe yazın

dd if=/vmfs/volumes/DiskY/tmp_hdr/base-flat.vmdk \
  of=/vmfs/volumes/.../HEDEF-flat.vmdk \
  bs=1M count=1024 conv=notrunc,fsync

conv=notrunc kritiktir: Sadece başı değiştirir, flat dosyanın geri kalanını silmez.

5) VMDK descriptor’ı düzeltin

Babyk sonrası descriptor eksik kalmış olabilir. Çalışan kardeşin DDB alanlarını referans alarak şunları tamamlayın:

• CID / ddb.longContentID
• ddb.uuid, geometry, ddb.thinProvisioned
• ddb.adapterType → VMX ile uyumlu olmalı (çoğu senaryoda lsilogic)
• Extent satırı doğru flat dosyayı göstermeli

6) VMX ve inventory ayarları

• displayName değerini istediğiniz isme çekin (ör. inventory’de görünür ad)
• Yeni uuid.bios verin (kardeşle çakışmasın)
• Yeni MAC verin (ethernet0.addressType = static)
• Firmware’i kardeş VM ile hizalayın. Bu vakada EFI “No Media” verdi, BIOS ile boot başarılı oldu.
• vim-cmd vmsvc/reload <VMID> ile inventory’yi yenileyin

vim-cmd vmsvc/getallvms | grep -i SemihTest

7) Temizlik: snapshot ve geçici klon

vim-cmd vmsvc/snapshot.remove <KARDEŞ_VMID> <SNAPSHOT_ID>
# gerekirse:
vim-cmd vmsvc/snapshot.removeall <KARDEŞ_VMID>
rm -rf /vmfs/volumes/DiskY/tmp_hdr

Kardeş VM’in power state, tools ve IP durumunu doğrulayın. Amaç onu bozmamaktır.

8) Hedefi açın ve doğrulayın

vim-cmd vmsvc/power.on <HEDEF_VMID>
vim-cmd vmsvc/get.guest <HEDEF_VMID>

Başarı işaretleri:

• guestState = running
• VMware Tools çalışıyor
• Guest OS adı görünüyor (ör. Windows Server 2022)

IP Çakışması Tuzağı

Header / disk klonu Windows guest’in ağ ayarlarını da taşıyabilir. Sonuç: Kurtarılan VM ile restored kardeş aynı IPv4’ü kullanmaya çalışır. Bu durumda:

1. Kurtarılan VM’de NIC’i hemen kesin:

vim-cmd vmsvc/device.connection <HEDEF_VMID> 4000 disconnect

2. Konsoldan IP’yi değiştirin
3. Ardından NIC’i tekrar bağlayın

Ayrıca bir sonraki açılışta otomatik bağlanmasın diye VMX’te ethernet0.startConnected = "FALSE" bırakmak güvenlidir.

Firmware Seçimi: EFI mi BIOS mu?

Durum	Öneri
Kardeş VM EFI + sağlam ESP	EFI deneyin
EFI “No Media” / boot entry yok	BIOS’a geçip tekrar deneyin
MBR imzası var, GPT yok	BIOS daha olası
Secure Boot açık ve imza uyumsuz	Geçici olarak Secure Boot kapatın

Neden Bu Yöntem İşe Yarıyor?

Babyk’in ESXi varyantında sık görülen model, büyük flat diskin tamamını değil özellikle başlangıç bloklarını bozmaktır. Boot loader zinciri (MBR/VBR/ESP) kırılınca hiper yönetici diski açar ama misafir işletim sistemi yüklenemez. Header transplant:

• Boot zincirini sağlıklı kopyadan geri getirir
• Veri alanındaki sağlıklı MFT/gövdeyi kullanmaya devam eder
• Çalışan production kopyayı kapatmadan ilerleme şansı verir

Elbette her saldırı aynı değildir. Disk gövdesi de tamamen şifreliyse bu yöntem yetmez; o durumda temiz yedek, storage snapshot veya offline decrypt/restore senaryoları gerekir.

Kontrol Listesi (Cheat Sheet)

1. Hedef klasörde .babyk + fidye notu var mı?
2. Flat başı 55 AA veriyor mu?
3. Derinde FILE0 / NTFS izi var mı?
4. Aynı UUID/boyutta çalışan restored kardeş var mı?
5. Kardeşte snapshot → base vmkfstools -i klon
6. Hedef off → 1 GB header yedek → 1 GB transplant
7. Descriptor + VMX (isim, UUID, MAC, firmware)
8. Snapshot/temp temizliği
9. Power on → Tools/OS doğrula
10. IP çakışması varsa NIC disconnect

Sık Yapılan Hatalar

• Kilitli flat’e dd denemek: Busy hatası alırsınız; önce snapshot + base klon yolunu kullanın.
• -000001.vmdk klonlamaya takılmak: Çoğu zaman lock edilir; parent descriptor deneyin.
• UUID/MAC kopyalamak: Inventory ve ağda çakışma üretir.
• Descriptor’ı yarım bırakmak: Disk açılır ama geometry/CID hatalarıyla kararsız kalabilir.
• Restored kardeşi power off etmek: Gereksiz risk. Bu yöntemde gerekmez.

Sıkça Sorulan Sorular

Babyk nedir?

ESXi ve sanal makine dosyalarını hedef alan bir ransomware ailesidir. Dosya uzantısı ve fidye notu ile kendini belli eder. Amaç, yedek ve erişim olmadan operasyonu durdurup fidye almaktır.

Header transplant veri kaybına yol açar mı?

Doğru yapıldığında (conv=notrunc ve sınırlı count) yalnızca disk başı değişir. Yine de işlem öncesi 1 GB header yedeği şarttır.

Restored VM yoksa ne yapılır?

Bu yöntem sağlıklı bir kardeş/yedek header’a ihtiyaç duyar. Yoksa storage snapshot, harici yedek veya offline onarım (Windows recovery / BCD / registry) senaryolarına geçilir.

Sadece .vmdk.babyk dosyasını geri adlandırmak yeter mi?

Bazen descriptor kurtarımı yeterlidir. Ancak flat başı şifreliyse yeniden adlandırma tek başına boot getirmez; header onarımı gerekir.

Bu işlem legal midir?

Kendi yönettiğiniz / yetkili olduğunuz sistemlerde felaket kurtarma kapsamındadır. Başkasına ait sistemlere izinsiz müdahale etmek yasaya aykırıdır.

Sonuç

ESXi üzerinde Babyk sonrası “işletim sistemi bulunamadı” hatası, çoğu zaman disk gövdesinin tamamen yok olduğu anlamına gelmez. Dosya yapısını okuyup çalışan bir restored kopyadan header transplant yapmak; doğru snapshot/klon tekniği, descriptor düzeltmesi ve UUID/MAC izolasyonu ile birlikte etkili bir kurtarma yoludur.

Bu yazıdaki akış, gerçek bir olay müdahalesinde doğrulanmış adımlara dayanır: kardeş VM bozulmadan klon alındı, hedef boot alanı onarıldı, inventory’ye yeni adla eklendi ve IP çakışması NIC kesilerek kontrol altına alındı.

Benzer bir vakanız varsa önce yedek, sonra teşhis, en son yazma sırasını bozmayın. Kurtarma sürecinde en değerli şey acele etmek değil, geri dönüşü olan adımlar atmaktır.

Destek İhtiyacı Olanlar

ESXi / Babyk / VM boot sorunlarında yardıma ihtiyacınız olursa doğrudan bana ulaşabilirsiniz:

• E-posta: semih@mynet.com
• Telefon: 0541 646 16 16

Mümkünse mesajınızda ESXi sürümü, hata ekranı (Operating system not found / No Media vb.), datastore klasöründeki dosya listesi ve VM’in powered off olup olmadığını paylaşın; teşhisi hızlandırır.